I do not consider elm-parts to not be pure TEA, I just consider it to make view/state combinations that are ID'd for separation, but I still consider it pure TEA.
But overall yes, reducing repetition really is beyond important as every repeated thing is another chance for an error (after 30 years of programming and being burnt too much on exactly this). It reduces code, makes it easier to read, and significantly reduces the rate of bugs. I built my ProgramEx library just to reduce the boilerplate of integration multiple other TEA or elm-parts things for example (and I am using it in my projects). However, there is one niggle of irritant of elm-mdl/elm-parts that I am not sure can be worked around, and that is its 'ID', the fact you have to manually manage the number means that you can add in duplicates accidentally (such as duplicating a line to add something). However we need the ID's to keep things not only distinct but to refer back to them as well. What we need is some way to ensure there are no duplicates on generation and if so log a warning or something (there are also cases where duplicates are needed). Currently this is not possible without having a parent view that walks the entire virtual node try via a to/from json hack or so again, which is painful and not done for possible breakage reasons in the future. On Wednesday, August 17, 2016 at 8:03:25 AM UTC-6, Peter Damoc wrote: > > There is a growing interest in elm-mdl lately and this brings into focus > the issue of boilerplate when dealing with custom UI. > > In yesterday's Elm Remote Meetup, Søren mentioned that he hasn't met > anyone who uses elm-mdl without the parts. > > Here is a very simple form with and without the boilerplate: > https://github.com/pdamoc/elm-boilerplate-example > > The pure TEA UI (without parts) is around 50% more lines of code with zero > added benefit. > As I was porting the parts code to the non-parts form I realized that > there were some opportunities for errors due to repetitiveness. I basically > copy and pasted some of the code. > > I am all for using the current recommendations but there are specific > cases like the implementation of a dynamic UI toolkit where the current > recommendations produces lower quality code. > > > -- > 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.
