Design Thoughts

[cmather]

I gave a closer look this evening. Everything seems to be working pretty well. But I have some design thoughts that may simplify things and enable taking advantage of named yields.

I thought about it in terms of how the behavior of Router needs to change to support this functionality.

1. autoRender needs to be turned off so the transitioner can control the rendering (this actually tripped me up for a second because I forgot to do this and the transitioner still kind of worked but then i realized the router was being rendered into the body).
2. onRun needs to support transitioning from one page to another

Currently, you're grabbing the current route context and the value of the __main__ yield in order to reactively do a transition. Since your computation dependency is added after the main Router's, presumably the route gets handled and then your function runs. This seems to work okay. But I guess we do lose the named yields capability, and it would be nice to be able to define transition options (if there are any) directly in the route definition. What if instead, you made a TransitionRouter that inherits from ClientRouter. It basically does two things:

1. Disable autoRender
2. Override onRun to respond to new route changes

I'm still thinking through the rendering logic - there's probably something slicker we can do here. But assume for now that you manually control rendering of the router on each transition, and you've statically set up the transition divs, just like you have them now.

client_router.js

onRun: function (context, options) {
  // 1. Decide which pane to render the new route into
  // 2. Render the router into that new pane by calling the render method of Router inside a Spark or Meteor.render

  // run the route and render into the new area (presumably hidden area)
  ClientRouter.prototype.onRun.apply(this, arguments);

  // 3. now, apply the classes to the old and new panes to do the transition

  // 4. when done, do a Spark.finalize on the previously rendered area

  // 5. boom.
}

[cmather]

You could also make it such that when someone adds this package, the Router global just becomes an instance of the TransitionRouter. Then the user deals with it the way they normally would.

[tmeasday]

The thing is that:

• what if you want to transition between the "parts" that are rendered by onRun -- e.g. from loading to the real page?
• often you want to transition within your layout e.g. the menu remains fixed as the transition happens.

That's why I chose __main__ as the point of transition. I'm actually using a second layouts package within __main__--I imagine people will often want this too, but I figure it's a stopgap until UI drops.

For this reason, I'd guess that onRenderMain is the right point of attachment. But the tricky part is that that gets re-called when data() changes, and I don't think you ever want that to trigger a transition.

I'll comment on the other bit on the other bug.

[tmeasday]

Hey @cmather,

Started work on a IT refactor to reflect our discussion about layout controllers.

The code so far is here: https://github.com/tmeasday/iron-transitioner/blob/refactor/transitioned_router.js

It doesn't actually work yet, just wanted to get your thoughts.

Interesting points of note:

• I went with two LCs because it seems to make more sense to me to have two sections of the screen that are rendered to by LCs and have the Router multiplex between them. Let's discuss this.
• The code is significantly less complex as I can use the existing Router autorun and not have to set up (2 of!) my own. This is assuming it works of course.