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 [email protected]. For more options, visit https://groups.google.com/d/optout.
