Controlling Route Traversals with Flow

This talk was all about routes. Nathan Hammond started by talking about URLs in three different categories… resources, actions, and flows. Resources don’t change the state of an app and are available all the time. We want them to be in our history stack. Finally, they are plural or singular nouns depending on the controller. Actions are things like post or put paths like /login or /recover-password. It receives all the users input at once. It results in the user being presented with flash or a new resource. Finally, it should always contain a verb (see the examples from a few sentences ago). Finally, there are flows. Slows are series of actions across routes. Flows lead to a completed application state.

A state machine allows you to jump into the flow. BUT designing a flow is really hard. You need to make sure you cover every components of the flow. There is a four step process to do this.
Step 1: inventory our routes in the routers
Step 2: list linear paths (ie- login flow traversal path)
Step 3: convert to node graphs
Step 4: identify state change to traverse each path
        Then you do a complete enumeration of the state or if you’re passing in a wait
Step 5: Identify backwards traversals (ie- where does the back button lead to each time you press it).

The CS term for doing this is a directed graph.

The result is a state machine that describes exactly how a user moves through and app. It is the picture that shows ALL of the steps we just outlined.

Looking at this demo, http://alexdiliberto.com/emberconf-2014-demo/#/login, gives us a sense of flows. To “code the flow”, the general strategy is that you start by loading the session state. The you reset the controller (if needed). After, you delegate identification of where you’ll go next. Then you traverse the longest route so you know you visited every node. AND you can use replaceWith instead of transitionTo which Nathan thinks is awesome.

A better strategy is to start with one place that defines flow and load the flow and flow state (explained as where the user is and what state they’re in). Then, you delegate the id of where to go to in the flow. After, you call back into the flow to progress. You start with a definition file with an edge list that dictates a from and a to path with conditions. The conditions are what needs to be checked, like ‘isAuthenticated’. Then you inject the flow logic. beforeModel looks up the current flow and identifies where the user should be and then you set the action. The action will include var Flow. Which sets state on the flow inside your routes so there’s no processing of that information in the route. Or further reading, check out ember-flows which is almost ready: https://github.com/nathanhammond/ember-flows.