Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Rewrite/refactor of router.js. Multiple features. #11

Closed
wants to merge 1 commit into
from
Commits on Mar 30, 2013
  1. Major refactor: improvements to transitions, async

    machty committed Mar 30, 2013
    router.js needed a facelift. Here are some things that have been fixed
    or improved with this rewrite/refactor:
    
    - `handleURL` and `transitionTo` behavior is unified. Previously, only
      `handleURL` would cause the router to go into a loading state when a
      promise was encountered. Now the logic is as follows:
      For both `transitionTo` and `handleURL`, if a promise context is
      provided to a route, check and see if a global loading state exists
      (as before). If so, pause the transition until promise resolves and
      enter the loading state in the meantime, else continue with the
      transition under the assumption that leafier routes can handle the
      unresolved promise. At some point in the future, we should reconsider
      per-route loading states like router v1.
    - Preventable/redirectable transitions according to an API described at
      https://gist.github.com/machty/5170781
    - URL-less routes: setting notAccessibleByURL to true on a handler will
      make it inaccessible to URL changes, and will prevent a URL update
      from happening at the end of a transitionTo
    - Promise-based URL-changing. Previously, transitionTo would immediately
      try to serialize transitioned-to route to determine the new URL, but
      if the context is a simple promise object (not an Ember Data Deferred
      with knowledge of its `id` property), the serialize can't succeed
      until the promise has been resolved. @wycats suggested that the update
      shouldn't happen until promises are resolved, but then again, often
      enough data is available to serialize even if the promise isn't
      resolved, and it would be undesirable to have transitionTo'd into a
      route and unnecessarily be waiting for the URL to show up. So this PR
      takes an eager but configurable approach to this problem. By default,
      the serialization attempt happens immediately. If one of the params
      set by a router's `serialize` method has a null/undefined value, the
      serialize is considered a failure, and the URL change won't be
      attempted until after all promises have resolved. This behavior is
      also configurable via the `updateURLImmediately` property on the
      router. If set to true, if the serialization fails, an error is raised
      while retrying later. If set to false, the first serialization attempt
      is never made, and is only attempted at the end of the transition
      after all promises have resolved. Closes #9.