Ember Route Action Helper

A case study in community solutions

@trabus

@jakebixby

Jake Bixby

Senior UI Engineer @

ember-cli core team alumnus

amateur macro photographer

doggo food balancing enthusiast

I have patient puppers

I also take a lot of pictures of little things and flowers

Why am I talking about this?

  • I wanted to highlight something I saw in the Ember ecosystem
     
  • I have seen differing opinions of the addon and its use over time
     
  • I have used it and have developed opinions to share
     
  • I needed a topic, and this seemed good?

So what did I see?

  • Ember has changed a LOT over the time I've used it
     
  • Ember is adept at spotting good ideas and adopting them
     
  • The process and tooling provided by Ember are pretty unique
     
  • Even in misstep the community generally course corrects

Case study

I am of the opinion that the ember-route-action-helper addon exemplifies how this process is working for the community

Let's take a look at it!

What is it?

  • ember-route-action-helper is an addon that was created in preparation for routable components
     
  • It provides a closure action style helper to access route actions
     
  • It completely circumvents the need for controllers in regards to route level actions
export Controller.extend({
    actions: {
        login(username, password) {
            this.send('login', username, password);
        }
    }
}
<button {{action "login" userName password}}>Login</button>

Controller

Template

Before

export Route.extend({
    actions: {
        login(username, password) {
            // do login stuff
            ...
            this.transitionTo('home');
        }
    }
}

Route

export Route.extend({
    actions: {
        login(username, password) {
            // do login stuff
            ...
            this.transitionTo('home');
        }
    }
}
<button {{route-action "login" userName password}}>Login</button>

{{yield (route-action "login" userName password)}}

Route

Template

After

Why was it created?

  • It was intended to be a stop-gap solution for routable components
     
  • It was also intended to simplify the programming model by circumventing controllers entirely
     
  • Applied the closure action pattern to route actions, for currying and passing with a return value
     
  • The existing route and controller action model was confusing and error prone

Action Bubbling

Router Service

"               "

Using the new with the old

  • The route-action helper leverages the then new router service
     
  • The helper walks through the currently active routes to find an action that matches the name
     
  • The helper returns a function, so the action can be passed/yielded down to components
     
  • Did not interfere with the old model, so adoption could be incremental

What went wrong?

  • Routable components were cancelled in January 2018
     
  • When used without restraint, anti-patterns emerged
     
  • When used with restraint, there was still room for poor developer ergonomics
     
  • Still tied heavily to the old pattern of action bubbling

The good

  • Providing a way to reach "global" level route actions is actually a good thing
     
  • Avoids use of controllers for actions that should be handled by a route
     
  • Abstracts route level actions as closure actions, removing the need for sendAction or using other bubbling methods from components

The bad

  • Abstracts route level actions as closure actions, sometimes obscuring the original source
     
  • Route "bubbling" means that you have to track your action down sometimes
     
  • Routes intentionally don't hold state, requiring controllerFor or other methods to access state (sometimes misusing services, etc)
     
  • Routes also don't own state, and mutating state where it isn't owned is bad

The ugly

  • Abstracts route level actions as closure actions, allowing naming disconnections
     
  • Use in component templates can cause invisible entanglement, i.e. inside a component 10 levels deep, inside a nested route
     
  • Use inside an addon puts difficult requirements on consumers (setting up a route action, testing setup for anything using it)
     
  • Action name collisions in the route hierarchy can cause issues that are hard to identify

A quick timeline

2015

2019

rwjblue's jsbin
Dec 2015

Dockyard releases addon
Feb 2016

Community adopts

closure actions introduced
June 2015

improved actions rfc
May 2014

routeable components rfc
Feb 2015

routeable components
rfc closed
Jan 2018

Dockyard deprecates addon
Feb 2018

route actions
rfc opened
Oct 2018

route actions
rfc closed
Jan 2019

What now?

  • Pre 3.4 continue using controllers and use the route-action helper only when you absolutely need it
     
  • Avoid using it in component templates
     
  • Be mindful of renaming issues
     
  • If you are using 3.6 (or 3.4 + with decorators polyfill) you can use the @action decorator on a service

@action + @service decorators

  • Explicitly refer to the action instead of hoping it is somewhere on your route hiearchy
export class Auth extends Service() {
    @service router
    @action
    login(username password) {
        // do login stuff
        this.router.transitionTo('home');
    }
}
<Login {{on “click” (fn this.auth.login userName password)}} />
export class LoginButton extends Component() {
    @service auth
}

Simplify the action system

  • Use one pattern for actions (instead of three)
     
  • We need to drop the old actions hash system, it carries a lot of cruft
     
  • I think the @action decorator is actually the best path to that. It simply binds context for later use
     
  • Somehow deal with the naming baggage (using the fn helper will help)

Embrace a simpler model

  • Drop Controllers entirely (after query params service is a thing)
     
  • Become a service + component framework (maybe with focused routes)
     
  • The @action decorator is an explicit and simple solution

To recap

  • ember-route-action-helper is an addon developed by Dockyard in early 2016 to provide a closure action style template helper for using route actions
     
  • It gained popularity in the community because the helper was recommended as a way to prepare for the removal of controllers in Ember
     
  • The pattern inadvertently enabled some anti-patterns
     
  • In early 2018 it was then recommended that the addon not be used after routable components were cancelled
     
  • A better way is here, so use it! (if you can)

But wait!

there's more...

RFCs, Addons, and Evolution

A paragon of community solutions

(A talk within a talk)

Jake Bixby

Senior UI Engineer @

hooman dadman

amateur macro photographer @trabus
doggo food balancing enthusiast @stumpybuns

I definitely have a problem

And I spend entirely too much time crouched around flowers

AMAZING

framework

DEVELOPMENT

has an

for

of itself.

Ember

What are some components

of this meta-framework?

RFC process

Addon system

Emphasis on primitives

Steering committee

Community involvement

Incremental
approach

Experimentation

Deprecations

Release
train

And more!!

Editions

  • RFC process
     
  • Addon system
     
  • Primitives
     
  • Experimentation                 

Some key components from the case in the last talk?

What can we extrapolate?

  • A gap in the framework was filled by a opt-in, minimally invasive, easily codemodded solution
     
  • Experimentation through an addon exposed unforeseen anti-patterns
     
  • Through a slightly related change in direction, the addon was made less optimal
     
  • The process worked, eventually, which has affected and improved the process by better scoping future candidate solutions

RFCs

  • Ember adopted a Request For Comments process from Rust in late 2014
     
  • The RFC process has been instrumental in fleshing out most of modern Ember
     
  • Every single feature of Octane has been brought in through RFCs
     
  • RFCs have also helped identify possible issues with some excellent ideas

RFCs

  • Rejected RFCs can still inform and influence ones that get accepted
     
  • Knowing that ideas are discussed and carefully considered before adoption gives me confidence in the framework
     
  • It's become the standard for many projects, including react and vuejs
     
  • They are extremely flexible in application, they are used for every part of the process!

Addons

  • Addons are so flexible and powerful that you can do nearly anything with them
     
  • They allow early experimentation and adoption
     
  • They allow incremental adoption of feature sets
     
  • They help back-port adoption of new features to earlier versions of the app
     
  • They are used inside ember and ember-cli itself!

Primitives

  • Ember has always aimed to provide strong primitives on top of JavaScript
     
  • Ember has also aimed to align primitives with native solutions when possible (Promises, Decorators)
     
  • Ember continues to move towards native solutions (classes, decorators) with a provided migration path for each

Evolution

  • This cycle of discussion, refinement, experimentation, and adoption, is how Ember has not left any of its users behind despite reinventing itself several times over
     
  • The entirety of the Octane feature-set went through this process, all providing polyfills to ease upgrading
     
  • This is how Ember can take a pre five year old application and bring it all the way up to a canary app
     
  • This is how I believe Ember will continue to be relevant, as it borrows and improves upon good ideas

Thanks!

Thanks!

@trabus

@jakebixby

deck

By Jacob Bixby

Made with Slides.com

deck

  • 602

More from Jacob Bixby