[elm-discuss] Re: We need a clearer story on architecture

[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.


On Thursday, 18 August 2016 01:33:15 UTC+2, Richard Feldman wrote:
>
>
>
> 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!
>

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

[elm-discuss] Re: We need a clearer story on architecture

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

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

[elm-discuss] Re: We need a clearer story on architecture

[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:
>
> 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.

[elm-discuss] Re: We need a clearer story on architecture

[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.





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