Hey Jordan thanks :)

For the first question, ember-concurrency removes a lot of the boiler plate code you might need if you were just using plain Ember.run methods, examples can be seen here and here

In this post everything was put into an acceptance-test just to give a few examples of testing, in production it would be preferable to have the test cases covered between unit, integration and acceptance. Since the tasks involve saving-data it wouldn’t be advisable to place them in a component, but we can split up some of the concerns so for example the nav in editor.hbs file might be split up into a component like follows

// editor.hbs 

{{nav-component 
   isSaving=saveModelTask.isRunning 
   isErrored=saveModelTask.last.error 
   retrySave=(perform saveModelTask)
}} 

// nav-component.hbs 
  <section class="container">
    <h4 class="float-left">My Editor</h4>
    {{#if isSaving}}
      <h4 class="float-right">Saving..</h4>
    {{else if isErrored}}
      
      <a {{action (action retrySave)}} class="float-right">
        <h4>Failed Retry?</h4>
      </a>
    {{/if}}
  </section>

And then you can write an integration test like normal on it. While in the unit test you can write the tests around save timings force-saves ect and finally in the acceptance tests you can write a runthrough test to see does it actually hit the db on save.

Also as an aside the tests around timing can be written much better by stubbing the ember run loop an example here