[nateabele]

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.

[rubicon33]

By component router, are you referring to the stock router in Angular? If so...

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.

[jbigelow76]

By component router, are you referring to the stock router in Angular?

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.

[nateabele]

If you hold out on refactoring to UI Router until 1.0 is released, I'm pretty confident at this point that I can promise you a smooth upgrade path well into the future. (Come to think of it, I'm still pretty confident even if you start now on 0.2.x).

[websirnik]

When UI Router 1.0(beta/stable) will be released?

[nateabele]

Well, we're pretty close to an alpha release. [0]

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

[bubersson]

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) and in generating/validating ui-sref links. I don't know if this will get linearly worse with increasing size of application, but anyway this is why I'm interested in checking out Component Router.

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)...).

[nateabele]

Great questions, thanks.

> 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....

[christhielen]

Another ui-router dev here. I've also never profiled transitions for performance (frankly, I don't think I've seen it mentioned before). I'd love to hear anything else you recall about your findings.

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?

[twrkit]

Just wanna say, huge fan of UI Router, thank you so much for your hard work! Makes my life so much easier :)

[nstokoe]

Same boat here. Really like UI Router. $stateParams saves me so much time.

[mdngtcdr]

Hi, I've been using AngylarJS & UI-Router for about 2 months. It's great. Some of the shortcomings that struck me were-

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).

[christhielen]

Hi, ui-router dev here. 1.0 is adding a global transition error handler which you can customize. The handler will be noisy by default (log to the console).

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

[nateabele]

> 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?

[WhitneyLand]

My vote is for the Angular team to stay away from ui-router because you are difficult to deal with, based on multiple discussion threads I've seen 'round the net.

Your code is good but not sufficiently better than component router to justify the friction.

[nateabele]

You're right. Sorry about that.

Either way, thanks for the compliment on the code. :-)