Hey, UI Router lead dev here. I'm interested in any & all feedback people have regarding Component Router vs. UI Router, what they like/don't like, and whether or how much they'd like to see UI Router support for Angular 2.
UI Router is basically what made Angular viable for 2 massive projects I've done. How it isn't a core part of Angular yet, blows my mind.
Component Router will be the stock router in Angular 2, it is supposed to fix most of the problems with the Angular 1 router.
I've personally held off refactoring my Angular 1 routing code to UI Router because I didn't want to do it again once Component Router is released for Angular 1.3, oops I meant 1.4, oops again I think I mean 1.5. But I am starting to reconsider.
After that, it's just a matter of users testing it and telling us what's broken, and us fixing it. A few weeks, maybe?
[0] https://twitter.com/ChrisThielen/status/638040557718126592
Do you have any pointers to differences between Component Router and ui-router? I'm especially interested in pitfalls of both.
I haven't debugged ui-router much yet, but maybe I'm doing something wrong (which sometimes happens in Angular world, e.g. when people use $timeout(fn), when in given situation they should actually do $timeout(fn,0,false)...).
> We started using ui-router recently and from quick profiling of rendering it looks like a lot of time is spent in ui-router transitions (chained promises)
I've never profiled transitions specifically, but the number of promises is generally determined by (a) how many templates you have in a target state, and (b) how much asynchronous data (resolves) each state loads.
> and in generating/validating ui-sref links.
State names themselves are validated once on initial template load. If the target is parameterized, we do set up a $watch() on the parameter values to update the href, which is a small incremental perf hit per use (and you'll naturally tend to get more churn the more deeply-nested the scope in which you use them is).
> Do you have any pointers to differences between Component Router and ui-router? I'm especially interested in pitfalls of both.
The biggest differences that I'm aware of are:
- Component Router supports components (naturally), which UI Router does not (this is on the roadmap)
- Component Router's transition pipeline appears to be more flexible than UI Router's (we're refactoring heavily to encapsulate & expose more APIs)
- As with ngRoute, Component Router's configuration binds view components (or controllers/templates in ngRoute's case) directly with URLs, whereas UI Router provides a more sophisticated abstraction in the form of a hierarchical state machine, which many people find more ideally-suited to large, complex apps (see other comments)
- UI Router provides more sophisticated abstractions for encapsulating and modeling your domain in terms of URLs, for example, Type objects [0]
> I haven't debugged ui-router much yet, but maybe I'm doing something wrong
Let me know if you encounter any specific issues, or post to StackOverflow. One or more of us are usually fielding questions there.
[0] https://angular-ui.github.io/ui-router/site/#/api/ui.router....
As for the ui-sref, there should be only one watcher per, and should only really impact perf if the target params change. Does that align with what you remember seeing?
Lack of "routing state" - integration with the history API or means to go to "previous" state etc.
No clarity in handling errors from "resolve" - Since there is no controller any failed AJAX request fails silently.
Ability to pass data (not params, more like a model) between states. This I think sparks the debate of having services to share data. But there are use cases wherein you would want to transition to-fro controllers (eg. multi page form).
This is interesting. Could you post a GitHub issue describing your use case and an pseudocode example of how you'd see it working?
To send data in a transition, add a non-url param to the target state. We added objects-as-params (url based or not) in I think 0.2.12
Your code is good but not sufficiently better than component router to justify the friction.
Either way, thanks for the compliment on the code. :-)