Iron Router works with Meteor 3!

packages
1

Hi,
we managed to get Iron Router working with Meteor 3.
Beside updating all the package reference to the lastest version, 2 items needed change :

7 Likes
2

Great effort! I had also been working on updating iron:router, but you’ve beaten me to it.

I have a suggestion, perhaps you might find it a hassle, but it would be helpful if you could recreate your GitHub repositories as forks of the original iron:router packages. That way it would be possible to see the exact diffs from the original packages.

3 Likes
3

Thanks. Yes I will look into doing it form a fork, I only learned yesterday that this is the preferred way. I will inform you when the forks are available.

1 Like
4

Hi
I have created 5 pull requests from these forks
[GitHub - polygonwood/iron-router: A client and server side router designed specifically for Meteor.]
[GitHub - polygonwood/iron-layout: Dynamic layout with support for rendering dynamic templates into regions.]
[GitHub - polygonwood/iron-dynamic-template: Dynamic templates and data contexts.]
[GitHub - polygonwood/iron-middleware-stack: Client and server middleware support inspired by Connect.]
[GitHub - polygonwood/iron-controller: Controller class for dynamic layouts.]
with the changes that were needed to make it work with Meteor 3.0.2 (that’s what I have put now in minimal version)
Probably this is not ‘complete’, e.g. I remove a test referring to Fiber in the Middleware stack, this is now perhaps broken, someone with deeper knowledge will have to look into this.
I have an application that uses most of Iron Router functions, both client and server routes. Client routes with multiple controllers and subscription management. So far I don’t see any issues with it in running in 3.0 environment (I’m not half way my refactoring but all pages and forms are alive).
How can I stay informed on what will happen with this ?
regards
Ronny from Polygonwood

1 Like
5

I reviewed your code and it’s very close to what I implemented in my fork. One change of yours I can’t get my head around:

let go = Meteor.promisify(function (stack, self, done) {
    stack.dispatch(url, self, done);
    console.log('RouteController.prototype.dispatch');
  }, self, true);
  go(stack, self, done);

Meteor.promisify() turns a callback into a function that returns a promise (an async function), however with the change you have made I would expect you to also have needed to do the following:

  1. Use go(stack, self, done).then() to ensure the promise is fulfilled OR
  2. Have the await keyword before go(stack, self, done), which would also require RouteController.prototype.dispatch to be a assigned to an async anonymous function

Is my understanding correct or is there something I have overlooked?

6

Hi
In normal situation you’re fully right. But the Iron Router code in it’s original version just fires off the dispatch call without any follow up on possible return value (the comment sais ‘it runs in it’s own fiber so we can’t do anything with return value’). We could write out some console logging based on the outcome of the call, but as long as the package doesn’t deal with the result of this call, it’s basically not needed (if you are not interested to wait for or event for the result of an async call you can indeed just let it ‘go’. I have no understanding of the internals of Iron Router, I just gave it a try to get it ‘fixed’ to avoid a heavy effort (now) on getting my application running in 3.0. Maybe over time I will still re-factor to alternative solutions if Iron Router remains unmaintained, but for now it seems to work as before.

7

Amazing work :clap:

Just added it to the list, sorry for the delay!

2 Likes