Integrate with angular-ui router.

[kentcdodds]

As John Lindquist put it: needs some ui-router love.

[geddski]

I haven't used ui-router, would be happy to investigate if there is enough interest.

[kentcdodds]

Currently I have no use for it in my projects. (Not big enough to merit overmind or we're using ngRouter). But maybe there are others. I'd say a large number of big applications use the superior ui router. But definitely wait to see who's interested...

[evillemez]

I'm definitely interested in ui-router support. Most of our projects are using ui-router because we often don't use "url" routing at all (websocket apps).

This is neat, I'd sketched out a similar approach to addressing lazy loading parts of an angular app, but haven't pursued it due to lack of time. Glad to see interest in that area!

[m4r71n]

:+1:

[skuester]

+1

[geddski]

ok cool I'll take a look.

[boneskull]

:+1:

[jbadeau]

Awsome

[kentcdodds]

Looking at it, I'm thinking you may have two different builds of overmind to make this work. One which depends on ngRoute and other that depends on ui.router. Then they'd each inject $routeProvider or $stateProvider respectively and listen to $routeChangeSuccess and $stateChangeSuccess respectively...

I don't think there's a way to do it in a single file... I'm thinking you'll have to have a build process go in to generate overmind.ng-router.js and overmind.ui-router.js based on overmind.template.js or something like that...

[kentcdodds]

However, I think there's a way to ask angular which modules exist on the page. So we could wrap the overmind in a function that accepts a parameter of which to use, then it'll be able to use the correct stuff based on which module is on the page. I may have time to look into this...

[boneskull]

The only way I've found to assert a module exists is this:

try {
  angular.module('foo');
} catch {
  angular.module('foo', []);
}

var myModule = angular.module('bar', ['foo']);

So you'd run this try/catch for both modules, require both of them, and do your initialization in myModule.config().

[evillemez]

I wonder if it would make more sense to not bind to router implementations at all, and instead use a provider for declaring "app" instances, and choose which app to load a little more explicitly? It may be an extra step for the developer, but it seems considerably less complex and we wouldn't need any router specific implementation logic.

angular.module('rootApp').config(function(overmindProvider) {
  overmindProvider.registerApp('admin', {
    module: 'childApp'         //the angular module to bootstrap for the child app
    inherit: true                    //optionally inherit stuff defined in the parent app injector
    //...other stuff, paths to files, etc...
  });
});

<overmind app="admin"></overmind>

[kentcdodds]

I would welcome a PR where that works, and maybe @geddski can correct me, but from my time in that code, I don't see any way to make this not dependent on how router implementations work. It's pretty intertwined. But like I said, that would be awesome...

[evillemez]

Yeah, it would be a considerably different approach, enough so that it might just be a rewrite, so I'm not sure it's worth pursuing. Do you think it's worth exploring in a different branch?

[kentcdodds]

If it could be done, I think it would simplify things greatly. I'm in the middle of trying to implement this to work with ui-router and it's been a bit more effort than I thought. I can only imagine what happens when 1.3 gets the backported Angular 2.0 router... :-/ That's definitely something to think about.

[evillemez]

That's a good point, router implementations are likely to be a moving target in some cases. Should we start a new issue for this?

[kentcdodds]

@evillemez, perhaps a new issue would work. In my fork I now have a branch for ui-router-support (hit a small snag, but I'm close there) and I'm working on another one to make it router agnostic as well... Sad part of the router agnostic approach is you'll have to provide overmind with a lot more info for it to bootstrap your module's view I think... Still looking into it.

[kentcdodds]

Made an issue to track router agnostic approach.

[kentcdodds]

@geddski and @evillemez, would love your input on #7...

[iamlasse]

The issue of Routing seems like an outdated way of designing web apps etc. With more and more apps being client side focused or decoupled from API the transition to states seems more "web. 2.0" than standard routing. Also the ability to have several views sections (UI-router) is a great feature.

[geddski]

Will take a look over the weekend.

[kentcdodds]

If it's helpful, you can take a look at how far I got on my branch. I was really close:

https://github.com/kentcdodds/overmind/blob/ui-router-support/src/overmind.js

Like I said, I was having trouble with $state.reload (note: all router stuff is injected with the ngRoute names to keep things consistent, but I'm using the array syntax to dynamically inject the router-specific object, the different names are defined at the top). Let me know if you like my approach and have any questions about it.

[TylorS]

Definitely interested in ui-router

[ubenzer]

+1, Interested.

[schmod]

This is interesting, although I'm not entirely sure if it would be possible to decouple Overmind from any routing system. At first glance, Overmind looks more like it could evolve into a drop-in replacement for a traditional routing system.

I use ui-router, and greatly prefer it to ngRoute. However, it's certainly not without limitations, and it'd certainly be interesting if you could provide additional isolation to nested states.

I'd rather fix and extend ui-router than replace it...

Perhaps it makes more sense for Overmind to evolve into a module loading framework that provides hooks for plugins to integrate with ui-router and ngRoute.

[iamlasse]

I second that idea. It seems like its a great loader I know in larger projects this would be amazing to decouple as much as possible and only having to load the initial files. But replacing the router seems like a tricky idea as everyone has their preference in whether to use ngRoute or ui router. Also using the word overmind seems to not follow the conventions of angular. What if you could just link into the ui-view or ng-view? And the overmind code sits as a layer in between. On Aug 4, 2014 8:32 AM, "Andrew Schmadel" notifications@github.com wrote:

This is interesting, although I'm not entirely sure if it would be possible to decouple Overmind from any routing system. At first glance, Overmind looks more like it could evolve into a drop-in replacement for a traditional routing system.

I use ui-router, and greatly prefer it to ngRoute. However, it's certainly not without limitations, and it'd certainly be interesting if you could provide additional isolation to nested states. I'd rather fix and extend ui-router than replace it...

Perhaps it makes more sense for Overmind to evolve into a module loading framework that provides hooks for plugins to integrate with ui-router and ngRoute.

— Reply to this email directly or view it on GitHub https://github.com/geddski/overmind/issues/2#issuecomment-51075834.

[geddski]

@schmod I like that thinking

[geddski]

@iamlasse if we use the ng-view name then the ng-view directive would get linked and mess with everything. Over mind name comes from StarCraft - it's the brain like alien creature that controls the swarms of zerg. Nerdy I know :)

[iamlasse]

Haha no I get that. It was more to avoid using new terminology. For instance if you use ng-view directive the script would recognize and execute according and same for ui-view and maybe others in the future? Or like Andrew mentioned create plug-ins that sit between overmind and the routing system. On Aug 4, 2014 9:28 AM, "Dave Geddes" notifications@github.com wrote:

@iamlasse https://github.com/iamlasse if we use the ng-view name then the ng-view directive would get linked and mess with everything. Over mind name comes from StarCraft - it's the brain like alien creature that controls the swarms of zerg. Nerdy I know :)

— Reply to this email directly or view it on GitHub https://github.com/geddski/overmind/issues/2#issuecomment-51083132.

[SamLebarbare]

+1, Interested.

[riddla]

+1

[kencaron]

+1

Currently using ui-router's resolve for my lazy loading, but would be interested in checking this project out.

[dgtlmonk]

+1

[cpursley]

:+1: for ui-router support.

[pviniciusfm]

+1

[goleafs]

+1 for ui-router all day long!!

[jbadeau]

Any progress here?

[kentcdodds]

Unfortunately, I haven't made much progress beyond where I got before. I was pretty close though. Feel free to checkout my fork

[datanotion]

+28 (everyone in my group wants it)

[geddski]

Don't think I'll have the time to make another implementation for ui-router, but I will support the new Angular router coming in 1.4 (March).