V2 Goals, Deprecations, etc

[NullVoxPopuli]

I think we should plan out what a V2 would look like.
There are some APIs that we could probably get rid of -- drop support for some legacy things that we don't need to care about (like super old Ember (maybe more for ember-changeset))

What I'd like to propose:

• drop support entirely for the validation APIs, in favor of something more composition friendly, like Yup. Colloquially at work, changeset-validations has had huge resistence, and is generally not meeting people where their mental models are. So, I'd like to propose that changests be just changesets, and we handle validation externally

• remove the following methods / properties:

  • cast - name is unintuitive
  • merge - how often is this used? why?
  • rollbackProperty - how often is rolling back a single property used? why?
  • changes or rename to valueOfChanges or something, as there is no change information here without context of original values

• add the following methods / properties:

  • changes (or changedValues): Add a more ergonomic structure to represent the changes structure #144
  • transactions: Store "transactions" to enable undo/redo history #145

• be immutable by default

  • calling execute doesn't deeply write the values to the source object unless that source object is passed to execute

  thoughts?

[snewcomer]

• yup or zod are great ideas! This would be a great API change
• deprecating and removing. I'm not sure.
• Yes 👍
• In theory immutability sounds nice, but I'm not sure practically how it would work or what extra hoops we would have to jump through to make it work.

[snewcomer]

drop support entirely for the validation APIs,

This would presumably remove the need for ember-changeset-validations?

[NullVoxPopuli]

In theory immutability sounds nice, but I'm not sure practically how it would work or what extra hoops we would have to jump through to make it work.

I think it'd be less work over all. I'll try to put up a prototype PR in the next few weeks.

ember-changeset-validations

Yeah, my thinking is that validation can be handled any number of ways (like, not even in js), and by many different libraries, like yup.

[BryanCrotaz]

addError versus pushErrors - seems like we don't need both.

In my proxy PR we don't need get and set any more. The changeset can be treated as a POJO. My thoughts are to ship this as a beta with deprecation warnings for all the clean up behaviour, then ship a cleaned up version as a new major version with a much cleaner API.

We should separate the typescript types into a public and private interface for changeset, and only export the public type. There's a lot of private API in the current changeset type.

[BryanCrotaz]

the test suite could do with some love. There are tests that say they're for changes that check the errors, and vice versa in the next test along. There are tests that rely on the exact order of errors - I've changed in my PR to .contains rather than .isEqual(array of errors)

[BryanCrotaz]

I don't think that changeset.save() should call model.save() - it's adding a lot of complexity and accidental footguns to save one line of code for the dev.

And if we remove that behaviour, let's also rename to apply() to lose the association with ED save()