Coder Social home page Coder Social logo

angular-ui / ui-router Goto Github PK

View Code? Open in Web Editor NEW
13.6K 486.0 3.0K 13.24 MB

The de-facto solution to flexible routing with nested views in AngularJS

Home Page: http://ui-router.github.io/

License: MIT License

JavaScript 2.02% TypeScript 97.84% Shell 0.13%
angularjs ui-router javascript typescript routing router state-machine state-tree

ui-router's Introduction

AngularUI Router  Build Status

Note: this is the Angular 1.x source for UI-Router version 1.x. If you are looking for the source for UI-Router version 0.x, it can be found here


The de-facto solution to flexible routing in angular


Tutorials | API Docs | Download stable (or Minified) | Guide | Sample App | FAQ | Report an Issue | Contribute | Help! |


Angular UI-Router is a client-side Single Page Application routing framework for AngularJS.

Routing frameworks for SPAs update the browser's URL as the user navigates through the app. Conversely, this allows changes to the browser's URL to drive navigation through the app, thus allowing the user to create a bookmark to a location deep within the SPA.

UI-Router applications are modeled as a hierarchical tree of states. UI-Router provides a state machine to manage the transitions between those application states in a transaction-like manner.

Get Started

Resources

Videos

Reporting issues and Contributing

Please read our Contributor guidelines before reporting an issue or creating a pull request.

ui-router's People

Contributors

0x-r4bbit avatar adambabik avatar alexandrbaran avatar cesarandreu avatar christopherthielen avatar cvn avatar cyrilf avatar dependabot[bot] avatar eddiemonge avatar fpipita avatar gigadude avatar greenkeeper[bot] avatar greenkeeperio-bot avatar hshn avatar jeme avatar jhicken avatar ksperling avatar mikef438 avatar mrngoitall avatar nateabele avatar philbrown avatar pkt-zer0 avatar proloser avatar sbezkostnyi avatar scooper91 avatar timfjord avatar timkindberg avatar wawyed avatar wesleycho avatar ysbaddaden avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ui-router's Issues

High-level method for state transitions

transitionTo() is a fairly low-level method in that it expects a "fully qualified" state and all parameters to be passed in. I want to add a higher-level method on top of it for everyday use where you can do stuff like

  • Keep the values of existing parameters and only specify what changed
  • Have some short-hand syntax for identifying parent or sibling states, maybe something like
  • This syntax needs to work well from JS code and from within Angular expressions in a template -- from code having a state name (or short-hand), and a hash of parameters as two separate arguments seems fine, but I'm not sure how that would look within a directive (see next bullet point); I suppose the parameters could be a separate named attribute of the directive.
<!-- Maybe '@' could be short-hand for ($state.current.name + '.') ? -->
<button ng-click="$state.go('@edit')>Edit</button>

Resolve called twice

Using the sample app you provide :

.state('about', {
          url: '/about',
          resolve: {
            something: function() {
              console.log('about');
            }
          },
          templateProvider:
            ['$timeout',
            function ($timeout) {
              return $timeout(function () { return "Hello world" }, 100);
            }],
        });

console.log is called twice.
It doesn't happen when using views property on state though :

state('contacts.detail', {
          // parent: 'contacts',
          url: '/{contactId}',
          resolve: {
            something: function() {
              console.log('only called once');
            }
          },
          views: {
            '': {
              templateUrl: 'contacts.detail.html',
              controller:
                [        '$scope', '$stateParams', 'something',
                function ($scope,   $stateParams,   something) {
                  $scope.something = something;
                  $scope.contact = findById($scope.contacts, $stateParams.contactId);
                }],
            },
            'hint@': {
              template: 'This is contacts.detail populating the view "hint@"',
            },
            'menu': {
              templateProvider:
                [ '$stateParams',
                function ($stateParams){
                  // This is just to demonstrate that $stateParams injection works for templateProvider
                  // $stateParams are the parameters for the new state we're transitioning to, even
                  // though the global '$stateParams' has not been updated yet.
                  return '<hr><small class="muted">Contact ID: ' + $stateParams.contactId + '</small>';
                }],
            },
          },
        })

