I just stumbled onto this post from @nragaz is ember data just unfinished or fundamentally broken - if you can get past the title he has some solid points. The one that hit-home for me is:
I’ve started to wonder if Ember Data would actually work better if it strengthened the concept of transactions into something more like an “editing context” that would let you isolate sets of client-side data changes until they are actually persisted. Models in the base store would not be editable by the user directly — they could only be updated by the server (e.g. after a model is saved or if changes are propagated through WebSockets).
Most ember-data apps i’ve seen uses transactions as editing-context, it’s a really solid use case. Consider that for vast majority of apps the ‘source of truth’ for our data is the server. The client will typically load subset of all records. It’s also very common that the data will be modified by system or other users and need to be pushed to our app. A typical end-user will modify very small % of total records - for the most part a record does not become ‘real’ until persisted via api. Even persistent-local-storage scenario is typically just caching values for later update.
My gut is that a ton of the complexity/bugs/issues in ember-data might be resolved by a few subtle changes in the architecture. We might shift a few basic assumptions, maybe not exactly as this post suggests, but let’s kick around a few ideas like:
- Is the storage adapter a better ‘source of truth’ for model data?
- Can we treat identity-map as a read-only cache?
- What if we allow sets of client-side changes (one or more transactions) to be isolated into an “editing context”?
- Could live-queries
find(), filter(), etc.have option to favor source-of-truth data or include changes from one or more editing context?
- What hooks should be in place to deal with conflict-resolution?
- Perhaps contexts could be persisted to localstorage and committed later, enabling offline mode
It reminds me of how we had to collectively kick the tires of ember-router-v1 until patterns/best-practices started to emerge. By last summer it was pretty clear that the original design was not quite right. While the core app-as-series-of-states thing was awesome, the hierarchical structure caused a ton of friction. Once the new concept was in place progress moved quickly and we ended up in a far better place.
I think that’s where we are with ember-data now. Thoughts?