@Nick "triplet" is commonly used shortcut for model, update, view functions. https://www.youtube.com/watch?v=LCNs92YQjhw&feature=youtu.be&t=21m09s
@Richard Thank you for your response, I really appreciate it! As I said before, I can be totally wrong. Put another way, *Elm does not have anything similar to components!* *But how about elm-mdl, elm-autocomplete, elm-ui, elm-datepicker, elm-form, elm-sortable-table even spinner elm-spinner? Thay all use theirs model, update, view "triplet" to be reusable and hide implementation details.* *And it is differently similar to components and pretty abstracted and reusable. I think it is good that I don't need to know how a Datepicker stores his view-state(open/close popup, scroll position etc) and his event flows, I just need the selected date. * Even more, it is exactly like described here https://gist.github.com/evancz/2b2ba366cae1887fe621 by the author of Elm Back to my example. Let's take a step back. I'd like to know more. > > 1. Where does this Login button get reused in the application? Is it > always in the same place in the header? Is it scattered throughout every > page? > > > 1. Is this a single-page application with multiple routes? > > These questions matter to figuring out how best to make it reusable. :) The UserInfo is more than a button, it will contain tabs, drop-down with checkboxes and buttons. So the model I will contain some user data (name, preferenses) and some view-state info (like current tab and open/close popup). Actions(Messages) will be also some global (like the "preferences changed") and the local (like tab switched). For login/logout and "preferences changed" I need to reload some stored data and send data to store preferences on our server. This "not component" will be used here only once (or more but not now) but should be used in several similar projects.They all will be using the same Identity Service so userInfo(and login/logout) should look and feel similar. The rest of application is a set of pages with the tabs navigation and multiple master/details grids and graphs. How I see my architecture for now. I have base service layer(folder). It contains modules for big data models, like user, cached data stores, etc. Plus some update functions to work with them (loader and reset, sync). Then I have pages models. Each page contains a model with sets of views-states(sorting order, tab states, scroll positions, etc) and their views and "update" function. I understand your point "don't do this", but the missing part is "do that". :) So Richard, How do you suggest to organize this differently? Can you point me to any good example of a big Elm application (with a user login and a multi-page navigation)? -- 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.