Vote on moving forwards

I'm happy to see @ksperling and @timkindberg have been moving this along.

I started this project because I wanted a routing solution that AngularUI could officially stand behind rather than have 20+ solutions that I couldn't really support or suggest to people.

That being said, I briefly spoke to @nateabele and he seems to think you guys are heading in the right direction.

I have 2 proposals:

1. We vote on if this is the proper direction

@ksperling and @timkindberg if you'd like to briefly summarize the new proposal here for everyone.

Since I haven't been able to dig into the solution yet, I'd like the community to decide if this is the right direction

If it is...

2. We move the project to AngularUI (?)

This of course may be rejected, as everyone is entitled to own their own project.
However I would like to have an official AngularUI project for routing that we can help review and collaborate on. @ksperling as with all AngularUI projects you would still have control over and be able to manage the project, but this way we can get a bigger team on board to actively help you once this solution takes off.

We would be able to help clean up the project and bring up code quality standards as well as tie it into the AngularUI which will help with getting the word out!

Add option for reloading controller when state URL parameters change

If you have a .state('mystate', {controller: 'MyCtrl', url: '/a/{id}'}), then navigating from /a/1 to /a/2 does not trigger a controller reload. This appears to be by design (

if (locals === viewLocals) return; // nothing to do
) and is desirable in many cases. However, in some cases, I'd like a URL param change to trigger a controller reload, as it does using the AngularJS $routeProvider. (This allows controllers to perform initialization in their body instead of having to wrap their state params in watches.)

I can think of two ways to implement this: a $state.reload() function, or a reloadOnParamsChange param to state (similar to reloadOnSearch). I can submit a PR that implements one of these if you think that is the right approach. If I am approaching this wrong, please let me know.

BTW, great project! Thanks!

Sample app is not working

I see the following error in the console:

Uncaught SyntaxError: Variable '$ViewDirective' has already been declared angular-ui-states.js:974
Uncaught Error: No module: ui.compat angular-1.0.4.js:1060

This error also occurs for my own app when I try to use ui-router.

I get this error on Chrome Canary on Windows 7 64 bit. Firefox stable on Linux Mint works fine.
I get the same error as above when I try to run my own app with ui-router on Chrome Canary.

Commenting out the forward declaration of $ViewDirective gets rid of the error in the console, but nothing seems to happen in my app - no views get populated or controllers instantiated, etc.

Abstract States, Non-Abstract Parent States and Default Child States

I know we went back and forth on this several times already, but I think I may have found a need for this feature again.

It seems as though we are trying to get to a place where states can function completely on their own without any url routing (correct?). So how would we know which child state to load automatically without specifying a url of ''? Seems like we would need a default boolean property or something similar.

Let me also attempt to define abstract states, and non-abstract parent states. Please let me know if I'm on the right track.

Abstract State

  • must be a parent state
  • a state that cannot be activated directly (via transitionTo method) without activating one of its children.
  • must have a default child state (either with empty url or default property)
  • if no default child state is set, first child state found will be used as default
  • can be navigated to via url, but this really just activates default child state

Non-Abstract Parent State

  • a normal state which has child states
  • can be activated and navigated to directly (via transitionTo method or url), though any view directives will not be populated until navigation to on of it's child state OR one of its child states is set as default child (either with empty url or default property)
  • default child state is optional

Pseudo Code

@ProLoser: It's interesting reading your solution, as I was working on my own, which is quite similar. I didn't want to pollute #1 with my code ideas below, so I thought a new topic to discuss the interface might be helpful. Personally, once I know how I want to start using something, it makes it a lot easier to understand how to go about implementing it.

So, here's what my idea looked like:

.when('/long-form', {
  templateUrl: 'views/long-form.html',
  controller: 'LongForm',
  resolve: 'getSomeData',
  andWhen: {
    '/:step': {
      templateUrl: 'views/long-form/step.html',
      controller: 'LongFormStep',
      resolve: 'getSomeMoreData'
    }
  }
})

These andWhens can be nested deeper, following the definition of the route object.

/long-form

behaves as normal

/long-form/first-step

