There is no performance penalty to passing the entire model to all nested view functions. Elm will simply pass the reference to the object around, so the performance of passing the entire model vs passing just the necessary parts should be equivalent.
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. In contrast, if you limit what data you pass to each function, then it limits the possibility of bugs and makes it easier to focus when you work on the smaller functions. The smaller functions will also be potentially more reusable and it will be easier to set up initial data when testing. This also makes it easier to extract modules later, since if all the functions take a Model, then any module you extract would also need to import Model and any other modules that data in the model depends on. I also personally find that having the caller process the data (instead of having the called function transform the entire model into the data that it needs to render) usually leads to a nicer separation of responsibilities. On Wed, Jun 21, 2017 at 10:03 AM, Tomaž Žlender <tomaz.zlen...@gmail.com> wrote: > Is it performance expensive if each view function gets a whole state as an > argument? So instead of passing only a portion of a data that view function > needs for rendering, each function gets whole state and inside that > function another function is called first that transforms data in a format > needed to generate view. > > -- > 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 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.
