thank you Peter, I will try this approach and see how it works for my app. On Tuesday, August 9, 2016 at 11:57:22 AM UTC+2, Peter Damoc wrote: > > Hi Robert, > > To better understand the whole "state ownership" situation, take a look at > the implementation of elm-sortable-table > https://github.com/evancz/elm-sortable-table > and if you have the time/patience, watch this api design session > https://www.youtube.com/watch?v=KSuCYUqY058 > > What I can share from my own experience is this: > Within a complex app, there are a series of business objects. Specific > locations in your app deal with these business objects and do something to > their data. > > If you keep these business objects in one place at the top of your app and > you pass their information down to the components through the view, the way > it is done in elm-sortable-table, you end up with better code. > > If you pass the business objects at init down into the components and then > you have to deal with the whole extraction of the information and > synchronization of the information you end up with more trouble than you > need to have. > > > > > > > On Tue, Aug 9, 2016 at 12:39 PM, Robert Walter <[email protected] > <javascript:>> wrote: > >> Hi Richard, >> >> interesting information there. For me, I'm at a much smaller scale, but >> the scalability of Elm certainly is the deciding factor for whether or not >> I want to use it in production. I'm fooling around with a small but >> non-trivial app to get a better feeling and understanding of how Elm >> behaves "over time" and how easy refactorings are. I take it that, a lot of >> the road bumps I hit are due to my lack of fully embracing The Elm >> Architecture, but I would really like to get a better sense of what you >> mean with "state ownership". Are there any "archetypes" or "patterns" that >> give a bit more guidance? I can see that are common cases in different apps >> that appear over and over again, where we could give some direction. >> Not sure if my use case is actually that common, but just to give an >> example what I have in mind: >> I have an app with a "collector" and "items" (to keep it abstract for the >> moment). I want to have a page in my app, where I show the user an overview >> over all typed collections (think of a dashboard). For each item type, >> there are specific pages that show the user details of an item. Of course, >> everything is interactive. The question is, should the items become >> components? If yes, why? If no, why? >> Maybe there is no "yes of no" answer for this specific case, but I hope I >> was able to illustrate my idea. >> >> In general, I'd prefer to work with components early on, because I feel >> that, the longer I wait, the bigger and more painful the refactoring will >> become once I have to go from monolith to components. >> >> On Tuesday, August 9, 2016 at 6:42:57 AM UTC+2, Richard Feldman wrote: >>> >>> We have over 36,000 lines of production Elm code that we've been running >>> over a year. Before that we had a ton of React code, although Elm has since >>> overtaken it in terms of LoC. >>> >>> >>>> Since I'm comfortable with React way to componentization, I can't >>>> understand why " *flat is better than nested*. " while getting big >>>> update and view functions. >>>> >>> These huge files won't hurt the maintainability (and reusability) of the >>>> project ? Someone can expand in this area ? >>>> >>> >>> If the files feel too big, split them into separate files and import >>> them. That's not a big deal. >>> >>> What is a big deal, and a super common beginner mistake, is to split out >>> separate state ownership when you don't need to yet. >>> >>> Our React code base is full of components that each have their own local >>> state, because that's what React encourages. >>> >>> Our Elm code base has very, very few components with their own local >>> state. In most cases each "page" has its own state and state is not >>> subdivided any further than that. >>> >>> As far as maintainability goes, it's not remotely close. It's not just >>> that Elm code is more maintainable, it's that it is on a different planet >>> of maintainability. The gap between Elm and React is bigger than the gap >>> between React and MooTools. >>> >>> tl;dr I wouldn't worry about 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ >
-- 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.
