Q: Support for v4.8+

[basz]

Is someone working on bringing support for ember-data 4.8+?

[wozny1989]

I'm also curious, tried investigate by our self but internal changes in ember-data killed me

[deanmarano]

Based on this blog post, I believe efforts are going to target ember-data 4.12.

[knownasilya]

@dwickern and @runspired probably have the most insight into this

[dwickern]

ember-data 3.28 - 4.6 uses RecordData v1 which is implemented by model-fragments v6
ember-data 4.7 - 4.11 uses RecordData v2 (RFC 461) which is not currently supported by model-fragments
ember-data 4.12 - 5+ has built-in support for fragments (?)

In #417 (comment) Chris suggested we end support for this addon at ember-data 4.6 and have users upgrade straight to 4.12. @runspired is this still what you would recommend? How would a migration look?

[runspired]

TL;DR The path ahead is as follows. I'll be working with @RSG and anyone else interested to achieve this.

The Promised Land: 4.12+

Our main goal should be to make ModelFragments compatible with 4.12. The release with 4.12 support will be ModelFragment's last, though obviously patches as necessary as long as some folks are on it.

Users of ModelFragments would then upgrade to 4.12, install (at least) @ember-data/schema and @ember-data/schema-model which are the two packages we are guaranteeing the 5.x versions of will support 4.12, and then begin incrementally re-writing their apps to use SchemaModel instead of Model+ModelFragments.

The Road to 4.12

First Stop, Improve 4.6 support

As the Compatibility table points out, currently ModelFragments hopes to support up to 4.6. In practice so far @RSG has noted that at least for Square there seem to be blockers to getting beyond 4.0. So for starters we'll want to figure out what those are and ensure they and anyone else that hasn't quite been able to get to 4.6 gets to 4.6.

Second Stop, Choose Our Path

Option 1 - Write A Custom Cache for 4.7+

In this approach the bulk of the application's refactoring responsibility occurs in 4.12.

In this path, we focus on keeping the public DX and APIs that ModelFragments has today, but change the underlying implementation to conform to expected cache behaviors.

For non-ModelFragments users, 4.11 was a pretty solid landing version before more substantive changes to the internals in 4.12 introduced a number of dragons.

The V2 RecordData version in 4.7-4.11 is very similar to the final version that shipped in 4.12. If we focus on building a custom singleton RecordData to support 4.7-4.11, the leap to supporting 4.12 is likely such that we can handle 4.7-4.12 in one go, but even if we can't easily we should be close enough that it won't be a big ModelFragments rewrite to get to 4.12

But this is also dicey, as this means one big-bang rewrite for ModelFragments. And that rewrite will inevitably come with its own unexpected, unintentional but observable and frustrating deviations in behavior. And to be clear, I do mean a full rewrite, because ultimately the way ModelFragments reasons about and uses the cache and transforms today is incorrect and is what drives the private API usage.

Option 2 - Write A Custom Model for 4.6+

In this approach the bulk of the application's refactoring responsibility occurs in 4.6

We keep EmberData's cache (likely zero changes needed) and instead focus on changing the ModelFragments DX and APIs. We would effectively be attempting to adopt EmberData's SchemaModel ~6 versions early. I think it is possible; though it would not be an exact match due to some limitations of the cache in versions before 4.12.

The migration path for this then involves users getting to 4.6 + Today's ModelFragments, and then incrementing ModelFragments to the major that supports 4.6+ and incrementally rewriting from ModelFragments to the "FragmentSchemaModel", and finally bumping to 4.12 and replacing model-fragments with just EmberData.

I believe in this approach the risks are likely similar, but that if we are careful we can keep SchemaModel and FragmentSchemaModel close enough aligned that the 4.12 swap is relatively painless. The downside is that users won't gain access to any other new features of EmberData (Request, Collection, Pagination primitives, builders) until after a potentially long migration spent on 4.6, and EmberData's patterns will change substantially during 5.x pushing towards newer DX that 4.x supports today.

Parting Thoughts

I leave it to the community to decide which of these paths feels best. I have no apps which use ModelFragments and thus cannot accurately judge the right path before you.

I'll be talking quite a bit in depth about the DX and Feature set of SchemaModel at EmberConf this year. Likely that talk will serve as a good grounding point to reflect on which approach feels more correct.

[Gorzas]

and then begin incrementally re-writing their apps to use SchemaModel instead of Model+ModelFragments.

I don't know if I understood correctly, but I assume that v4.12 is the last version of Ember Data this library is going to support because a similar behavior is available to develop in ED v5.x+. @runspired Is it possible to have docs of how to migrate from ModelFragments to SchemaModel?

[runspired]

@Gorzas the migration path hasn't been built as its something we'll discover together as we build SchemaRecord / figure out the nice path for folks here. This said, 4.12 is a key part of that path. I recently added a wg-model-fragments channel to the ember discord and posted more about our 4.12 support on the blog