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.
