Where is this project heading ?

[telovo]

Maybe this is not the right place for me to be asking this question but my team would like to use the code that's here. However we are very concerned as we can't see a roadmap and the current version number does not inspire confidence.

Should we use the code? Will it be around in a year's time, will it be incorporated into AngularJS. I hope someone can give us some advice.

Thank you

[simalexan]

+1 for someone's answer.

[Undistraction]

+1

[rynz]

We're using it in production for a responsive web/mobile app and loving it.

[telovo]

Are you not worried by the version number v0.0.1 We are also testing out the code and it works great but our company has concerns if we use Version 1 of a product and this is not quite at Version 1 and I can't see any roadmap for the future.

[rynz]

AngularJS is practically in the same boat, v1.0.6 remember. Although, we're using v1.1.4 and when any API changes we just adjust our code. Google could just as easily stop supporting it like they have other JS frameworks in the past, there's always going to be risk with 3rd party code.

The beauty of UI Router is the code is pretty damn well documented and extends a lot of AngularJS' ground work, even if it's v0.0.1. From what I heard it's meant to gain attention of AngularJS @mhevery‎ and @IgorMinar‎ etc and hopefully become a standard state machine within AngularJS itself but for now it does the job and besides, there's nothing else out there that compares.

The complex apps we've written so far would have been very very tedious to do just with <ng-view>.

[IgorMinar]

We are aware of this project and support it. The Angular v1 routing system is reaching it's limits. As we are designing Angular v2, deep dive into UI Router will be our first thing on our list when it comes to routing. But first we need to ship v1.2!

I'm however interested in setting up a meeting to discuss UI Router some time next month. Would you be up for it?

[simalexan]

@IgorMinar, that's awesome ! 👍
I think that the Angular-UI team & its contributors should firstly respond and if there is place for us, other devs, I think that we all would love to attend.

[Undistraction]

The best answer possible.

[rynz]

Cheers @IgorMinar. I think @ksperling and @jeme are the leads behind UI Router.

[jeme]

This is mostly @ksperling's project as he has by far done the majority of the implementation here, I have only pinched in a little from time to time, mostly pulling smaller things over from my own router project (https://github.com/dotJEM/angular-routing)...

I would have hoped that in due time, I would have been able to bring more over from that, and I did allot of "rework" in angular-routing to get close to the interface of this project (namely going from a completely OO style API to this, angular-routing was actually published after this project though, as I had kept it in my private repo until then), but it seems that it would require allot of effort to bring them together, not to mention that they are sort of on a slightly different path (even after I changed my direction allot due to liking @ksperling's implementation from an interface perspective).

So I wouldn't really consider my self as a lead on UI-Router, just a regular contributor... Which just airs my opinions quite a bit, obviously because I have some experience from writing another solution as well as the need for a routing solution like this.

But I am happy to be part of this, and especially because the Core team takes interest in it... Which is why I recommend this project over my own.

Since @ksperling is the one doing about 99% of all things here now, I can imagine that things slowing down has to due with him becoming a parent :)...

At the end... should you use this at the risk of it suddenly not being maintained any more?... There is always a risk as @SparkiO says, assessing how big that risk is, is probably what you are doing.

But even if people stop having interest in this particular project, there is still chances that you won't have lost everything. Mainly because the overall idea about structuring views in this way won't die, so all your controllers and templates shouldn't suddenly be dead or stuck on an ever aging "platform", they are likely to be able to be brought over to whatever takes over after UI-Router...

That leaves the configuration code to be the only part that is truly lost... And that might not be entirely lost, it might be that anything taking over here is deeply inspired by it, so you just need to do smaller adjustments...

Worst case scenario is that you would have to start maintaining your own fork of the project. (which I see as a very unlikely scenario)

@IgorMinar Would love to participate in a discussion, I may have a trip to Texas mid June (1 week +/- a few days) and I have allot of release activities here in Denmark, so it might be hard to schedule, but as long as @ksperling is there, that is the important one to include :)

[ksperling]

I think the intention from the outset was that ui-router would be written in a way to allow it (or parts of it) to be picked up by Angular core. Unfortunately I haven't had as much time to work on ui-router lately as I would like -- and what time I've had has mostly been taken up with responding to issues here on github, rather than coding...

@IgorMinar I'd be happy to have a discussion about where ui-router is going and how we can align with core Angular.

In terms of a (fairly short term) road map, here are a few bullet points

• Factor out/rewrite 'resolve' logic into a $resolve service that handles (1) inheritance from parent resolve(s) (2) dependencies within a single resolve
• Have a separate $view service for defining what goes into ui-view tags. Will support an async interface along the lines of $view.load('myview', { template: ..., controller: ..., resolve: ... }), but will also need to support a synchronous interface that $state can use after having called $resolve itself (so that all views relating to a state can be updated atomically). One major conceptual difficulty is that the naming of nested views (how they get turned into "qualified" names) is fairly intrinsically linked to the state hierarchy.
• parameter handling needs to be revisited, to support reload=false per parameter and two-way binding between $stateParams and $location for those.
• implement $injector.bind() that binds injectable parameters via Function.prototype.bind and returns a plain function object, so that for callbacks like in $urlRouter or $state we don't have to either (1) use $injector.invoke() where 95% of use cases would prefer a simple callback with 1 parameter (which is also orders of magnitudes faster in performance critical code paths) or (2) force the 5% to contort their configuration logic into custom providers just so they can get at the necessary services they want to use inside the callbacks. I'm intending to do this one as a PR on core.
• nice things like $state.href() / related directives
• support for independent "components" with their own states that can be instantiated multiple times in the global (or a parent component) state hiearchy (see how do you handle state for a modal dialog ?  #123)

A number of these are probably going to involve breaking changes, even though I'm planning to start doing interim releases (bower-enabled) as people are already using the code anyway.

[kloy]

I adopted this project for an enterprise level product. In my opinion, anything opensource you adopt you should assume as some point you will own it or branch it to meat your needs.

In my experience (3 months now with this plugin) it has been great and has many benefits over angular's default implementation, especially for complex applications. The testing suite is pretty good and the code is fairly easy to understand and well commented. I have had to make a few modifications to meet my needs and they weren't difficult to make.

So.. go for it if it satisfies a need for your project.

[paullryan]

I agree with @kloy, assume that anything that you get from opensource may be yours to maintain at some point. However if the project is still active and hasn't diverged untenably far from your needs is best to stick with the official branch for two reasons. One you can give back to this community that is working to help you and second you get the benefit of the communities assistance in fixing bugs and keeping up-to-date.

As far as the ui-router is concerned I also agree this team has done a great job a creating a stable platform that even in it's alpha state is production capable as long as you understand that you're responsible for checking performance and load scenarios and running through nice thorough QC and QA procedures (which you should be doing anyways ;).

Also remember versioning and roadmaps for open source projects are up to the team creating that project and some are very generous about how they version things. The ui-router team is a bit more methodical about how they version and process issues which leads to a slower ramp up to a stable release but it also leads to a much much more stable master on the road to that official major release.

[nateabele]

@ksperling I have time next week to help with some of these. I was chatting with @timkindberg and we'd like to meet with you about putting together something like a guide for core contributors. Basically, it should contain enough information that anyone on the core team should be able to evaluate a pull request and reach the same conclusion as everyone else about whether to hit the big green button. :-) Hopefully this will help free you up a bit.

[ksperling]

@nateabele sounds great, should we organise a hangout on G+?