I have a rather gross implementation of what I'm hoping to achieve. I don't really see a way to do this without writing Native code, which is highly unfortunate: https://github.com/tgecho/elm-custom-task-example
On Friday, May 20, 2016 at 2:03:42 PM UTC-4, Erik Simmler wrote: > > Thanks! ...but I don't think I explained my question very well. I'll try > to come up with some sort of explanatory sample code when I have some time > back at my computer, but in the meantime... > > In your sample, you're only nesting the component once. In my case I have > more than one child of the same type (e.g. the nested counter/gif > examples). I'm looking for a good way to return a Cmd from a child to > javascript through a port, do some async work in JS and route a Msg with > the result back to the same child. > > The Gif/Http/Task workflow seems to be really close to the result I want > which is why I brought it up. > > > On Friday, May 20, 2016 at 12:57:38 PM UTC-4, Peter Damoc wrote: >> >> Keep your ports in one file and import that file throughout your project. >> >> Here is a gist with a simple example: >> https://gist.github.com/pdamoc/bf346e232ae2466923c18101122e3690 >> >> download and >> >> $ elm-make Main.elm --output elm.js >> >> agree to the install of the packages and after the elm.js is produced, >> open index.html >> >> you should be able to see the classic counter and it should work as >> expected with one small change, the update of the counter is done with a >> round trip through JS. >> >> The way I've set up this to work is by creating a port `toJS` where I >> send String >> in index.html, I check to see if the String is "Increment" and send back >> through `fromJS` either +1 or -1 >> >> In Component I subscribe to `fromJS` and feed this +1 or -1 back into the >> counter update. >> >> As you can notice in Main... there is no knowledge in the parent about >> what the Component is actually doing. All the parent does is map things and >> pass around messages just like in any other regular Elm Architecture thing. >> >> One last thing. Please note in Ports.elm that the Cmd and Sub you have >> there are generic. >> >> This way, the Ports.elm doesn't need to import anything. >> Also, as I've demonstrated in Main.elm you can subscribe to those ports >> from other parts of the App, even with different purposes. I've subscribed >> in Main just to snoop on what's going on there. :) >> >> >> >> On Fri, May 20, 2016 at 5:59 PM, Erik Simmler <[email protected]> wrote: >> >>> Does anyone have a good pattern for handling multiple nested components >>> that need to communicate with JS via ports/subscriptions? >>> >>> I have a list of items, and I'm trying to allow any of these children to >>> send a message through a port and receive the result back via a >>> subscription. I have the outgoing port and incoming subscription wired up >>> and functioning (using `Sub.batch` similarly to >>> https://github.com/evancz/elm-architecture-tutorial/blob/master/nesting/4-gif-list.elm#L150), >>> >>> but any message I get back through the port from JS land is duplicated for >>> each child. >>> >>> Furthermore, I can't come up with a nice way to get them tagged and >>> directly properly without moving the ports up to the containing component >>> and "manually" wrapping/unwrapping the commands and messages, which seems >>> like an unfortunate level of coupling. >>> >>> In the elm-architecture-tutorial repo, the Gif component requests a new >>> url by returning a command created by `getRandomGif` ( >>> https://github.com/evancz/elm-architecture-tutorial/blob/master/nesting/Gif.elm#L53). >>> >>> In the second nesting example, the only relevant place that I can see any >>> mapping occurring is the usual `Cmd.map` at >>> https://github.com/evancz/elm-architecture-tutorial/blob/master/nesting/4-gif-list.elm#L93. >>> >>> Yet, when the `FetchSucceed` comes back, it is properly wrapped in a >>> `SubMsg Int` message. >>> >>> This seems to be exactly what I want, but I can't figure out how it >>> works. How I can replicate this effect on my own or am I just barking up >>> the wrong tree? Thanks! >>> >>> -- >>> 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. >>> >> >> >> >> -- >> There is NO FATE, we are the creators. >> blog: http://damoc.ro/ >> > -- 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.
