@uirouter/core
Advanced tools
Changelog
5.0.9 (2017-10-02)
Compare @uirouter/core
versions 5.0.8 and 5.0.9
invokeLimit
to limit the number of times a hook is invoked before being auto-deregistered. (2cb17ef)Changelog
5.0.8 (2017-09-30)
Compare @uirouter/core
versions 5.0.7 and 5.0.8
Changelog
5.0.7 (2017-09-23)
Compare @uirouter/core
versions 5.0.6 and 5.0.7
self
instead of window
for webworker compat (a4629ee)Changelog
Changes in @uirouter/core
between versions 5.0.5 and 5.0.6 (2017-08-12)
Changelog
Changes in @uirouter/core
between versions 5.0.5 and 5.0.6 (2017-08-12)
Changelog
Changes in @uirouter/core
between versions 5.0.4 and 5.0.5 (2017-06-29)
Changelog
5.0.0 (2017-04-21)
State
object to StateObject
(feceaf9).register()
and StateMatcher.find()
misses (fdb3ab9)Transition.is()
which was never implemented (1edff4b)UrlRouter
) improve perf of registering Url Rules and sorting Url Rules (64fbfff)rules.initial("/home")
to config initial state (like otherwise) (bbe4209)State
object (now named StateObject
)import { State } from "@uirouter/core";
const match = { to: (state: State) => state.data.auth };
transitionsvc.onEnter(match, (trans: Transition, state: State) => {
// state is the internal State object
if (state.includes["foo"]) { // internal ui-router API
return false;
}
}
import { StateDeclaration } from "@uirouter/core";
const match = { to: (state: StateDeclaration) => state.data.auth };
transitionsvc.onEnter(match, (trans: Transition, state: StateDeclaration) => {
// state === the state object you registered
// Access internal ui-router API using $$state()
if (state.$$state().includes["foo"]) {
return false;
}
}
The State
object (now named StateObject
) is an internal API and should not be exposed via any public APIs.
If you depend on the internal APIs, you can still access the internal object by calling state.$$state()
.
How likely is this BC to affect me?
Medium: You will likely be affected you 1) have transition hooks, 2) are using typescript and/or 3) use the internal ui-router State API.
How severe is this BC?
Low: Access to the internal api is still available using $$state()
.
State
object to StateObject
import {State} from "@uirouter/core";
import {StateObject} from "@uirouter/core";
We'd like to use the State
name/symbol as a public API. It will be an
ES7/TS decorator for ES6/TS state definition classes, i.e:
@State("foo")
export class FooState implements StateDeclaration {
url = "/foo";
component = FooComponent;
@Resolve({ deps: [FooService] })
fooData(fooService) {
return fooService.getFoos();
}
}
How likely is this to affect me?
Low: This only affects code that imports the internal API symbol State
.
You will likely be affected you 1) import that symbol, 2) are using typescript and 3) explicitly
typed a variable such as let internalStateObject = state.$$state();
How severe is this change?
Low: Find all places where State
is imported and rename to StateObject
Previously, if a transition hook returned a rejected promise:
.onStart({}, () => Promise.reject('reject transition'));
In onError
or transtion.promise.catch()
, the raw rejection was returned:
.onError({}, (trans, err) => err === 'reject transition')
Now, the error is wrapped in a Rejection object.
.detail
..onError({}, (trans, err) =>
err instanceof Rejection && err.detail === 'reject transition')
.type
of transition rejection (ABORTED, ERROR, SUPERSEDED and/or redirection)..onError({}, (trans, err) => {
err.type === RejectType.ABORTED === 3
});
Errors thrown from a hook and rejection values returned from a hook can now be processed in the same way.
How likely is this to affect me?
Medium: apps which have onError handlers for rejected values
How severe is this change?
Low: Find all error handlers (or .catch/.then chains) that do not understand Rejection. Add err.detail
processing.
onBefore
hooks are now run asynchronously like all the other hooks.Previously, the onBefore
hooks were run in the same stackframe as transitionTo
.
If they threw an error, it could be caught using try/catch.
transitionService.onBefore({ to: 'foo' }), () => { throw new Error('doh'); });
try {
stateService.go('foo');
} catch (error) {
// handle error
}
Now, onBefore
hooks are processed asynchronously.
To handle errors, use any of the async error handling paradigms:
transitionService.onBefore({ to: 'foo' }), () => { throw new Error('doh'); });
stateService.go('foo').catch(error => { //handle error });
transitionService.onBefore({ to: 'foo' }), () => { throw new Error('doh'); });
transitionService.onError({ to: 'foo' }), () => { // handle error });
stateService.go('foo');
transitionService.onBefore({ to: 'foo' }), () => { throw new Error('doh'); });
stateService.go('foo');
stateService.defaultErrorHandler(error => { // global error handler });
Why introduce a BC?
How likely is this to affect my app?
Very Low: Apps that registered onBefore hooks and depend on synchronous execution are affected.
How severe is this BC?
Low: Switch to asynchronous handling, such as chaining off the transition promise
defaultErrorHandler
Returning false
from a transition hook will abort the transition.
Previously, this case was considered an error and was logged by
defaultErrorHandler
.
After your feedback, we agree that this is not typically an error.
Now, aborted transitions do not trigger the defaultErrorHandler
Why introduce a BC?
Most users do not consider ABORT to be an error. The default error handler should match this assumption.
How likely am I to be affected?
Low: Most users do not consider ABORT to be an error. For most users this will not be a BC.
How severe is this BC?
Low: Users who want to handle all transition rejections can
register a .onError
handler and filter/process accordingly.