Overhaul store.push and store.pushPayload

[pangratz]

Rendered

[rlivsey]

s/intented/intended/

[pangratz]

I started working on a proof of concept https://github.com/pangratz/ember-data-store-push-improvements

[josemarluedke]

Our team would love to see this landed. We have our backend api as a thrift server and we use Ember Data in the frontend. Basically we had to create some random conversions from our api response to JSON API format. Having something like this would help us organize our code and most importantly, test it easily with patterns in place. ❤️

[sandstrom]

Nice writeup and thanks for tackling this! 🏆

Some thoughts:

1. I'd prefer pushReference over pushRef. It'll be consistent with how BelongsToReference and HasManyReference are named. Also, this method call won't be repeated throughout the app (like myRecord.save()), so having a short method name isn't important.
2. Is there a planned release date for Ember Data 3.0? If so we could keep this under a flag for a while and (possibly) go with store.normalize (instead of store.normalizePayload) as breaking change in 3.0.
3. Instead of adding pushRef/pushReference, how about re-using store.push or store.pushPayload + an option, e.g. method(..., { reference: true }) to have it return references? To avoid having three push-like methods on store. Don't know if this is feasible though.

[pangratz]

Hey @sandstrom, thanks for your feedback.

I've updated the RFC so there is a pushDocument now, which returns a DocumentReference.

I am not too convinced about the additional parameter, as this would return a different type for the method, depending on the passed in function. One could argue, that this is already the case since store.push either returns a record or an array of records. But I would still prefer a dedicated method for returning a reference.

[sandstrom]

@pangratz sounds great!

I agree that an additional parameter (3) has some drawbacks. I was mainly trying to figure out was of keeping the API surface down. What do you think about using 3.0 to reduce the number of normalization methods on the store? But this isn't a major thing, overall I'm very much in favour of this proposal!

[pangratz]

We should definitely make sure the normalization story is better in the future and tidy that up with 3.0 seems like a reasonable idea! Hopefully all this is fleshed out and implemented before we reach that 😃

[rwjblue]

I think we ultimately want to deprecate store.normalizePayload completely (its just not the responsibility of the store to do serialization/deserialization).

After todays ember-data core team meeting we moving this into "FCP to close".

[runspired]

normalizePayload doesn't even exist anymore :)