accessed directly from URL entry:
  1. adds templateUrl and resolve values from /long-form $route to array of dependencies
  2. adds templateUrl and resolve values from andWhen['/:step'] $route to array of dependencies
  3. resolve array of dependencies
  4. compile long-form.html and link to LongForm scope
  5. compile long-form/step.html and link to LongFormStep scope
accessed coming from /long-form or another /long-form/sub-page:

*/long-form.html would have already been resolved, compiled, and linked to the LongForm controller.

  1. adds templateUrl and resolve values from andWhen['/:step'] $route to array of dependencies
  2. resolve array of dependencies
  3. compile long-form/step.html and link to LongFormStep scope

Here's what the template HTML would look like, adding a new route directive to embed the views.

long-form.html
<h1>Awesome Form!</h1>
<div>
    <p>Thanks, {{name}} for filling out our form! You're just swell.</p>
    <h2>Here's what you've filled out so far!</h2>
    <ul>
        <li ng-repeat="field in data">{{field}}</li>
    </ul>
    <form>
        <route root>
            <p>Since this is your first time here, we need some basic information.</p>
            First Name: <input ng-model="data.firstName">
            Last Name: <input ng-model="data.lastName">
        </route>
        <route view="step" />
    </form>
    <marquee>This should never skip a beat!</marquee>
</div>

When long-form.html is compiled, only the matching route directive would be included. So, when a user is loading /long-form/first-step, long-form.html would compile the <route view="step" />. The value of the view attribute is connected to the andWhen key. That way, when <route view="step" /> is compiled, it knows where to grab the template from. Then it's business as usual for the injected template and controller.

I wish I had time to contribute more on this. My 11 week old daughter thinks I love JavaScript more than her, so my hands are tied. There are obviously a lot of changes that would need to be made for an idea like this to work. Is this within the scope of what this project and its team are attempting to accomplish?

Thanks everyone for taking on this issue! I look forward to following the progress and hopefully spending time helping out.

ui-active-highlight directive

@ksperling said somewhere at some point:

Finally, to provide utility directives around ... highlighting the current place in the UI ...

I propose a directive called ui-active-highlight, it would add an "active" class onto the element whenever the state in the parameter was active.

<li ui-active-highlight="contacts">
    <a href="/contacts">Go to Contacts Page</a>
</li>

Refer to the ui-route directive authored by @ProLoser

Question for AngularJS Core Team

We are initially planning on building a third-party solution, but we want to design it with the intention of eventually becoming a PR that you guys would look forward to merging into the core. I'd appreciate your input so that we can make this as mergable as possible.

  1. What are major concerns / requirements you guys have for nested routes?
  2. If you were to accept a PR or tackle the routing problem, would you keep backwards-compatibility or just focus on unrestricted changes? (Lets say you put the legacy router into an optional module like ngResource)
  3. There have been several approaches to handling nested routing. Do any of these sound like solutions you were looking at?
    1. Create a nested definition object (Angular.js+)
    2. State-based routing (Ember.js)
    3. Defining route decorators (Lithium PHP)

Unit Tests

I hate to be that guy, but unit tests are really really needed. I'd be willing to help with these if the APIs are final.

Feature request: global 'before' check on all state transitions

I see you've go an onEnter callback. I'd like to request something similar, but at the global level, so all state transitions need to pass the before filters before processing the route.

The main use case I'm thinking about are

  • login-checked
  • has the user completed signup check

