FYI, Kris Jenkins' approach- http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html
On Tuesday, January 24, 2017 at 7:25:01 AM UTC-8, Rupert Smith wrote: > > I took some advice early on that a good way to structure components in a > nested TEA is to split each into 3 files; Types.elm, State.elm, and > View.elm. > > Now that I have more experience, I am not so sure that this is providing > the best design. I feel that it may generally be a good principle to group > together the definition of a Type with the functions that operate on that > type, as the 2 are highly coupled (feature envy, all the implementation > modules want to import Type). > > Obviously not all functions that operate on a Type will be in the same > module. It tends to be 'core' functions that make a type usable, and > functions that generally only involve that Type and the basics, not other > types. So Maybe supplies the Maybe type and a basic set of operations on > it. I write plenty functions that use Maybe in my code, but that code does > not get pulled up into the Maybe library. > > I am just wondering if anyone has some thoughts on how to apply Parnas' > principles of modular design to optimize the design of Elm modules with > respect to said principles (https://en.wikipedia.org/wiki/David_Parnas)? > > Some candidate "rules of thumb": > > Group Types and 'core' functions on them into the same module. Core > functions are the basic set of functions that make a Type usable, and > generally operate only on that Type and the types offered by the Elm core > libraries. > > A module that declares Type only cannot take responsibility for > implementing some functionality, so modules like this should be avoided. > > Never use exposing (..); always declare exactly what will be exposed. > > Never import using exposing (..); always expose explicitly what you want > or use the full name form Module.Type or Module.function > > The exposed functions of a module should align well with its > responsibilities. Group related responsibilities together. Consider > splitting a module to group related responsibilities into better units. > > If allmost all exposed functions of a module use Types or functions in > another module, there is a high degree of feature envy between the modules. > Consider pulling some or all functionality into the calling module, or > split it out into another module and combine together there. > > -- 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.
