On Tuesday, January 24, 2017 at 4:32:41 PM UTC, jphedley wrote: > > FYI, Kris Jenkins' approach- > http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html >
Part of the reason I think this design is wrong, is that when importing a component into the top-level Main module to use it, I have imports like this: import MyComponent.Types import MyComponent.State import MyComponent.View Which tells me that I never need just one of these modules, I always need them all. So the code is not forming a 'coherent' module very well. I think a better approach would be to put build a TEA component like this: module MyComponent exposing (Model, Msg, update, view, init, subscriptions) -- and perhaps also OutMsg Then if the component starts to get too big, instead of splitting it up into Types/State/View, just split out parts of it that group well together into appropriately named sub-modules. The advantage of this is that to use the component only 1 import will be needed, and that will hide the implementation sub-modules behind the principal one. To decide what code to pull out into sub-modules, just look for related functionality that makes sense to be combined together. So perhaps I am writing some view logic for a menu and it is getting quite big, extract all the menu code into its own module. Perhaps I have a group of functions that unpack/repack data from a REST service into a model that is suited to what I need for the UI, maybe pull those related functions and the model Type that they work with into its own module. And so on. -- 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.
