Very Interesting Project

[ProLoser]

Hey there, I just found this project and was checking out your examples. It's very interesting and I like a lot of what you've done here. I had some thoughts though if you didn't mind me being so bold:

Previous States

I actually think this feature should sort of be tossed out (it seemed by your notes that you are on the fence about this one yourself). It's a little wonky, super easy to implement manually, and kind of creates an unusual behavior.

For instance, if I hit the 'return' button multiple times, you would expect a browser-like behavior where you traverse your history. But instead we're jumping back between the last 2 states. If you chose to use a purely URL-based approach you won't run into this problem, and if you take a history-based approach it gets ridiculously convoluted.

To implement this manually, all someone would have to do is subscribe to $routeChangeSuccess and store the value at a globally accessible location.

You also hard-coded an onError behavior which might interfere with other peoples' implementation or desired behavior (although I can completely understand why this behavior is a good default). Frankly, I'd love to see the code stripped down to bare essentials and thrown onto the documentation as examples of things you can do.

Future States

I think this is kind of something you should just be capable of doing with the existing tools available in ui-router. This entire feature is kind of based around the fact that you're trying to do configuration after the config phase. There are already tricks to solve this problem, such as storing references to the provider and recalling those references when your lazy-loaded resources become available.

For instance:

app.config(function($stateProvider){
  app.$stateProvider = $stateProvider;
})
// sometime later...
app.$stateProvider.state(...)

If this doesn't work right now, I think it would be better to instead modify how ui-router works so that lazy-adding states wouldn't cause any hiccups whatsoever.

Sticky States

This is an interesting idea I've toyed with myself. I think 'sticky' is an odd name and 'parallel' makes more sense. I've actually toyed with this idea before by referring to it as something like detachable states or reusable states. It tends to be more relevant for modals. For instance, opening the login modal anywhere in the app, or under a subsection of states in the app. I need to toy with this idea though cuz I think it could make this very complicated for people.

Deep State Redirects

I actually think of THIS as 'sticky', but like 'sticky branches'. Like do you go directly to a tab, or do you go to where you were drilled down into that tab. I think of it as a flag when you do a transitionTo like setting sticky to true or resume to true. I should poke around your implementation, but if this was done in the core, I wonder having each state kept track of what it's last active immediate child (if any) is, and we leverage an async-loading of states as discussed here: angular-ui/ui-router#1170 could this feature get implemented in the core pretty efficiently?

Conclusion

Anyway, this is all just food for thought. Since angular-ui is always looking for active maintainers I was throwing out these ideas because if everyone was interested maybe you might like the idea of implementing some of this stuff in the core and helping out as a maintainer of ui-router?

[ProLoser]

Also pinging @timkindberg and @nateabele (if he wants to) for their thoughts.

[timkindberg]

We'd actually had a lengthy conversation with Christopher already (see angular-ui/ui-router#894) and it was decided that we weren't quite ready for these super freaking awesome features...

I'd be all for Chris stepping up as a head maintainer on ui-router. I've not seen anything from @nateabele in a while, though I know he still likes the project and is very busy. I also think he probably has some code he's working on, which is great, but also blocks others from contributing because of fear of merge conflicts.

Chris seems like he'd be a great person to carry the torch forward on ui-router if @nateabele is cool with it.

[snekbaev]

I've been "watching" the progress on this project and I can say it is impressive: documentation, fixes and response times, Chris is a maniac in a good sense :) meanwhile I was waiting for new ui-router release that addresses current issues, but seems that main developer is quite busy, I totally agree with @timkindberg that Chris could be the "one" :)
Thank you!

[ProLoser]

It seems it's up to Chris. But yes I agree that I would want to look at
considering merging these features in slowly (if at all).

What say you, Chris?
On Aug 8, 2014 1:36 PM, "Shukhrat Nekbaev" [email protected] wrote:

