On Sep 10, 2016, at 10:05 AM, Josh Adams <[email protected]> wrote: > > Would you be willing to paste some example code so we can see the problem you > faced and the way you solved it? If so, maybe we could find that if you'd > made one small tweak to your solution then you never would have achieved this > level of frustration.
Sadly, I can't put up enough to be interesting without having to get legal permission. It's not that there is anything super secret but corporate policies would get in the way of just dumping a bunch of code out. So, I could do so, but it would probably be a week from now by which point it's a bit late. I could try to summarize them here, but I'm finding this community to be a bit hostile at times to such summaries. The code base is also in Elm 0.16, so some of the issues are, in fact, improved — specifically, I don't have to watch the window size signal and route that information down when the portion that cares doesn't make sense to keep at the top level and worse doesn't necessarily exist all the time. To point to something at least similar, consider Slack. You've got a hierarchy of boards, channels, and posts (and a bunch of other stuff). The set of channels depends on the selected board. The set of posts depends on the selected channel (and the selected board). It's natural to just manage them all together at the top level but as there get to be more pieces of the model, there gets to be more bumping heads as well if multiple people are working on it. So, it makes sense to start breaking things up in terms of modules for the board list, the channel list, and the message list. But selections in one affect the available choices in the other and APIs for talking to the server need to know the full information path. The choices then seem to be to replicate state — e.g., let the channel list know the ID of the selected board so that it can talk to the server about the channels on the board — or pass state down with all operations. The latter is better for avoiding things being out of sync but we still found ourselves needing messages to say things like "the board ID just changed" and if you've got to send those messages or invoke those functions, then you are more or less dealing with the sync problem but you'll have a harder time debugging sync issues because you won't have the values to look at if the sync doesn't happen. I'm not pretending that there is some magic way to avoid this. I've worked with observation systems and seen the confusion they lead to. But I am looking for best practices to manage this sort of coupling. As for contrivances v real problems, I approach these things like a mathematician and look for the core abstraction, the core problem which often is intentionally disconnected from the actual problem because much of the real problem is a distraction. I've got a new team member looking at elm-mdl and wanting to know whether that's a good pattern to follow in implementing a fairly elaborate corporate UI standard (not MDL but similarly involved). The initial feedback I've had to give is that the approach taken in elm-mdl hasn't been embraced by the larger Elm community but when asked as to what one should do instead to cover those same sort of problems, I haven't been able to supply a good answer. The questions in other threads seemed to boil down to "I'm implementing an MDL ripple or a calendar or something else with local/private state, how should I handle that?" If every answer is a one-off, then it means that Elm is a lot harder for new team members to work with and adopt. Mark -- 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.
