Skip to content

Back to Basics

Choose a tag to compare

View all tags
@alexlafroscia alexlafroscia released this 02 Apr 18:23
· 748 commits to master since this release
v4.0.0
d18b518

Docs: http://alexlafroscia.com/ember-steps/v4.0.0/docs

Breaking Changes

step-manager is no longer cyclical by default

Originally, the underlying state machine in the step-manger was cyclical, meaning that the first step pointed "backwards" to the last step, and the last step pointed "forward" to the first step. This doesn't really make a lot of sense, though.

Instead, by default, the state machine is now linear, meaning that the first step has no "previous" and the last step has no "next". Whether or not there is a next or previous step is now provided by both the step-manager and each step. See this page in the documentation for details.

If you want to retain the cyclical nature of the state machine, you can pass linear=false to the step-manager component and it will function the same way as it used to.

Removal of did-transition and will-transition hooks from the step-manager

This code got pretty gnarly, and it became clear to me that it doesn't makes sense for the step-manager to know anything about validating that the transition should take place. Rather than trying to transition and failing, we should just avoid executing the transition if that's the desired behavior. This also allows the step-manager to be entirely synchronous.

However, since validating transitions is still something that we want to allow for, the addon ships with a validate-transition helper that you can compose a validator action into, allowing you to execute a transition conditionally. Check out this page in the documentation for an example of how to use validate-transition.

Removal of did-enter and will-enter from step

Much like the {did|will}-transition hooks on the manager, these are concerns outside of the step-manager. If you want to respond to a transition taking place, see this example in the documentation for a tip on how you can compose actions together to the same effect. If you feel like that doesn't handle your use-case, please open an issue.

Removal of custom error classes

Originally this addon threw some custom error classes based on what went wrong. This has been replaced by "regular" Ember.assert usage. You should remove any logic that might have interacted with those specific error classes.

New Features

Linear state machine

The step-manager now creates a linear sequence of steps by default, which is more likely to be what you want anyway.

Surfacing whether a step has a "next" or "previous"

Now that a step can not have a "next" or "previous", the step-manager surfaces whether the current step has a next/previous step.

{{#step-manager as |w|}}
  {{w.hasPreviousStep}}
  {{w.hasNextStep}}
{{/step-manager}}

Each step also surfaces this information about itself

{{#step-manager as |w|}}
  {{#w.step as |step|}}
    {{step.hasPrevious}}
    {{step.hasNext}}
  {{/w.step}}
{{/step-manager}}

Improvements

  • No longer tries to determine the initial step at build time
    • Removes the need for the htmlbars transform; everything can be done at runtime
  • Simplified API, making maintenance easier
  • Better documentation, with thorough examples
Assets 2
Loading