I've been "watching" the progress on this project and I can say it is
impressive: documentation, fixes and response times, Chris is a maniac in a
good sense :) meanwhile I was waiting for new ui-router release that
addresses current issues, but seems that main developer is quite busy, I
totally agree with @timkindberg https://github.com/timkindberg that
Chris could be the "one" :)
Thank you!

—
Reply to this email directly or view it on GitHub
#46 (comment)
.

[nateabele]

Hey guys, sorry I've been out of the loop for a while. So, here's my issue: the current UI Router codebase is not in anything resembling great shape, and several aspects of its design actively make many of the desires expressed by the user community (i.e. rendering templates before resolves complete, that's been a big one) more difficult to implement.

I'm very concerned that if we continue to build off of it without resolving these issues, it's just going to become more unmaintainable. That's why I wanted to deal with this before going hog-wild with new features. Otherwise we'll just be in a worse position over the long term.

Over the past few months, I've slowly been working on a rewrite of the internals which addresses all of UI Router's architectural issues, and provides us many oft-requested features for free. I kinda stalled out on handling how resolves should be indexed, so I could use some help there.

My rewrite still isn't fully functional, but it's pretty close. If you guys want, I can push that to a branch and we can start working on it, but once that's done, all this other stuff should come pretty easily.

[ProLoser]

@nateabele go ahead and push the branch. I personally wasn't thinking of having @christopherthielen immediately focus on implementing his features in the core but more of as future roadmap objects after making almost the exact same changes you discussed (such as async loading of sub-states). At the very least, I realized that @christopherthielen has already been quite active in the issues of the project and could perhaps help clean them up a bit if he's not interested in being a code contributor.

[nateabele]

Having a co-maintainer would be a huge relief, so @christopherthielen, if you're up for it, welcome aboard. Right now (in terms of code maintenance itself, obviously @timkindberg has been a huge help on docs and issue triage) I feel like it's just me against the world. Compared to other Open Source tech communities I've been a part of, the level of discipline in client-side JavaScript land seems pretty low, so there's been a lot of demand to meet. Also, while I have a rough plan for where we can take this thing, having a dedicated person around to compare notes and bounce ideas off of would be very welcome.

[christopherthielen]

OK, I'm in.

When I started working on UI-Router Extras, I just wanted a way for these features to get out there. I need them for a commercial app I'm working on, and there seems to be lots of demand. I see this project as a sort of rapid/early-access incubator for stuff that deserves more attention than my daily whims. Also see #45 / angular-ui/ui-router#1257 which is directly in response to the various transition service requests, such as angular-ui/ui-router#238.

@ProLoser Sticky States and Deep State Redirect came directly from my fork of UI-Router back in Feb. Your criticism of Previous State is spot-on. I made that in response to the flurry of request for "$state.previous" support as a stop-gap solution towards a history service. Future States tries to fill the gaps on post-config state loading, but also tries to enable lazy url-matching as well as provide an easier way to modularize large apps (ngload+requireJS) without jumping through a bunch of hoops.

@nateabele I'm glad you're still working on UI-router. I'm a huge fan of the project, but I don't know it well enough to do the one-man-army thing you've been doing, nor do I need that kind of responsibility.

I'm glad to be on board, let's do this.

[nateabele]

@christopherthielen Sweeeeet.

I'm a huge fan of the project, but I don't know it well enough to do the one-man-army thing you've been doing

Trust me, I didn't know it well enough when I started, either. ;-) Fortunately for both of us, I've been able to clean up and de-clusterfuck the internals quite a bit since then. My upcoming week is pretty slammed, but we should schedule a Hangout for next week so I can walk you through my refactor. It should be a lot more sane.

nor do I need that kind of responsibility

Well, many hands make light work, so two developers vs. one is already an order of magnitude better. Even so, though you're "on the team", don't ever feel compelled to commit to something beyond your means.

@ProLoser I need another hour or two (which I haven't had this weekend, unfortunately) to clean up my rewrite and push it to a branch, but I'll do that as soon as I can, and @christopherthielen will take it from there.

Thanks a lot for the support, guys. I'm excited to get back into it.