I've hesitated to mention this since I'm a newcomer to Elm, but I'll throw it out there and see what you think.
The way Elm currently renders subcomponents is because the view is a pure function, so all subparts must be pure functions. That's what makes stateful subcomponents irritating to work with... the boilerplate of accounting for them in the parent. As a thought experiment, what if Elm were to bring in support for UI components that were independent of Main? They get wired to received init/update/view independently of the parent. They get avenues to send messages to the parent and vice versa. They get some state from the parent on init. Etc. That path has already been well-traveled by most every other front-end so we can know the answer. Doing that is basically bringing in object orientation and all the accidental complexity that comes with it. Right now Elm steers us away from those problems by forcing our code to be deterministic, but with the trade-off of the parent being responsible for everything underneath (requiring the boilerplate). That's not an answer to the issue at hand. It's just an observation that Elm does provide a (perhaps non-obvious) benefit with the current way it does things. It still definitely has pain, but it's clear-cut as opposed to accidental and pervasive. So I think that's why we hear the advice from the more seasoned folks to start from a place of having the parent manage everything with the child being stateless. Only once it becomes impractical for the parent to maintain the child's state, then take the lumps to make it stateful. The message is: yes, there's pain... just avoid it until you can't. Now don't get me wrong, I want the ability to use UI toolkits without impacting "my" code. And I want to eradicate boilerplate. We just need to be mindful of the trade-offs in how that's accomplished. Myself, I'm still thinking on it. On Thursday, August 18, 2016 at 1:41:57 AM UTC-5, Oliver Searle-Barnes wrote: > > In my experience every large SPA I've worked on has ended up building a > set of it's own components similar to elm-mdl. They've usually been used > alongside other components that have been provided by libraries such as > elm-mdl but they're still a significant part of the codebase. From this > perspective, and judging by the questions I've seen in slack, this is > something that pretty much every Elm developer is going to need to resolve. > > It would also be great to have a healthy selection of UX components > available at http://package.elm-lang.org/. To get a concrete idea of some > of the sorts of components this might be take a look at > https://emberobserver.com/categories/components. > > Making it easy to author, share and consume UX components will only make > building Elm apps even more pleasurable :) I'd caution against treating it > as a special case for advanced use or the select few. > > > On Thursday, 18 August 2016 08:25:29 UTC+2, Peter Damoc wrote: >> >> A small clarification that came up in an earlier discussion. >> >> This is a boilerplate example for the case where you have many small >> components that are unavoidably stateful as it is the case with UI >> toolkits. >> >> This is a topic that concerns very few people from an implementation >> point of view but stands to concern a lot of people from usage point of >> view. >> >> Most of the components needs are covered by current technologies. >> >> One more thing that might be worth mentioning: >> Adding a new field involves changing the code in 3 places for the >> with-parts version and it 5 places for the without-parts code. >> >> >> P.S. Many thanks to Josh for cleaning up the code of without-parts >> example. >> >> -- >> 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.
