• Dev

  • Mithril version

I've spent the last couple of days familiarizing myself with Mithril, only to encounter m.prop in some Flarum code today and realizing Flarum uses Mithril v0.2.8. Mithril is at v2.0.4 today and it raised some questions.

First of all, are there still plans for Flarum to catch up?

But more interestingly, I'm curious to ask how you lovely people at Flarum would go about doing this, as Mithril 2 is not backwards compatible and all of those Flarum extensions out there have some front-end code using old Mithril methods?

They did provide some tools to help migrating. From Migrating from v0.2.x:

v1.x and v2.x are largely API-compatible with v0.2.x, but there are some breaking changes. Migrating to v2.x is nearly identical, so the notes below apply mostly to both.
If you are migrating, consider using the mithril-codemods tool to help automate the most straightforward migrations.

But even then:

There are certain classes of changes that are impossible to automatically convert.

m.prop removed
m.redraw(true) removed
m.deferred() removed
onunload preventing unmounting

I'm just starting Flarum development, is it wise to try and avoid certain practices to futureproof my extension when it comes to Mithril?

    nxta We do plan on upgrading to Mithril v2. There's an issue on our GitHub for a Frontend Framework Rewrite (flarum/core1821), which I'm assigned to.

    I myself don't fully understand (yet) how Flarum uses Mithril for its Components (as it also includes a .render function that just returns the view, etc...) so my first attempt few attempts have failed. This was about a month ago, haven't had the time to try again.

    I do plan on making the rewrite as backwards-compatible as possible for extensions, but as that will probably not be the case, we will merge all those changes that include dependency upgrades and dependency changes at once.

    We also plan on adding TypeScript if possible, to allow for simpler extension development and to avoid common type errors, etc...

    is it wise to try and avoid certain practices to futureproof my extension when it comes to Mithril?

    Many extensions will break, I don't really know what functions we'll be able to keep and which ones we wont, so I wouldn't worry about that.

        A few general best practices I'd recommend, not only for ease of update later but also to keep the code cleaner:

        • Avoid calling m.redraw() if it's not absolutely necessary. All event handlers (onclick, onchange) trigger one automatically so it's often not needed.
        • Likewise, don't use m.props() where you can skip it (member variables in a component for example). As said above redraws are already triggered most of the time anyway. You still have to use them in models and such where Flarum expects props for now.
        • Extend Flarum's Component where possible instead of creating Mithril components. Mithril v0.x uses a controller/view system that changed in later releases. If you use a Flarum Component you can be sure there will be a documentation on how to update later if necessary.

        So, things will break and there is no way to fix that programatically.

        Does that mean migrating to Mithril 2 is something Flarum will save up for a major release, announce in advance and get developers to rewrite their extensions? How, if at all, have you dealt with similar issues in the past?

          nxta we were hoping to make that change before reaching stable to minimize disruption once stable is released.

          How soon it happens depends how successful we are with migrating Flarum itself to the new version. I'd say it's probably more work for Flarum core and core extension than it will be for third-party extension developers. We will have to update the core extensions ourselves so this will also give us an idea of how difficult it will (or will not) be for extension developers.

            Thanks a bunch for providing some insight