Investigating alternate route data patterns

[knownasilya]

Managing data in the route has been brought into question a few times, e.g. https://gist.github.com/machty/38bdc3057be92eadbb2e81efc59c4aac, #283

There is also an addon that attempts to accomplish some of the ideas below https://github.com/nickiaconis/ember-prefetch

I'd like to get more people thinking about this, since a gist gets lost pretty quickly.
The goal is to get some concrete ideas that could become an RFC and/or an addon.

What it should do

1. Only block child routes based on some value, like a blockChildRoutes hook (kind of like beforeModel)
2. modelFor that returns a promiseproxy (resolved if parent blocked).
3. model that returns an object and sets it on the controller (new default setupController)
4. resetController resets the keys set from model on the controller by default
5. Remove default model behaviour (no auto id lookup via type_key syntax in router definition)
6. Something else?

Example Code

This code is just an idea to get you thinking.

import Route from 'some-new-route-addon';

export default Route.extend({
  async data({ userId }) {
    // the 'profile' route isn't a parent, so we must pass the arguments
    // so that route gets the right data for us.
    // no arguments and nested means that the existing arguments from the router are used and it might have already been loaded.
    let { profile } = await this.dataFor('profile', { profileId: userId });
    
    return {
      profile,
      user: this.store.findRecord('user', userId)
    };
  }
});

// controller.user === user
// controller.profile === profile

Implementation

Sample implementation on top of existing Route class

import Route from '@ember/routing/route';
import { hash } from 'rsvp';

export default Route.extend({
  model() {
    if (typeof this.data === 'function') {
      let result = this.data.call(this, ...arguments);
    
      return hash(result);
    }
  },
  
  setupController(controller, resolved) {
    if (resolved) {
      let dataKeys = Object.keys(resolved);
      this.dataKeys = dataKeys;
      controller.setProperties(resolved);
    }
  },

  resetController(controller) {
    if (this.dataKeys) {
      let reset = this.dataKeys.reduce((obj, key) => {
        obj[key] = undefined;
        return obj;
      }, {});
      controller.setProperties(reset);
      this.dataKeys = undefined;
    }
  }
});

Relavent code

• Continue to the next route (not sure where this is called)
  https://github.com/tildeio/router.js/blob/682e63d7814de7d9aef47dee364da76900ae4877/lib/router/transition-state.js#L69
• Call the model hooks (called from above)
  https://github.com/tildeio/router.js/blob/master/lib/router/handler-info.js#L71

Docs

• router.js readme https://github.com/tildeio/router.js
• router.js architecture https://github.com/tildeio/router.js/blob/master/ARCHITECTURE.md

[ef4]

We would want to explicitly design what's meant by

3. model that returns an object and sets it on the controller (new default setupController)

Particularly around what automatic awaiting (if any) would still happen.

My preference would be that the model hook is an async function that resolves to a POJO, and then Object.assign(controller, thePOJO). This gives people full control over which values will be awaited, or not. Although we will need to teach them about the (non-ember-specific) pitfalls, like how:

return {
   foo: await foo(),
   bar: await bar()
}

is unnecessarily serial. In the above case, you'd be better off with RSVP.hash still.

[ef4]

I would also suggest that every other hook on the existing Route should be questioned and probably dropped. Like, I would drop activate, etc, and slim the API down to only model and a possible blockChildRoutes. Everything else that used to need to be special (like the redirect hook) stops needing to be special once you have the ability to dynamically await this.modelFor(...) or not.

[ef4]

Oh, and this document is missing what is perhaps my highest priority item, which is making the model hook always run, regardless of whether a person calls transitionTo() with params vs a model. That is a megatroll that needs to go away. Caching behavior belongs in a different layer than the router.

[wagenet]

I'm closing this due to inactivity. This doesn't mean that the idea present here is invalid, but that, unfortunately, nobody has taken the effort to spearhead it and bring it to completion. Please feel free to advocate for it if you believe that this is still worth pursuing. Thanks!