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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
