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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
