Definitely recommend simplifying it yep. :-) Ports, in my opinion, should only ever go in one, fully-functional module (I have it in a `Ports.elm` in my projects) that all things should share through it. The global top-level update call should feel free to delegate messages around.
On Thursday, November 10, 2016 at 3:11:19 AM UTC-7, Matthieu Pizenberg wrote: > > Thanks OverminDL1 and Wouter In t Velt, I will try to explain how I have > come to this issue. > Originally, I have designed a web page (the "part") that was loading a > collection of images to display them. > So the flow was: > - init the elm page with a list of images urls > - [port] send the urls to JS > - JS create local blob copies of the images at these urls > - [port] JS send back the urls of local images to elm > - elm can display and manipulate the collection of locally stored images > > Everything was working fine. > Then we wanted to deal with multiple collections of images successively. > So the app becomed kind of a SPA (the "Group") where each page (a part) > corresponded to one collection. > > And so the problem is that each page is receiving a notification for > loaded images that should notify only the page corresponding to their own > collection. > > Currently, I have circumvent the problem by filtering. > Since each page is aware of its own images urls, if it receives a port > notification with an new url that does not correspond to one of its own, it > does nothing of it. > > I have been reading a lot since, and a lot about the problem of making too > many "components". > So as you suggested Wouter In t Velt, I am refactoring a lot of my code > (and getting rid of a lot of those "components" inside it ^^). > It turns out it is getting much simpler than before. So I think I will go > with your first advice once it is finished, and manage all ports from the > top level SPA (the "Group"). > > Thanks again, I will let you know how it is going as soon as I get some > time to take care of this. > > On Wednesday, November 9, 2016 at 5:37:19 AM UTC+8, Wouter In t Velt wrote: >> >> In your design, the port has a 1-to-1 connection to the Part. >> The port does not communicate for which Part the incoming message is >> intended, because it "expects" that their is only 1 Part. >> >> Your batch function in the subscriptions in the Group.elm passes on the >> port message on to all your Parts. >> Your port receives one message of type `PortMsg (Some, Values)`. >> The Group subscription function effectively turns this into 10 messages >> of type `PartMsg 0 PortMsg (Some, Values)` etcetera. >> And passes each on Group update function. >> So all parts respond to the one message. >> >> You could: >> >> - refactor your port, to provide also an Int id of the intended Part >> to receive the message >> - subscribe to this port ONLY in Group >> - that would also mean you need to change code in JavaScript-land, to >> provide the Id when sending info to Elm >> >> Or: >> >> - store an `activePart: Int` in your Group model, so your Group >> update knows to which single Part the message should go >> - subscribe to the (unchanged) port in your Group subscriptions only >> (without bundling the subscriptions of each of the Parts) >> >> Or other options. >> But that depends very much on what you want to achieve. The terms 'Part' >> and 'Group' are quite generic, and it is unknown what happens at the other >> end of the port. >> Maybe you could elaborate on what you want to achieve? >> >> >> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
