We need a clearer story on architecture

[Oliver Searle-Barnes]

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.

[Erik Lott]

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.

[Erik Lott]

I feel like I just wrote you a vague response - something I try to avoid. If you have a specific question about how to build or structure something in Elm, don't hesitate to ask.

On Wednesday, August 17, 2016 at 12:19:21 PM UTC-4, Oliver Searle-Barnes wrote:

[Richard Feldman]

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 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!

[Oliver Searle-Barnes]

Thanks Richard and Erik for your input, I am taking this all onboard and giving it lots of thought. I think the next step for me is to experiment and refactor my app into a couple of different structures. That should give me a feel for what works well and what doesn't. Thanks again.