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 <mhamburg...@gmail.com> 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 <andrew...@gmail.com> 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 elm-discuss+unsubscr...@googlegroups.com. >> 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 > elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
