Hi @arunoda, thanks a lot for your awesome work with FlowRouter. I’m curious about one very specific use case that is very important for modern apps in my opinion: Transitions.
Currently with routing the issue is that you immediately swap out content upon requesting a new route. In order to be able to properly transition between two pages you need both contents/pages available at the same time, which currently is not possible with FlowRouter. (I’m not just talking about basic fade-animations here, material design like animations where one element might fade to become a new page)
I’ve been hacking together my own version of this (not as a package), it’s still a bit buggy though. Do you have plans for making this possible in the future?
You don’t need to do the animation package/functionality yourself. Imo the only thing to do proper animations/transitions is to have both routes available at one point instead from FlowRouter. Right now you have:
Route a available
Route b available
It should be like this:
Route a available
Route a+b available (to transition between the two)
Roube b available
The way I’m doing it right now is using two different dynamic templates and always keep the current and new route in my document. Or that’s how I used to do it. It worked, just had a few issues with how I programmed it I guess. I’m not sure how easy it would be to help out with FlowRouter.
Specifically in my use case I’m using Polymer for page transitions. You have something like:
And you swap the content when needed. But with FlowRouter something like this doesn’t work because you only can have one route-view active. Essentially what is needed for this approach is to keep the old current route until a transition has been finished (then removing the entire template from the DOM would be the best case of course.)
Here’s a sample animation showing why this is necessary. To do a smooth transition that goes from element a to element b you definitely need them both available in the document. (click on any of the rectangles)
So, you need to both the old route and new route. So, pause the routing until the animation is complete and then resume the route.
If that’s the case, I think that’s not something we can do. Since FlowRouter does not wait. I always think this can be implement as a special animation component. Where it tracks all the template changes and do transitions. So, router is only just a trigger.
The way I do it is I track the change myself in a “director” container component, which keeps track of which route I’ve come from, and am going to. This allows me to tightly control when things are mounted and unmounted, and set all the necessary props to make sure the in and out animations do what they are supposed to do.
This works well with a very specialized set of transitions, where specific items on the page need to know where we are coming from and going to. It also keeps my routing information super clean - I don’t need to know that we are between pages, just what the next page is (for both forward and back navigation).
Their are generic packages that can track and manage mounting/unmounting before and after animations (React Motion and Velocity-React), which is similar to what React Router does.
I prefer Flow Router, because I prefer to not have the router and/or animations packages do the mounting and unmounting for me. It’s easier to manage that stuff directly in my containers than to work around the quirks of disparate managers doing things with their own generic algorithms.
But I also do crazy stuff like sending all my routing data through Redux.
How will fast-render know what subscriptions to send without Route level subscriptions?
Even in the current docs (2.x) there is a contradiction with regard to using route level subs, as the general thrust of the readme is to avoid route subs, and use template level subs instead, but then it also says fast-render needs route subs to work.
I’m also curious if there is any plan to enable any kind of code splitting, which I would really like to see (so I don’t have to send an admin payload to every client).