Just to pipe in with my experience, I'm working on a medium sized project with a lot of inter-related data between my modules, which is dictated by a database structure. We started the project as a single file elm project, but the code was starting to get unmanageable, so we broke it out into modules. When that was done, we fixed the elm error reports until it worked again. That meant that in some cases, we broke out some modules into multiple files, and we tried to stick to generally Module.View, Module.Update, and Module.Model. We had a few instances where we had to break out sub-update messages (ie the union type typically used in Module.Update) because we had messages that passed messages.
Also for methods, only pass what you need, even if it means passing and returning more data. I eliminated a handful of circular dependencies just by doing that. Only break things out if there is a reason to. If there is a circular dependency, then either see if there is a way to use anonymous types, or break out the files. Things like update messages might be okay to use anonymous types, as long as elm is able to infer the types properly. On Wed, Jan 25, 2017 at 9:41 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > On Wednesday, January 25, 2017 at 12:11:46 PM UTC, Rupert Smith wrote: >> >> 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 >> > > So I think I understand where the tempation to put Model and Msg in > Types.elm comes from. As the codebase grows I may end up with lots of > functions for rendering the view, which are of the type Model -> Html Msg. > Or it may be the update function that grows and I end up with lots of > helper update functions of type a -> (Model, Cmd.Msg). So these functions > cannot simply be pushed down to a sub-module as they need to import the > type, but that is in the main module that is using them - a circular > dependency. > > Just grabbing some random function from view code I was working on today: > > slideButton : Model -> Html Msg > slideButton model = > div > [ class "slide-button" > , Events.onClick ToggleMenu > ] > [ div > (Animation.render model.slideButtonStyle > ++ [ class "slide-button__inset" ] > ) > [] > ] > > I could push this down into a child module by not passing the whole Model, > but just the bits it needs, and by passing a 'tagger' for building the > messages: > > slideButton : Animation.State -> msg -> Html msg > slideButton slideButtonStyle clickTagger = > div > [ class "slide-button" > , Events.onClick clickTagger > ] > [ div > (Animation.render slideButtonStyle > ++ [ class "slide-button__inset" ] > ) > [] > ] > > Interestingly by removing the Msg and Model type from this piece of view > logic I have also made it re-usable (with other Models and Msgs, that is, > other components). So I think if I structure my code this way, as groups of > related functionality emerge and files get too long, the tidying up > activity will be to introduce re-usability into code as it it organized. > > So some good rules about modules with Types only might be: > > * A module that declares Type only cannot take responsibility for > implementing some functionality, so modules like this should be avoided. > * A module that declares Type only can introduce too much coupling when it > is used as a technique to break the circular dependency of modules. > > > > -- > 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. > -- 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.
