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.
