Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extend test coverage to sync relationships #409

Merged
merged 4 commits into from
Jan 22, 2020
Merged

Extend test coverage to sync relationships #409

merged 4 commits into from
Jan 22, 2020

Conversation

andreyfel
Copy link
Contributor

@andreyfel andreyfel commented Jan 17, 2020 •
edited
Loading

This PR extends test coverage for sync and async relationships.

@andreyfel andreyfel changed the title Tests bug for sync belongsTo Extend test coverage to sync relationships Jan 18, 2020
@andreyfel andreyfel requested a review from snewcomer January 18, 2020 10:30
@snewcomer
Copy link
Collaborator

I like this!! 👍 Happen to know why the two tests are failing?

Also to confirm, there is no addon code changes needed right?

@andreyfel
Copy link
Contributor Author

After recent changes added in #404 those 2 tests started failing. It is caused by the fact that isEmberDataObject util method doesn't work with sync relationships. We need a more reliable approach.
cc: @josemarluedke

@snewcomer
Copy link
Collaborator

snewcomer commented Jan 18, 2020 •
edited
Loading

Great points! Yes you are right. A couple of points.

  1. We need to add a check for obj._internalModel or the like although is not comprehensive.
  2. We aren't checking if is a type of array in the referenced PR before doing Object.assign. So it would have to look something like this...

if (!Array.isArray(result) && isObject(content[baseKey]) && !isEmberDataObject(content[baseKey])) {

@snewcomer
Copy link
Collaborator

I merged the Array check #413

@andreyfel
Copy link
Contributor Author

_internalModel is not a public API, so, it can be removed at any moment. I've asked for advice in the ED discord channel.

@andreyfel
Copy link
Contributor Author

@runspired suggested that we should ask the user if the object is an Ember Data Model or not.
So, we should either have something like a flag passed in the Changeset constructor which says if an object is an ED model or even a separate class for ED models.

@snewcomer
Copy link
Collaborator

snewcomer commented Jan 19, 2020 •
edited
Loading

@andreyfel I like the idea of explicitly saying it is an EmberData object. However, this might get a little murky when an object's nested values are EmberData objects.

A few thoughts.

  1. We can bring back the changeset-get helper. Ref Bring back changeset-get for nested getter #414. Ultimately, requesting for the leaf key should actually ask for the leaf key and ideally the logic introduced in Fix changeset get for nested properties with changes #404 shouldn't be necessary.
  2. However, based on master, it is necessary if the end user calls changeset.get('user').lastName when only user.firstName has changes because right now, lastName will be the model value. I think there is a fundamental problem I have built into the proxied get that has led this discussion astray. It is this line - https://github.com/poteto/ember-changeset/blob/master/addon/-private/validated-changeset.ts#L896. changeset.get('user').lastName should return undefined and not the original value on the model. Follow up: This is a bad idea. Users build changesets in forms and need access to the original values that render as values in the form.

The combination of these two (the second be always request the combination that leads to the leaf key) would alleviate all our problems, albeit, a stricter API. Do you have any thoughts?

@snewcomer snewcomer mentioned this pull request Jan 20, 2020
Merged
snewcomer
snewcomer reviewed Jan 21, 2020
View reviewed changes
tests/integration/main-test.js

assert.equal(user.get('profile.firstName'), 'Bob', 'Profile is set on user');
assert.equal(user.get('dogs.firstObject.breed'), 'rough collie');
assert.equal(user.get('dogs.lastObject.breed'), 'Münsterländer');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI I don't think these array accessors work (at the moment at least)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, they work for EmberArray and dogs is an EmberArray.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh you are right...we are passing in Ember's getter...

@andreyfel
Perform tests with sync relationships
d4093fb 
Ember-changeset is supposed to work with sync and async relationships.
Behavior differs significantly, we need to test for both types of
relationships.

Create `sync-user` model which is mirroring the `user` user model but
it uses sync relationships.

Refactor tests for users to be executable for both types of users.
@andreyfel
Fix test for sync belongsTo()
7a5b438 
In case of sync `profile` relationship user.profile is null after
executing the changeset. For safe check we need to use
`user.get('profile.firstName')` vs
`user.get('profile').get('firstName')`

user.get('profile') is always a proxy in case of async belongsTo(),
and it doesn't correlate with calling `save()` on the user model.
So, this check doesn't really check anything.
For the sync relationship this check fails, because profile is null
after performing `execute()`
@andreyfel
Add tests for initially empty relationships
4d3fb3d
@andreyfel
Bandaid fix to merge tests in
897af38 
Add more heuristics to support sync belongsTo() relationships.
A preferable fix is to let user specify if an object is ED Model or not.
One of the options is passing a flag in the constructor or having a
separate implementation for ED Models.
@snewcomer
Copy link
Collaborator

@andreyfel Is this PR g2g? I'm happy with it in its current state as long as the latest master is merged in...

@andreyfel
Copy link
Contributor Author

Yes, I've rebased it today. The pr can be merged and we can think of refactoring after that.

snewcomer
snewcomer approved these changes Jan 22, 2020
View reviewed changes
Copy link
Collaborator

@snewcomer snewcomer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lovely! What a nice PR!

@snewcomer snewcomer merged commit 0a30324 into adopted-ember-addons:master Jan 22, 2020
@andreyfel andreyfel deleted the sync-belongs-to branch January 23, 2020 08:26
@andreyfel
Copy link
Contributor Author

@snewcomer yesterday I wrote a comment but it appears I forgot to publish it.
Regarding object's nested values are EmberData objects. Is this feature supported? Are there are tests for that scenario? Maybe we don't need to support that?
Thus PR is kind of a bandaid fix to make tests pass and merge them in but I believe we should do something about it in the long term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@snewcomer snewcomer snewcomer approved these changes

Assignees
No one assigned
Labels
bug enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@andreyfel @snewcomer