On Wed, Apr 19, 2017 at 9:19 AM, Richard Feldman < [email protected]> wrote:
> My point that there's a simple way to scale Elm applications by > abstracting at the function level has gone uncontested for awhile in this > thread. I think at this point I've said my piece and might as well move on. > > It's cool for people to have philosophical goals separate from the goal of > a nice scaling experience, but I honestly don't think I have much to > contribute to those discussions. :) > I am genuinely interested in a reasonable answer to the encapsulation of side-effects components/widgets. I have tried to think about this when I tried to reimplement the old tutorial and failed to find a proper solution. I remember asking about it here (or maybe on Slack) and have no memory of an answer. I don't know how to encapsulate the kind of functionality that was demonstrated in the RandomGif or the SVG Animation with the currently recommended approach. It's fine to say, "we don't do it like we used to do it" but there was no functionally equivalent solution offered. Also, one could use the old approach to scale by splitting an app into pages. I have no idea how to avoid Model-Update-View when implementing the idea of Pages. You say: > > *we learned that a Model-View-Update triplet is the wrong unit of > composition for Elm applications.* How do you propose to split the functionality one has in a highly complex app with a lot of pages without using those triplets? -- 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.
