title: Best practice to organize list, view, create and update routes in Ember.js
body: <p>Working for a few years with ember.js now, it's still not quite clear to me, what should be considered as best practice for structuring list, view, create and update routes.</p>
  
  <p>The projects I've worked with so far mostly used to routing trees per entity. The pluralized entity name for listing with a subroute for create and the singular entity name for detail view with a subroute for editing. As an example a <code>post</code> model would have these for routes: <code>/posts</code> for listing posts, <code>/posts/new</code> for the create functionality, <code>/post/:post_id</code> for showing a single post and <code>/post/:post_id/edit</code> for editing that one. The corresponding router would look like this one:</p>
  
  <pre><code>Router.map(function() {
    this.route('post', { path: '/post/:post_id' }, function() {
      this.route('edit');
    });
    this.route('posts', function() {
      this.route('new');
    });
  });
  </code></pre>
  
  <p>This approach is working quite nicely for detail and edit view cause they are sharing the same model. So the model hook of the edit route could just reuse the model of the detail view route. In ember code this looks like the following:</p>
  
  <pre><code>// app/routes/post.js
  import Route from '@ember/routing/route';
  
  export default Route.extend({
    model({ post_id }) {
      return this.get('store').findRecord('post', post_id);
    }
  });
  
  // app/routes/post/edit.js
  import Route from '@ember/routing/route';
  
  export default Route.extend({
    model() {
      return this.modelFor('post');
    }
  });
  </code></pre>
  
  <p>Normally we would return a collection of posts from <code>posts</code> route model hook and not implementing the model hook of <code>posts.new</code> route (or returning a POJO / Changeset there depending on architecture but that's not the question here). Assuming we are not implementing the model hook of <code>posts.new</code> the routes would look like:</p>
  
  <pre><code>// app/routes/posts.js
  import Route from '@ember/routing/route';
  
  export default Route.extend({
    model({ post_id }) {
      return this.get('store').findAll('post');
    }
  });
  
  // app/routes/posts/new.js
  import Route from '@ember/routing/route';
  
  export default Route.extend({
  });
  </code></pre>
  
  <p>But now this approach is not working well anymore cause a transition to <code>posts.new</code> route is blocked until the collection of <code>posts</code> are loaded. Since we don't need this collection to create a list of posts (at least if we only show them in <code>posts.index</code> route and not on all subroutes) this doesn't feel right.</p>
  
  <p><em>Side note for those ones not that familiar with ember: Nested routes model hooks are executed in order. So in our case first the model hook of application route, afterwards posts route and then posts.new route waiting for any promise executed by one of them.</em></p>
  
  <p>So what should then be considered as best practice?</p>
  
  <ul>
  <li>Should the fetching of posts live in <code>posts.index</code> route if we are not showing them on nested routes?</li>
  <li>Shouldn't the create route be a nested under the list route? So should we have <code>posts</code>, <code>post-new</code>, <code>post</code> and <code>post.edit</code> routes? Feels confusing since the post related code is splited over three route trees. Also it would go against the goal of the <a href="https://github.com/emberjs/rfcs/pull/143" rel="nofollow noreferrer">improved file layout</a> being developed currently since the code would be splitted over three directories.</li>
  <li>Should we just take the tradeoff of unnecessarily fetching the collection of posts since mostly the user flow comes from this route before the creation route and therefore the model hook is in most cases already loaded anyway?</li>
  </ul>
  
  <p>Would appreciate any thoughts on that one. Decided to not ask that question in the community slack to better document the answer.</p>