@ and named@ doesn't work on the same state views with resolve

Question

I have a state named 'index' that, depending on the ui-view on the page, display different information and have different templateUrl and share the same URL:

    $stateProvider.state('index', {
        url: '/',
        views: {
            'all@': {
                templateUrl: '/templates/partials/all/index',
                controller: function(){
                    console.log('main');
                }
            },
            '@': {
                templateUrl: '/templates/partials/home/index',
                controller: Controllers.Index,
                controllerAs: 'academia',
                resolve: {
                    templates: Preload.go(),
                    academia: ['Info', (Academia: Academia.Services.Info) => {
                        return Academia.get();
                    }],
                    plans: ['Planner', (Planner: ngPlanner.Planner) => {
                        return Planner.init();
                    }]
                }
            }
        }
    });

when the page is loaded with a <div ui-view></div>, it works as intended (matching the '@' rule). but when the page is loaded with <div ui-view="all"></div> it doesn't.

A plunkr showing the problem http://plnkr.co/edit/a2SWbB?p=preview

The resolve from the unnamed @ shouldn't interfere with the all@ view. The current resolve is being rejected because it doesn't belong on the current view (since there's no unnamed view when the page is loaded). Is it a bug, or am I doing something wrong?

Answer 1

At these days, the UI-Router implementation is driven by state management. And despite of the fact, that there are some voices/requirements to split the resolve of the views (well, not the parent view vs child view - but that is discussed below) ... I would say, current behavior in the Q&A described above is simply correct.

Firstly, what is the problem in above question? In general there are two or more sibling views, with their own resolve definitions:

views: {
    'view1': {
          ....
          resolve : { // could fail
        }
    },
    'view2': {
        ...
        resolve:    { // could fail as well
    ...

What is state?

A state is a cluster of settings, representing the state. (sounds like self proving statement, but I am serious). All the settings are about state definition, about one, specific state.

We can use more views to represent it (e.g. title and content).
We can use some resolve statements (for all sibling views, for some of them) to support these views.
We have still only ONE state.

And that's it. It is all or nothing. The state is one, one cluster of settings, which all of them must be workign/resolved - or the whole state is failing.

Another story: parent - child

There are also some requirements to let the parent view to render once all its stuff is resolved. Why? Currently, if we navigate directly to child state, all/both resolves must be resolved before the state is initiated, the views are rendered.

That could be really improved. Make sense. And as far as I remember it is planned to happen in later releases (I'would swear I've seen that in one of the comments by UI-Router team member - but cannot find it).

It is different scenario. Because 1) we can go to parent (list view) first. And then 2) select child (detail). In this scenario it could really happen that list is working, detail fails.

So going directly to child should render parent, next fail on a child... But this is different story then the sibling described above.

Suggestions:

My suggestion would be, keep in resolve only stuff which is essential, absolute MUST for a state. Move the rest into Controllers injected services. This is my suggestion and my way...