Improved Ember Data and Ember Changeset support for relationships

Main problem

Create a changeset with a model, set a belongsTo relationship, change a belongsTo, and lastly revert back to original - the changeset will be dirty

Support for ember-data relationship objects has been fraught with issues. Precisely and often with async (default) relationships in Ember Data. This is due to them being behind a Proxy, thus a === will fail with the same relationship.

This issue is to track (and keep me honest) in either implementing better support for ember data relationships or improved documentation.

One idea that is floating around is to use @embroider/macros to see if e-d is installed and then we can importSync the model and do an instanceof Model check. I’ll be exploring this space in the next few weeks.

[snewcomer]

Also here is a working implementation using the Reference API and extending ember-changeset. (thanks Oliver!)

import { EmberChangeset } from 'ember-changeset';
import { TrackedArray } from 'tracked-built-ins';
import isEqual from 'lodash/isEqual';

/**
 * Ember Changeset copies Ember Data relationships,
 * which are a proxy to the actual related value.
 *
 * `hasMany` relationships are always treated as changes,
 * so manipulations to the array do not affect the underlying relationship
 * until the changeset is executed.
 */
export default class RawRelatedModelsChangeset extends EmberChangeset {
  // keys for the hasMany relationships we're tracking
  hasManyProperties = [];

  /**
   * Returns the unwrapped related model for `belongsTo` relationships,
   * or a TrackedArray of models (for `hasMany`).
   *
   * @inheritdoc
   * @override
   */
  get(key) {
    if (this.data[key] && !this._changes[key]) {
      switch (this.data.relationshipFor?.(key)?.meta?.kind) {
        case 'belongsTo':
          return this.data.belongsTo(key).value();
        case 'hasMany':
          this.hasManyProperties.push(key);
          this._changes[key] = new TrackedArray(this.data.get(key).toArray());
          break; // the change will be returned by `super.get`
        default:
          break;
      }
    }

    return super.get(key);
  }

  /**
   * `safeGet` returns the original value for comparison,
   * but not when initially fetched (which is done in `get`)
   *
   * @inheritdoc
   * @override
   */
  safeGet(obj, key) {
    if (obj.relationshipFor?.(key)?.meta?.kind == 'belongsTo') {
      return obj.belongsTo(key).value();
    }
    return super.safeGet(obj, key);
  }

  /**
   * Because `hasMany` are TrackedArrays,
   * this will recompute when they change
   * (assuming they are used in a tracking context).
   *
   * Also contains an override to correctly compare Date objects.
   *
   * @inheritdoc
   * @override
   */
  get isPristine() {
    let pristine = super.isPristine;

    if (!pristine) {
      const allDates = this.changes.filter(({ value }) => value instanceof Date);

      // if the only changes are dates,
      // and those are all the same,
      // override pristine state
      if (this.changes.length == allDates.length) {
        pristine = allDates.every(({ key, value }) => {
          return value.getTime() == this.data.get(key).getTime();
        });
      }
    }

    // check the arrays and see if any differ
    if (pristine) {
      const arraysDiffer = this.hasManyProperties.find(prop => {
        return this._changes[prop]
          && !isEqual(this._changes[prop], this.data.get(prop).toArray());
      });

      if (arraysDiffer) {
        return false;
      }
    }

    return pristine;
  }
}

[sandstrom]

@pernambucano (and anyone else who’s interested in this), consider sponsoring @snewcomer via Github sponsors, so he can spend more time on this library (ask your employer to pay). We sponsor him with $100 every month.