m.route.Link WTF???

[graphicla]

I'm just a long time Mithril aficionado, an expert by no means, but wft is this m.route.Link BS?? oncreate:m.route.link was EASY and fit very well within Mithril's minimalistic paradigm. I am concerned that this sets a precedent for building components into the framework which to me seems VERY antithetical to Mithril's differentiating value, which is STAYING OUT OF THE WAY.

I'm not yelling.

Why did you guys do this? Surely there is a great reason I am not considering.

[dead-claudia]

@joshuajameshunt This specific component had been in the talks for over a year. What us maintainers found from experience was that using lifecycle hooks was counterintuitively resulting in more boilerplate and making it harder to use. Also, it was harder to get right: the old oncreate: m.route.link didn't work if you ever wanted to change the target URL. If you wanted to do that, you had to do oncreate: m.route.link, onupdate: m.route.link, and I couldn't tell you how many people asked for help on Gitter because they didn't know about this. And finally, there were a few other edge cases not covered with the old lifecycle-based implementation: it didn't cover accessibility and it notably didn't support server-side rendering. The current implementation is still relatively simple, and it doesn't actually bloat the bundle as much as you might expect.

We've been very cautious on which components to include in core, trust me. There's a couple other components I've looked into, with only one having a serious shot at making its way into the core bundle:

• m(Async, {init: async () => value, pending: () => vnode, ready: (value) => vnode, error: (e) => vnode}) - This encapsulates a very common piece of logic in apps, and it'd remove a source of frequent boilerplate. It's not opinionated, and it's encapsulating something that's so easy to screw up that I've personally screwed up on multiple occasions by accident doing similar things. I'm almost surprised React didn't add a hook for similar purposes because of how much it simplifies things in practice. It's also a common source of questions, and I feel it's useful enough it deserves a story, more so than even routing.
• I've considered moving m.route(...) to component land as part of allowing dynamic routing, but I've decided against exposing an API using components (I'll likely be going with functions instead) since it's just more boilerplate for the user. Internally, m.route uses a component to know when to update and clean up after itself, but the component isn't itself exposed to the user.

[dead-claudia]

Also, side note: GitHub supports Markdown in comments. You can place emphasis *like this* (rendered: like this) and bold parts **like this** (rendered: like this) if you want to emphasize without using all caps.

[graphicla]

@isiahmeadows I appreciate you taking the time to explain this. I'm reassured that you are doing your best to keep Mithril "light and yet harder than tempered steel" and that you share my concern over built-in components and other bloating. Having never encountered the oncreate:m.route.link corner cases or bothered with SSR I was upset to have to do a lot of redundant editing 'a.button' to {class:'button'} sort of thing which to me seems like more effort to do the more common task. Not to mention that onupdate:m.route.link in the rare case that you're dynamically changing the URL is actually pretty intuitive and easily documentable (in my opinion).

The more similar Mithril becomes to React the less reason there is to choose Mithril. It's beauty is in its simplicity, and that is – as you know – incredibly difficult to preserve.

[orbitbot]

@joshuajameshunt If you'd like to keep the old functionality it's not that hard to copy paste the old or a modified new implementation of m.route.link into a helper of your own.

Apart from that, you can pass a.button as the selector parameter instead of refactoring to a separate class parameter.

IMO Mithril isn't in a particular hurry to become more like React, not sure exactly what you're referring to.

[dead-claudia]

[@joshuajameshunt] The more similar Mithril becomes to React the less reason there is to choose Mithril. It's beauty is in its simplicity, and that is – as you know – incredibly difficult to preserve.

[@orbitbot] IMO Mithril isn't in a particular hurry to become more like React, not sure exactly what you're referring to.

@joshuajameshunt I'm currently trying to make Mithril less React-like, actually. I was personally a bit resistant to the design of the v1 rewrite from v0.2.x (which was a basic component-driven MVC framework), and I'm trying to gradually move Mithril back closer to that v0.2 simplicity at least at the API level, just in a way that's a bit more streamlined, a bit more ES6+ and reactivity friendly, and still relatively fast. (Our renderer is among the fastest, so even little things can cause noticeable changes.)

In fact, that's why I've been trying to find ways to avoid adding full on React-like "hooks": it's a solution to a long-standing problem, but it "solved" reactive views about as well as Angular v2+ "solved" MVVM by separating things into components.

[dead-claudia]

Is this intentional, and if so is there a fix?

I need more details than that. Could you file a separate bug with the target platform and a repro? I don't recall making any functional changes to that part of the router implementation.

[graphicla]

@isiahmeadows Roger that. BTW I really appreciate the work you and others are doing on this project. Thank you.