Point is, I have a fairly concrete idea of what makes sense for 0.18, so I wanted to share these thoughts as soon as possible.
The implementation is quite simple, and has no real impact on public APIs.
It does change code-gen a little bit, so surprisingly, this requires major bumps to the platform, core, and html on its own.
Time travel went away in 0.17, but I have some plans to bring it back better than ever before.
This needs some compiler features, but I don't think it forces 0.18. By pairing server-side rendering and elm-reactor, the bump to 0.18 feels more justified. Lots of people do not care about server-side rendering, but I think the elm-reactor stuff will be very worth it.
Shuffling some Html functions
The elm-reactor improvements require a change to the Program type. (I need the Model and Msg types to safely implement certain features.) This technically will be a breaking changes in Html.App.program so it will force a major version in elm-lang/virtual-dom and elm-lang/html.
I think this is a good excuse to:
I think using Html.program and Html.map will just be nicer. It does expand the scope of Html, but I think if the odd things are at the top of the docs, it won't feel too weird.
- Do some of this stuff.
- Move the contents of Html.App into Html.
Finally, with Html.Keyed and Html.Lazy, I felt like things were looking kind of intense. Like, why so many modules to do HTML?! I think dropping Html.App will make it feel more streamlined.
I think I could be talked out of the Html.App stuff, but we should discuss that kind of thing in a new thread. Please root any comments in specific personal experience and concrete technical details.
Removing Backticks / Flipping andThen
Since server-side rendering and elm-reactor force some major changes, it's a good time to break things. The best time for that is always right this second, because it only gets harder over time. So there has been a decent amount of agreement that the order of arguments in andThen was a mistake, and if 0.17 had been more tame, it probably would have been on the table then.
The idea is to change it to:
andThen : (a -> Maybe b) -> Maybe a -> Maybe b
This order looks clearer to me as a type, and I have heard beginners do better with it because it looks like map more obviously. More importantly, this argument order means you can do things pipelined:
|> andThen doSomething
|> andThen doAnotherThing
|> andThen doThatLastThing
This requires folks to either define functions separately (ideal style) or to use parens, making it explicit where a closure ends (something people have been surprised by in the past, so this is better too).
This would replace the backtick infix style like this:
The backtick syntax is neat, but ultimately, it is redundant. In practice, it is recommended against in every case, with the one exception of andThen. By changing the argument order in andThen, we can just drop the backtick infix syntax entirely.
I know there are lots of libraries out there with andThen functions, so my advice would be keep them the same for now. If this makes 0.18, you should swap when you are upgrading. Keep it consistent in 0.17. Keep it consistent in 0.18.
If you want to discuss andThen and backticks more (how that impacts your library, etc.) let's start a new thread. Again, please root any comments in specific personal experience and concrete technical details.