2

Mithril's website states:

You can only have one m.route call per application.

So I was almost able to do a work around with code splitting.

But my application is only aware of the first-level components for a given URL which it utilizes the async code splitting to accomplish.

Now the problem: Those first-level components would then like to register their own namespaced routes to leverage URL state change for their own inner components since I can't register their routes ahead of time (and Mithril prevents setting the routes again after the initial route was set by the app/wrapping component).

To further the complexity of the issue, each first level component is loaded on an as-needed basis, so I can't wait for all the first level components to load and then instantiate the m.route; routes have to be added dynamically.

I love this framework, but my use case seems like an edge case that I can't seem to resolve.

The simple solution would be to re-instantiate the m.route object after each first-level component loads, but that's not supported.

UPDATE

The purpose of my post was to find a native way to do dynamic routing and not lose functionality (such as variadic routing), but its been reinforced that that's not possible.

I replaced the entire router with an in-house one so I could support dynamic (and unknown) routes, more flexible variadic routing, better params method, and even provide get/set global data across views without a global window variable or use of the History API in that case. I still provide the rest of the functionality that Mithril does, just a little more simply.

Why not do a pull request? From what I've read on different Github pages, two big pieces of this would not work with the core logic of Mithril; and/or, is too much of an edge-case that they don't want to support it.

I'll still choose Mithril over any other framework though.

In the meantime, I built what I need, and hope Mithril 2 will have dynamic routing baked in.

Modular
  • 6,440
  • 2
  • 35
  • 38
  • 1
    Perhaps you can create a workaround using [params](https://mithril.js.org/route.html#mrouteparam)? Could work if you only need to support a limited number of slashes in the url, although it might become a bit messy. – ArneHugo Oct 27 '17 at 10:35
  • 1
    @AmeHugo Yeah, I've written my own router a couple times over, but I was really hoping to not step outside Mithril for something it does so well in most areas. – Modular Oct 27 '17 at 15:27

2 Answers2

1

Mithril's router is intended as a relatively simple solution to easily enable standing up simple SPAs, dynamically registering routes isn't part of the current design.

I think you'll probably be best served by finding a router that supports the dynamic route registration you require and using that.

Integration of that router with Mithril could be naive (using m.mount() when routes change) or more complex by emulating a bit of the logic of the existing router API.

Tivac
  • 2,553
  • 18
  • 21
  • Yeah, those are both alternatives and what I've already done in the meantime, but I really don't like to step out of Mithril when the built-in routing works well for most everything else. I was just hoping someone has run into this and found a good Mithril-centric solution. – Modular Oct 27 '17 at 15:29
1

Mithril's router is not the most advanced tool. Although you can work around it pretty much however you want.

There is a way to make new routes dynamic. I made a little jsfiddle a while ago. https://jsfiddle.net/Godje/cpzLtoyz/

You are interested in lines 2-11 and 63-92.

Although they aren't dynamic in the fiddle, you can make a function, to replace that switch on line 73, which will process your routes and return a component needed to be rendered. That way if you have an array stream with all the URLs or other routes you want, you can have a function process each param on each route-change call and check it with the array.

Sorry for a messy response. Writing an exact solution to the problem requires a local server.

Godje
  • 404
  • 5
  • 15
  • I built a replacement router last year, with the base concept similar to what @Tivac and you suggested. I like how you stuck with built-in methods to get some of the other data needed. The downside is losing the variadic routing, but nice work. – Modular Feb 26 '18 at 15:55