store.createRecord should be async?

[rwjblue]

While working on ember-qunit-codemod (which converts existing QUnit tests to the structure proposed in emberjs/rfcs#232) I have ran into something a bit surprising to me around store.createRecord(...) and I think it may be something that we should address (or at least discuss).

Currently, ember-data uses batching in a few locations:

• creation/updating of the various live record arrays

  data/addon/-private/system/record-array-manager.js

  Line 96 in ce606b1

  emberRun.schedule('actions', this, this._flush);

• Transitioning an internal model into _any_state (via InternalModel.prototype.transitionTo)

  data/addon/-private/system/model/internal-model.js

  Line 847 in ce606b1

  this.updateRecordArrays();

  data/addon/-private/system/model/internal-model.js

  Lines 1017 to 1019 in ce606b1

  	updateRecordArrays() {
  	this.store.recordArrayManager.recordDidChange(this);
  	}

To me, this effectively means that anything that runs through these paths is actually async (which roughly seems like "everything"?) and probably should return a promise.

---

Concretely, the issues I'm facing in testing land are:

• store.createRecord(...) must be wrapped in a Ember.run to avoid triggering the auto-run assertion, in the prior moduleForModel API this was hidden from users behind this.subject(), but the new API is specifically intended to remove these extra "test only API's" and instead have users do what they would actually do in normal app code

• calling run(() => store.createRecord(...)) in test behaves significantly different than what most users would do in "normal" app code (store.createRecord(...))

[bmac]

We talked about this at a recent Ember Data core meeting and it was agreed that createRecord should be made sync. We suspect the performance improvements with deferring relationship and record array updates don't make a big of an impact for createRecord then they do with pushing many records from the server.

[rwjblue]

👍 thank you for summarizing