> I have not seen the reverse happening. We did spend the first 6 months or so of our project following the advice to not use nested TEA components. Our experience was that the perceived complexity of the app grew exponentially to the point where it was difficult to make progress. We refactored into a nested TEA structure and are far happier since (the change was made at the start of the year). I'll try to summarise the areas where we saw an improvement. (note I've used the term TEA component for lack an alternative -- triplet doesn't really cover it as we've added additional functions into what we think of as mini-apps).
*Msgs* The Msgs for a part of the UI were only valid once that part of the UI was actually loaded. Prior to nesting we had to handle the possibility of Msgs being created that in fact couldn't exist at a particular point in time. *Models* Similar to Msgs, the state for a particular part of the UI was only present if that part of the UI was actually initialised. Using a flattened structure this led to a lot of Maybes that could be replaced by a single Maybe or Dict (in the case that multiple versions of that part of the UI could be loaded at the same tie). While it isn't necessary to introduce a TEA component to do this, you are already another step down the road to a TEA component once you do this. *Declarative data loading* Each TEA component can now specify which data it requires and it's made available/kept updated when that component is active. Active here meaning that the component has been initialised but may or may not currently be visible. Having this consistent approach to data synchronisation has made it easier to understand the data lifecycle for a particular part of the UI. *Synchronisation of scroll state and focus* Each of our nested components now has a syncDom hook which is used to synchronise aspects of the DOM which can't be handled declaratively. Being able to target a TEA component rather than the whole app or e.g. a particular element's scroll state has proven to be a practical level of granularity. *Reusable view components* We view these as distinct from the mini-apps that I mentioned earlier. The approach elm-sortable-table uses shifts some of the burden of state management into the client of the package. In it's case this is a good tradeoff. In other cases, when a component has several pieces of view state for instance, pushing this out to the consumer ends up with copy/pasted code that has all the pain that you'd expect. Sometimes the client has no business touching the state at all, e.g. the open/closed state of a dropdown menu for instance. In that case the menu is responsible for when it's open/closed and it needs to manage this when a user for instance clicks on a link in the menu (the menu needs to be closed before handling the click). *Code comprehension* Developers are finding it far easier to navigate the codebase. They're now able to work on a particular TEA component and the amount of code they have to grok before they can get started is far smaller. Prior to introducing the nested structure the feedback from new developers was that they felt lost at sea and overwhelmed by the amount of code they had to wade through. Generally excuses were made and they avoided working on the Elm app. Now that we've moved to a nested structure they're able to concentrate on a small part of the app and get up to speed/make changes easily. Our experience has been that TEA component concept that was encouraged with 0.17 has it's place in SPAs. It appears other teams building SPAs have had similar experiences (although I'm not sure whether they've experimented with the flat approach). As Mark has mentioned it does at least provide an architecture which new Elm developers building SPAs can get started with. There may well be a flat approach that addresses some of the concerns that I've mentioned. Currently though it seems a somewhat illusive approach, if it's to be encouraged then there needs to be some more concrete advice regarding how to implement it. That said, aside from a little boilerplate (which is minimal by comparison to the actual app code) we really haven't felt any desire to move away from the nested TEA structure. On Thursday, 20 April 2017 03:09:47 UTC+2, Richard Feldman wrote: > > The structure camp says (in many more words) "I've seen your alternative >> and it isn't a real alternative. It's a pathway that decades of software >> industry experience indicates leads to creating big balls of mud." >> > > This idea would hold more water if people hadn't tried what you're telling > them Decades Of Experience Dictates Can't Possibly Work and found that it > actually worked great when they tried it. > > The old "who are you gonna believe, me or your lying eyes?" argument does > not have a great track record. > > >> To the extent that we live in a world where we all say "you're free to >> develop software however you see fit", we can often take the attitude. >> "That's interesting. It wouldn't work for me but I see why you are making >> those choices." >> > > It seems that from your perspective, this is an intellectual exercise with > low stakes. I see this as a discussion that has great potential to cause > pain, because I've seen a lot of pain result from past discussions on this > topic. > > A lot of people follow what you're advocating and then end up reporting > that they had a really bad experience with it. I ask where they got the > idea that this would be a good approach to follow, and they point to a blog > post someone wrote, or a discussion thread where nobody stood up for the > simpler alternative. Then I point them to advice like this > <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbuu0m4/>, > > and I get a lot of people coming back to thank me afterwards, saying they > got out of the "component mindset" and now they're happy with how their > code scales. > > *I have not seen the reverse happening.* I don't see people saying "I > decided to refactor everything to be based around model/view/update > triplets just because, and I was much happier with my code afterwards." > Obviously it's not impossible to follow your advice and have a fine time > anyway, but I can confirm at least one case - myself - where someone > consciously shifted towards the "component mindset" (before it had that > name) and hated working with the result so much, he halted work on the > project until he could refactor it back to the old way. > > You keep acting like this is unexplored territory even though *it has > been explored by many people.* > > I'm not going to pretend discussing things in a public form has no > consequences for beginners who come across it later. Call me a > bold-text-using verbal ruffian if you like. If I can pull people away from > a cliff, I intend to. :) > -- 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.
