Skip to content

refactor(view): refactor how views are loaded and configured. #2619

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

Merged
merged 1 commit into from
Mar 17, 2016
Merged

refactor(view): refactor how views are loaded and configured. #2619

merged 1 commit into from
Mar 17, 2016

Conversation

christopherthielen
Copy link
Contributor

  • Each framework (ng1/ng2) to provide a StateBuilder views decorator that understand different keys/values to meet that framework's needs
    • The views decorator takes ViewDeclarations (the views block on the state declaration), and processes them. It returns normalized framework specific POJOs (i.e. Ng1ViewDeclarations)
  • Before a Transition begins, each normalized ViewDeclaration being activated is converted into a ViewConfig and added to the Node's views array
    • The ViewService is responsible for creating an instance of a ViewConfig from the ViewDeclaration, based on the type of ViewDeclaration (registered using ViewService.viewConfigFactory)
    • Each ViewConfig is bound to the appropriate Node in the "to path"
  • During the transition, the ViewConfig is prepped (load templates, controllers, components) using viewConfig.load()
  • After the configs are prepped, they are registered with the StateService (to be matched with ui-views)
  • The $element.data('$uiView') is reorganized and simplified.
    • $element.data('$uiView').$uiView has the ActiveUIView ref object (formerly named UiViewData)
    • $element.data('$uiView').$cfg has the activated ViewConfig ref object

- Require a Framework-specific (ng1/ng2) StateBuilder `views` decorator
- The `views` decorator takes `ViewDeclaration`s and returns normalized `ViewDeclaration`s
- Before a `Transition` begins, a `ViewConfig` is created and bound to the appropriate Node
- During the transition, the `ViewConfig` is prepped using `load()`
- After the configs are prepped, they are registered with the `StateService`, to be matched with `ui-view`s
- The `$element.data('$uiView')` is reorganized and simplified.
  - $element.data('$uiView').$uiView has the ActiveUIView object
  - $element.data('$uiView').$cfg has the ViewConfig object
@@ -158,6 +158,11 @@ function ng1UIRouter($locationProvider) {

// Create a new instance of the Router when the ng1UIRouterProvider is initialized
router = new UIRouter();

// Apply ng1 `views` builder to the StateBuilder
router.stateRegistry.decorator("views", ng1ViewsBuilder);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Register the ng1 views "StateBuilder decorator".

christopherthielen added a commit that referenced this pull request Mar 17, 2016
refactor(view): refactor how views are loaded and configured.
@christopherthielen christopherthielen merged commit 3d3c50f into angular-ui:master Mar 17, 2016
@christopherthielen christopherthielen deleted the refactor_viewconfigs branch March 28, 2016 14:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants