If you mean dividing a component into 3 separate files - ie. model.elm, > update.elm, view.elm , then yeah, that's fine. A single file is too. If you > have a massive Elm component that you feel is difficult to manage in a > single file, and splitting it into three pieces will make it much easier to > maintain and understand, go ahead and do that. Whether your component is 3 > files, or a single file shouldn't change your overall architecture - it's > just a horizontal partitioning of functions. >
Totally agree! I tried to present this advice on another thread <https://groups.google.com/d/msg/elm-discuss/u3J2eSThkjw/4FT3p50uBAAJ> but I'm not sure I said it as well as you just did. ;D > I'm not sure what you mean by framework - do you mean elm-parts? If so, > just forget about that for now and connect your components manually. It's > not a big deal. > 100% agree. > as the SPA transitions from page to page, we load only the data that is > required for that page - We have no central business data in our app, > because our server itself serves acts as the single source of truth. > +1 to this too If you're using websockets to update your business model, go ahead and do >> that - the model will be automatically reflected in the view. *Your view >> shouldn't know anything about websockets.* >> > Strongly agree! Only update should know or care that websockets are involved. I would second the need for better "official" documentation in Elm for > folks getting started. There is a learning curve to Elm, but once it > "clicks", it'll be more obvious how to piece your application together. > I think part of the challenge is figuring out where the gaps are. Threads like this are super helpful in surfacing specific questions, so HUGE thanks to Oliver for posting it! -- 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.
