I’ve been writing my apps recently without a router… ReactiveDict gave me all the state control I needed. However, it came at the price of back-forward navigation and linkable URLs. Routing solutions looked complicated, so I thought, why learn someone elses when I can learn to make my own?
The idea for this started as simple router that just runs a callback on a URL and then lets the developer figure out what they want to do. The result is a router that basically executes each URL as a function, and something that stores a ReactiveDict on the URL.
It’s feels really simple and thin. If you’re build an app, I encourage you try it and would love to hear what you think
I’ve also been asked, what about rendering views? Well, I’ve been writing my own logic around {{Template.dynamic}}, but have an idea for a layout manager that should come out soon
[quote]
I feel like everything starts out “simple and thin” but then grows in features forever. I’ll be interested to see if it stays simple.[/quote]
Indeed - that is an entire art. In this case, I’ll be breaking out the layout manager into its own package, and the two will have a really easy integration.
I really like this approach. Particularly for single-page applications that preload all the working templates onto the DOM. I’ve long noticed that animations work fantastic if you render all your templates first, then apply origami folding using Session variables. Which is the approach this appears to be getting at.
All the current Routers… they suffer from this notion that the DOM should always be as small and light-weight as possible, so the entire idea of routes is to add/remove templates to a layout manager. Which borks animations every which way.
Bingo, bingo. For an animated, single-page apps, you really need to hold state on the URL otherwise things will break when people reload the app, navigation back/forward, try to share URLs, etc…
As far as incremental loading… I think you really should have your templates loaded up front on a why-not basis. That’s why I really like Ember’s fast boot approach: it loads just whatever it takes to get the view up, then loads all the rest.