Just bumping this to the top as it has the best discussion of html lazy that I know of in this mailing list and Evan's latest talk (React Rally) emphasised lazy there is such a way that I think I had better start using it better
On Wednesday, 2 August 2017 05:17:01 UTC+2, ajs wrote: > > Hi Mark, feel free to hit me up on Slack sometime to discuss further. My > last two messages to this list have had more than one week delay in posting > (ignore the timestamp, I'm posting this on Friday July 21), so that might > be easier. > > I discussed these ideas quite a bit with @ilias and he made a rather > interesting example of doing some things relating to state access: > https://github.com/zwilias/elm-disco > > I'm a firm believer that view functions should only receive data that they > directly interact with, and nothing more. I've just found that to be a much > better way to reason about interfaces. > > On 21 Jul 2017, at 19:04, Mark Hamburg <[email protected] <javascript:>> > wrote: > > Per the other thread discussing this this morning, I don't know that > passing the whole data model to all of the view-side functions is that > horrendous. (We pass around a UXConfig structure in all of our views to > provide access to translation functions amongst other things and the > biggest pain is that I'm not certain that making it he first parameter by > convention was the right choice.) Passing the whole data model feels icky, > but you can document the dependencies using different modules to access > different parts of the data model and you can still keep data model > mutation out of the views by emulating the command mechanism. > > That said, there are, definitely friction points where being able to > subscribe to pieces of the data model would be a significant improvement. > See my other message for some examples of these. But the friction is not in > needing to pass the whole data model through the rendering process. > > Mark > > On Fri, Jul 21, 2017 at 6:55 AM ajs <[email protected] <javascript:>> > wrote: > >> > However, the downside of doing passing the entire model everywhere is >> that you have to keep the entire model in your head when looking at any of >> your view functions. >> >> This is correct, but how can you avoid passing the whole model to all >> views if the data model isn't structured similarly to your view hierarchy? >> The idea of doing pre-processing on your data into a view-friendly >> structure seems to add overhead and complexity, while also more or less >> duplicating your view structure in two places: the view stack, and the view >> data. >> >> We have found that as apps grow in size, it is unreasonable to couple a >> data model's internal structure to the requirements of a UI, and thus >> passing The whole model is the only valid option for most view functions. >> The exception are leaf nodes down the line that have few or no children, in >> which case they can receive focused inputs only. >> >> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elm-discuss/F5pdcsls1Zc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- 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.
