Pierre-Yves Gérardy

@isiahmeadows this is not equivalent to RouteResolvers: It will not preserve layouts on route change, and will not keep the previous endpoint live while the async route is pending.

The first screencasts series are very good (It's nice to have the perspective of both novices an experimented users), it would be a good addition IMO, but I'm not sure...

Actually, as far as API goes, I'd rather add an extra, optional `{onhashchange: true}` param to `m.route.prefix()` so that the routing strategy is set in one API call.

I'd rather not add unnecessary friction, even for v2. Would you go for `m.route.config({prefix, onhashchange})`?

@barneycarroll I wish it were, but #1734 can't be fixed without a breaking change, I want it fixed ASAP and I don't want to do 3.0 just after 2.0. This...

Indeed... Anyway, updating the test suite is going to be fun :-)

Here's what it would look like if we went for `m.route({root, default, routes, prefix, onhashchange})`: https://github.com/pygy/mithril.js/compare/pygy:fix-1734-rebased-2018-6...pygy:fix-1734-revamped-api-2018-6?expand=1

@tivac any thoughts on the API bikeshed? `m.route.prefix(prefix, options?)` seems like a fine compromise for both backwards and forward compatibility. Alternatively, a codemod could also be used for migrating to...

Thanks for the heads up! That's a good suggestion. Alternatively, we could replace `buildQueryString` / `parseQueryString` with a `URLSearchParams` polyfill (like we replaced the A+ non-compliant Promise implementation with one...

If you want custom diff behavior on route change, you can use a RouteResolve. Here using a `key` to get the behavior you want if I understand correctly: ```JS m.route(document.body,...