I was just sketching out my own ideas for this before googling to find this router project (looks great, can't wait for it) which would look something like this in my head... (obv not using $routeProvider, but you get the point)

$routeProvider
      .before(function($route) {
        if($route.current.secure && !$rootScope.currentUser) {
          // abort the current route
          // force login here
        }
      })

Any appetite for including this sort of functionality within your router project?

I think the big difference over onEnter is the ability to abort routes, and do it on all states

feature requests

Awesome work, guys!
For me the only concern about Angular was routing.
I was able to implement all kind of requirements with low level js
(browser events and dom manipulations), but its not mixable with angular.
Your solution is almost perfect. I'd like to participate at least as tester :)

Some points:

1: would be great to have "more modularity" for states definitions. for example ("pseudoapi"):

    // basic structure in main /app.js file
    $stateProvider
        .state('admin', ...)
        .state('admin.profile', ...)
        ....

    // in separate src file e.g. '/admin/profile.js'
    $stateProvider
        .branch('admin.profile')
            .state('photos', ...
            .state('photos.details', ...

    // maybe also extend properties 
    $stateProvider
        .branch('admin.profile', {...}) // "inline"
        .config({ onEnter ... })        // or "explicit"
            .state...

and some base configuration

    $stateProvider.init({
        default: 'public',      // instead of $urlRouterProvider.otherwise('/')
        base: '/routing/sample' // for $locationProvider.html5Mode complete urls
    })

2: what about 'reloadOnSearch' ? - should it be implemented ?

3: does it make sense to amend form directive to use "native like" action syntax:
<form name="myForm" action="/user/auth/submit" method="get|post">...
to "navigate" to state on submit with form fields in params

4: is it possible to make ui-view directive hook-able (e.g. with another custom directive in attributes or through view config) to implement custom views transitions (like github src tree navigation or mobile sliding)

5: question - is it possible to move resolve: functions definitions from state tree to some module to reuse it in different states (without polluting global namespace) ?

Really appreciate any comments.

templateUrl and views attribute is mutually exclusive?

I have this code below:

  $stateProvider
    .state "standard",
      abstract: true
      templateUrl: "assets/layouts/standard.html.haml"
      views:
        "header@standard":
          templateUrl: "assets/layouts/header.html.haml"
        "navigation@standard":
          templateUrl: "assets/layouts/navigation.html.haml"
        "footer@standard":
          templateUrl: "assets/layouts/footer.html.haml"

When i try to load the corresponding page, which has "standard" as its parent, the lone 'templateUrl' ("assets/layouts/standard.html.haml") will be ignored and the standard.html.haml template won't be loaded.

However when i commented out the views, that templateUrl attribute will work normally.

Is this an intended behavior? can you elaborate on this?

$state.loaded

I think the loading indicator could just be a loaded property that is true once all views and dependencies have been loaded and resolved. The you can use the property in you templates to show some indicator if loaded while false. I think this should be a separate feature request because its SO common.

Also, Maybe a directive to automatically display a "loading.html" partial or have it be a setting on each state?

gh-pages branch

Need to put together a demo site with mini docs. I realize this is redundant to the existing docs and approaches, so do not prioritize it.

Custom views transitions

Is it possible to make ui-view directive hook-able (e.g. with another custom directive in ui-view attributes or with view config) to implement custom views transitions (like github src tree navigation or mobile sliding).
Something like http://ajoslin.github.com/angular-mobile-nav/ , but with ability to amend transition behavior with js.

Resolve demo code not working

the following code from the docs throws an error

Error: Unknown provider: titleProvider <- title
$stateProvider.state('contacts', {
  template: '<h1>{{title}}</h1>',
  resolve: { title: 'My Contacts' },
  controller: function($scope, title){
    $scope.title = title;
  }
}

after looking at the source code, I see the docs should say:

$stateProvider.state('contacts', {
  template: '<h1>{{title}}</h1>',
  resolve: ['$scope', function($scope){ $scope.title = 'My Contacts'; }],
  controller: function($scope){
    $scope.title = title;
  }
}

Back Button Support?

It would be absolutely amazing if we could detect when the back button is pressed, using window.onpopstate on newer browsers.

Then once ngAnimate is in, we could have transitions between pages that look different depending on forward or back (eg github file browser, any mobile app).

I'd be willing to work on this, has anyone else done anything with this?

Enhanced route syntax

Discussion on how augment route definition (regexp, optional params, constraints,...)

We should agree in the following, in no particular order:

  • Optional parameters
  • Type definition (restrict to string, to integers, paths, list). Especially important is the path, as it allows using parameters that contain slashes.
  • Min/max length
  • Regexp syntax

We could use the following pull-requests as a guide:

Create wiki page with demo snippets

Essentially we need some up-to-date documentation, but by 'demo snippets' I'm referring to how different features and edge-cases are to be addressed.

ui-router does not work when used with require.js

Hi guys,
I tried to use ui-router with require.js today. The problem is, every time I inject ui.compat into the controller the specific parts stops working. I created a plnkr here:

http://plnkr.co/edit/tbf5oXZrZh7b7pJnCila?p=preview

When you take a look at main.js and add the following lines:

function (app) {
  return app.run(['$rootScope', function ($rootScope) {
    console.log($rootScope);
    }]);
});

Instead of the current, which look likes this:

['ui.compat', function (app) {
    return app.run(['$rootScope', '$state', '$stateParams',
      function ($rootScope, $state, $stateParams) {
        console.log($rootScope);
      }]);
}]);

Then you can see that app.run(); is executed. The same is valid for routes.js. As soon as I remove ['ui.compat'...] everything works as expected again. With ['ui.compat'...] it stops.

Any idea why this happens?

Relocate source to AngularUI/Router

Lets put the code in here so we can start cleaning it up and refactoring.

Since not everyone is in consensus we may try to bring it in line into a solution everyone can agree with.

Updating one view while not updating the other

Hi,

Maybe its too simple and I am doing something wrong here.

In the code below, I have am loading templates into my views. Note that, between the two states - customers & services, only the view 'maincontent' is changing. The view 'leftpane' does not change.

.state('customers', {
url: '/customers',
views: {
'leftpane': {
templateUrl: 'ui/p-leftpane-cust.html'
},
'maincontent':{
templateUrl:'ui/p-customers.html'
}
}
})
.state('services', {
url: '/services',
views: {
'leftpane': {
templateUrl: 'ui/p-leftpane-cust.html'
},
'maincontent':{
templateUrl:'ui/p-services.html'
}
}
})

My question is can I do something like -
.state('services', {
url: '/services',
views: {
'maincontent':{
templateUrl:'ui/p-services.html'
}
}
})
where the 'leftpane' view is inherited from its previous state/last loaded state? When I try to do this, the 'leftpane' is updated to empty.

<unnamed> view targeting

While writing up the Overview, I feel like targeting unnamed views or states needs a less magical elite solution. While using empty can still be an option it may be nice for developers AND any developer reading the code later if we had an alias as well.

I propose using for unnamed views and for root state (or something similar). Reference the Named Views section of the overview. Like this:

$stateProvider
  .state('contacts.detail', {
    templateUrl: 'contacts.detail.html'
    views: {
        "info" : {}                   // relatively targets the "info" view in "contacts.detail" state
        "" : {}                        // relatively targets the unnamed view in "contacts.detail" state
        "detail@contacts" : {}  // absolutely targets the "detail" view in parent "contacts" state
        "<unnamed>@contacts" : {}         // absolutely targets the unnamed view in parent "contacts" state
        "status@<root>" : {}            // absolutely targets the "status" view in root unnamed state
        "<unnamed>@<root>" : {}                     // absolutely targets the unnamed view in root unnamed state
  });

Side Question: How do we set a root state without using URLs?

Back Button Support?

It would be absolutely amazing if we could detect when the back button is pressed, using window.onpopstate on newer browsers.

Then once ngAnimate is in, we could have transitions between pages that look different depending on forward or back (eg github file browser, any mobile app).

I'd be willing to work on this.

Why not embed '<script src="various.js"></script>' into templateUrl "html" document ?

Hi,

Something we do in CRUD environments is to include JavaScript routines for a specific <div> partial, so that we can control everything going on inside the partial, for example:

------- start html document ------

<script type="text/javascript">
    function MyCtrl($scope) { 
       . . . JavaScript functions . . .
    }
</script>
<div ng-controller="MyCtrl">
      . . . various . . .
</div>

------- end html document -------

Notice that MyCtrl is a controller that is inside the HTML document.

This enables us to have different developers writing specific business logic for each CRUD section.

I would like to use the "templateUrl" option so that we can load an xxx.html, in which we can add as many <script type='text/javascript'> with embedded controllers and other JavaScript code bits.

In other words, the classical ui-router just needs:

  .state('report',{
    views: {
      'tabledata': {
        templateUrl: 'MyXXX.html',
       NO NEED FOR CONTROLLER HERE, 
      BECAUSE JS CODE IS EMBEDDED IN 'MyXXX.html'
     }
      },
      'graph': {
        templateUrl: 'report-graph.html',
        controller: function($scope){... controller stuff... }
      },
    }
  })

Thanks,

Marcus

Optimize object-based states to prevent conflicts with future API changes

Object-based states are already supported, but we should consider the pitfalls of doing it this way.

var states = {};

states.contacts = { 
    name: 'contacts',
    url: '/contacts',
    abstract: true,
    templateUrl: 'contacts.html'    
}
states.contacts.list = { 
    name: 'list',
    parent: states.contacts, 
    templateUrl: 'contacts.list.html'
}

$stateProvider
  .state(states.contacts);
  .state(states.contacts.list)

Potential Pitfalls:

  • nesting state objects in this way could lead to issues if we ever expand $stateProvider with new properties or methods (e.g. add a list property in the future).

One suggestion was prefixing all API properties with '$', though this doesn't seem optimal.

(Back-Compat) uiRouteProvider Routing

Discussion on how enhance the default route provider with hierarchical routes in a backward compatible way.

Task list:

  • Duplicate the relevant code and test cases and just renaming the route service and the ngView directive.
  • Agree on a syntax to specify subroutes (nothing about smart reloading of subviews yet).
  • Add tests & make it work! (or viceversa, whatever we decide).
  • Discuss and agree on a intelligent way of updating or refreshing subviews.
  • Add tests that cover dynamic updating of subviews.
  • Enhance the route syntax (optional params, constraints, regexp, etc). At this point we should already agreed on this via the relevant issue thread).
  • Add test that cover the new syntax.
  • RFC?
  • Make a Pull Request to the AngularJS official repository.

Requirements extracted from the wiki and #1:

  • Implementation should be backward compatible with the actual routing system.
  • Implementation should be just one module.
  • We shouldn't override the original $routeProvider service nor the ngView directive. Let's just use uiRouteProvider and uiView instead (or whatever you want).
  • When designing how nested routing works
    • Subview naming should be optional if there is only one in that nesting level.
    • Subrouter are specified using nested objects inside the top level route param object.
    • At first, when a route changes all its subroutes get reloaded. We will add conditional refreshing/reloading/persistence/whatever later.

Inferred State Properties

This is a thread to keep the idea of inferred state properties alive. The idea is that we'd do some of the work for the user based on the the state name. To pull from another issue:

I also like the idea of inferring things (similar to Ember) but that's not really what angular is all about. In ember you have to always remember all the magic that is happening for you, in angular there is a lot less "magical" inference. So I'd be cautious to automatically load templates based on state name, e.g. 'contact.list' automatically loading 'contact.list.html'. If we did infer templates though, we could handle named views similar to the view's absolute name, e.g. 'menu' view in 'contact.list' could automatically load '[email protected]' though that would screw up alphabetic sorting of the files, so maybe '[email protected]'.

Benefits:

  • Easier quicker API

Downsides:

  • Magical API

Questions:

  • Users may not want to load a view (or other properties) for every state, how to prevent that?

Looking for Team Members!

I'm creating this issue so that people can have a place to request joining the AngularUI Router development team!

Simply add a comment below and if possible add your 2c to issue #1

Two tabs

Is there's a discussion list for ui-router? I can't find one.

For a single tab, it's easy, url can be like /tab/:tabId

<tab header/>
<ui-view>

How about two sibling tabs though?

<ui-view="tabOne">
<ui-view="tabTwo">

But how do you define the states? And url? "/tab/:tabOne/:tabTwo ? Is it supported?

$stateParams not populated when resolving dependencies for nested views

I've been experimenting with the new routing code and I've managed to get pretty far in converting an existing application to use the new code but I've run into a bit of a problem and I'm not sure if it is because I am doing something wrong or if it is a bug.

The issue is that $stateParams nor anything that I can see in $state has the URL parameters for the view that is being transitioned to when attempting to resolve a nested view. You can see this issue in the example application and I created a branch that demonstrates it here: https://github.com/robschley/router/blob/stateParams/sample/index.html#L115

The contacts.detail view defines dependencies to resolve before initializing the controller. To effectively resolve those dependencies, one would expect that $stateParams or $state would provide the URL parameters for the view that is being transitioned to. In this case, contactId should be available in $stateParams. When resolving "something" in the sample, there seems to be no way to get to the contactId because it is not populated into $stateParams until AFTER all of the dependencies have been resolved.

Is this a bug or am I doing it wrong? Any guidance is much appreciated.

Complete shim for $routeProvider backcomp

The shim to implement the $routeProvider API on top of $stateProvider is mostly there:

  • copy over the unit tests from AngularJS and see what's missing to implement that API fully
  • maybe also try some existing Angular samples that use $routeProvider and see if they still work when running on the $stateProvider implementation.

Create project specification breakdown

The core team is interested in getting involved, but they asked that we try to make a very SHORT breakdown of what issues/features we are trying to address and how the new router accomplishes this.

Project Docs

I see the doc markup in some of the files and I see a commit called "Generate some docs via jsdoc" but I am not seeing any docs, nor am I seeing any final builds. Are you not adding some things to git?

Create milestones

So I only recently started using Github milestones on AngularUI, and I must say it makes things a lot more chronologically organized.

It lets me quickly pull up all the issues I want to tackle immediately for the next release and also lets me have a place I can throw long-term ideas that I may pick up in the future.

I'm going to create a v0.1.0, v0.2.0 and 'future' milestones.

Things that are MISSION CRITICAL belong in v0.1.0, keep this as minimal as possible because we want to keep the scope small. Once v0.1.0 is released, we will open a v0.1.1 for bug fixes that (also) should get merged into v0.2.0.

Nice features that would make the basic functionality easier/beter can go into v0.2.0 but leaving them out will not make the router impossible to use.

Any ideas that may require us to come back to in the future should (obviously) go in 'future'.

The reason I am not using v1 and v2 is because we would like to reserve the right to keep the API unstable until we know what we're going to officially go with.

Since I don't have a lot of time, I will leave it to you guys to organize the issues into their relevant milestones.

Also, we should remove the 'review later' tag in lieu of the 'future' milestone.

I realize that issues may not be granular enough to fall into milestones yet, so feel free to leave them out until this becomes clear.

(Non-Back-Compat) State-based routing

Discussion on how to implement a state-based route provider. The idea is to generate a module that can be loaded on those apps who require advanced or state-based routing.

Backward compatibility does not need to be kept, so we can explore any proposal without being restricted.

Some reading to getting started:

Ability to reject a state transition

Look at the ability to reject state transitions, even though in my mind this has some caveats

  • If the transition is initiated via URL, rejection should really result in a redirect to some other (valid) URL rather than just leaving $location out of sync
  • If it's done via code, why is it happening in the first place

AngularUI Org Hangout

As per this thread we have been talking about having an AngularUI Org-wide hangout. I figure you guys may not be receiving emails from the google group so I thought I'd post this here:

http://doodle.com/2abdy3tkwbatrcs9

We can refine the time further once we get a general slot identified. If too many people cannot make any of these timeslots we can make a new poll.

NOTE: PLEASE UPDATE YOUR TIMEZONE FIRST BEFORE EDITING

Trailing slash in url breaks state routing

If the url contains a trailing slash the state routing does not recognize the url and transition to the correct state.

For example, if you define the following state:

$stateProvider
       .state('contacts', {
           url: '/contacts',
           templateUrl: '/contacts.html',
           controller: 'ContactsController'
       });

When you go to #/contacts it routes to the 'contacts' state correctly, however if you go to #/contacts/ the route is not recognized.

The only workaround I have found is to define a second route which contains the trailing slash with a different name but that is quite cumbersome to have to do for every single state in an application.

Thanks!

$stateChangeStart and preventDefault

First and foremost, thank you guys for your hard work I am loving it, it's awesome !
Is there currently a way to pause the state change to enable a "transition-out" of the current view for x millisecond ( the time the "transition-out" takes ) and resume the state change ones it's done ? I have tried $stateChangeStart event.preventDefault() but it didn't stop the transition the view and the scope was destroyed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.