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

Reply via email to