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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

6.0.1 (2018-08-27)

Bug Fixes

6.0.0 (2018-06-17)

Bug Fixes

Features