Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor $pipeline, $state and $stateTransition #106

Open
jeme opened this issue Jun 26, 2014 · 0 comments
Open

Refactor $pipeline, $state and $stateTransition #106

jeme opened this issue Jun 26, 2014 · 0 comments
Milestone

Comments

@jeme
Copy link
Contributor

jeme commented Jun 26, 2014

To complete the work done in #102 for v0.7.0 we need a few refactorings.

Reason for splitting the task up is that the introduction of the $pipeline service in #102 is not a breaking change, and so it can live in the v0.6.x track, but to streamline things a bit more some services will undergo some refactorings that will introduce breaking changes.

Merging and renaming of $stateTransition and $transition into the same object/service, while $transition would be the cleanest name for both, we need to consider a clash with: https://github.com/angular-ui/bootstrap/blob/master/src/transition/transition.js

So we need to consider another option for a name or stick with $stateTransition.

We do this as a refactoring of $state and $stateTransition as is should make way for letting the $stateTransition handle all what the intermediate $transition service did.

This should allow for a much more flexible solution, which can be customized to a high degree, this also makes both the $state service and $transition service more focused on what they do.

Also we wan't to allow access to configure all providers through just the $stateProvider to simplify things a great deal, e.g.

$stateProvider.routes -> $routeProvider
$stateProvider.transitions -> $stateTransitionProvider
$stateProvider.pipeline -> $pipelineProvider

the $stateProvider already have access all of these directly or indirectly as it needs them for configuration or at runtime so this shouldn't be a problem.

@jeme jeme added this to the v0.7.0 milestone Jun 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant