I'm building quite a large app at present and find myself passing more and more into the view functions in addition to that component's model. I feel reassured knowing that the view function can't mess with any state and the diffing engine is ensuring that I'm not causing more DOM work than necessary.
The inability to capture even micro amounts of state in components will either be one of Elm's long term contributions to front end programming or part of its eventual sidelining by a broader community - I don't know which though. On Friday, 27 May 2016 07:28:57 UTC+2, Ian Mackenzie wrote: > > I think the first solution (context/options argument) is the clearest and > simplest. Yes, it's a bit verbose, but: > > - You can use the 'view' and 'viewWithOptions' pattern where the > former calls the latter with a default primary color etc., so you can get > convenience if you don't care about customizability > - Users can easily do something like `myView = viewWithOptions > myOptions' in their own code and then just use that partially-applied > function everywhere (with the advantage that they can control exactly > where > and how the partial application happens) > - It's very clear what's going on - one of the things I love about Elm > is that it's much easier than other languages to trace the flow of logic > and see how things work without having to worry about hidden/implicit > state > or context. Creating a module-like record seems to move a little ways in > the 'magic' direction... > > -- 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.
