Oliver, we're currently migrating a large production SPA to Elm - 15+ pages non-trivial app, drag and drop interfaces, complex data display, integrating with multiple backends, etc. Not a toy.
Components - the best advice I've heard is to extract view/model/update > separately, as we've seen with elm-mdl this only goes so far though. In the > end every large application is going to end up with it's own framework > similar to elm-mdl so this seems to be an issue that needs to be resolved > somehow. 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. 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. Separation between view model(component state) and application model > (records from the server) - previously I've always had these two separated > which has meant that I can have multiple views updating the same server > records. Yes, exactly right. Conceptually, you'll want to make sure that you have a single source of truth for your business state, and your components only manage their internal state - they do not store business state in their model. Evan has created a great example here: https://github.com/evancz/elm-sortable-table/blob/master/README.md#about-api-design . When you update your business state, any component displaying that state should automatically reflect that change. Notice that I've said "Conceptually". I get the impression that most folks in the Elm discuss board have small apps that can hold their entire business model in memory all at once, like a todo application - In that case, that business state could be stored all together in the root model and used as the single source of truth of business data. In our case, however, we have a huge amount of user data, and it would be unreasonable to load all of that data into the app at startup. Instead, 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. Services - when I've had cross-cutting concerns I would typically manage > them in a service tier, e.g. I'm using websockets and want to update the > view optimistically. Managing the optimistic vs confirmed state isn't > something that I'd expect to have abstracted away from the view. I'm not sure if I follow you on this, but I think this is something that I would actually abstract away from the view. 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. These are my concerns and issues, what I'm really looking for though is an > approach to move things forward. Given that there are existing frameworks > with well understood architectures I wonder if we should work on guides of > the form Elm for React users or Elm for Ember users and try to translate > the concepts from those frameworks into practical solutions within Elm. I > think this would help clarify the advice and perhaps uncover areas where we > need to give some more thought. 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. On Wednesday, August 17, 2016 at 12:19:21 PM UTC-4, Oliver Searle-Barnes wrote: > > I've been using Elm for about 4 weeks now and having generally been loving > it. An area that I'm really having trouble with though is architecture. The > basic TEA is a fantastic foundation but the guidelines are really very > limited with regards to requirements of a typical SPA. > > * Components - the best advice I've heard is to extract view/model/update > separately, as we've seen with elm-mdl this only goes so far though. In the > end every large application is going to end up with it's own framework > similar to elm-mdl so this seems to be an issue that needs to be resolved > somehow. > * Separation between view model(component state) and application model > (records from the server) - previously I've always had these two separated > which has meant that I can have multiple views updating the same server > records. > * Services - when I've had cross-cutting concerns I would typically manage > them in a service tier, e.g. I'm using websockets and want to update the > view optimistically. Managing the optimistic vs confirmed state isn't > something that I'd expect to have abstracted away from the view. > > I'm not really looking to resolve these issues here but I do feel like the > community is going in circles. Every day we hear the same questions like > "how does parent-child communication work?" but the advice that is given is > different depending who you ask (and always feels unresolved). > > A general concern I have is that the impression that's given is that > abstraction is treated as something which should be avoided. This seems > unworkable for large SPAs. It gives the impression that perhaps no one in > the Elm community is really building large applications. > > > These are my concerns and issues, what I'm really looking for though is an > approach to move things forward. Given that there are existing frameworks > with well understood architectures I wonder if we should work on guides of > the form Elm for React users or Elm for Ember users and try to translate > the concepts from those frameworks into practical solutions within Elm. I > think this would help clarify the advice and perhaps uncover areas where we > need to give some more thought. > -- 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.
