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.

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

Restore non-enumerability of resultFields[ID_KEY]. #3544

Merged
merged 1 commit into from
Jun 5, 2018

Conversation

benjamn
Copy link
Member

@benjamn benjamn commented Jun 5, 2018

The change to create a simple property rather than using Object.defineProperty was originally made in the interest of performance, but it seems to be causing problems for some users: #3300 (comment)

@benjamn benjamn self-assigned this Jun 5, 2018
@apollo-cla
Copy link

apollo-cla commented Jun 5, 2018

Warnings
⚠️

There are library changes, but not tests. That's OK as long as you're refactoring existing code

Generated by 🚫 dangerJS

@benjamn benjamn force-pushed the restore-non-enumerability-of-ID_KEY branch from e92f839 to 3960163 Compare June 5, 2018 18:34
@benjamn benjamn merged commit e6c9238 into master Jun 5, 2018
benjamn added a commit that referenced this pull request Jun 5, 2018
Restoring non-enumerability of the ID_KEY Symbol in #3544 made ID_KEY
slightly more hidden from application code, at the cost of slightly worse
performance (because of Object.defineProperty), but tests were still
broken because Jest now includes Symbol keys when checking object equality
(even the non-enumerable ones).

Fortunately, given all the previousResult refactoring that has happened in
PR #3394, we no longer need to store ID_KEY properties at all, which
completely side-steps the question of whether ID_KEY should be enumerable
or not, and avoids any problems due to Jest including Symbol keys when
checking deep equality.

If we decide to bring this ID metadata back in the future, we could use a
WeakMap to associate result objects with their IDs, so that we can avoid
modifying the result objects.
benjamn added a commit that referenced this pull request Jun 6, 2018
Restoring non-enumerability of the ID_KEY Symbol in #3544 made ID_KEY
slightly more hidden from application code, at the cost of slightly worse
performance (because of Object.defineProperty), but tests were still
broken because Jest now includes Symbol keys when checking object equality
(even the non-enumerable ones).

Fortunately, given all the previousResult refactoring that has happened in
PR #3394, we no longer need to store ID_KEY properties at all, which
completely side-steps the question of whether ID_KEY should be enumerable
or not, and avoids any problems due to Jest including Symbol keys when
checking deep equality.

If we decide to bring this ID metadata back in the future, we could use a
WeakMap to associate result objects with their IDs, so that we can avoid
modifying the result objects.
benjamn added a commit that referenced this pull request Jun 6, 2018
Restoring non-enumerability of the ID_KEY Symbol in #3544 made ID_KEY
slightly more hidden from application code, at the cost of slightly worse
performance (because of Object.defineProperty), but tests were still
broken because Jest now includes Symbol keys when checking object equality
(even the non-enumerable ones).

Fortunately, given all the previousResult refactoring that has happened in
PR #3394, we no longer need to store ID_KEY properties at all, which
completely side-steps the question of whether ID_KEY should be enumerable
or not, and avoids any problems due to Jest including Symbol keys when
checking deep equality.

If we decide to bring this ID metadata back in the future, we could use a
WeakMap to associate result objects with their IDs, so that we can avoid
modifying the result objects.
benjamn added a commit that referenced this pull request Jun 9, 2018
Restoring non-enumerability of the ID_KEY Symbol in #3544 made ID_KEY
slightly more hidden from application code, at the cost of slightly worse
performance (because of Object.defineProperty), but tests were still
broken because Jest now includes Symbol keys when checking object equality
(even the non-enumerable ones).

Fortunately, given all the previousResult refactoring that has happened in
PR #3394, we no longer need to store ID_KEY properties at all, which
completely side-steps the question of whether ID_KEY should be enumerable
or not, and avoids any problems due to Jest including Symbol keys when
checking deep equality.

If we decide to bring this ID metadata back in the future, we could use a
WeakMap to associate result objects with their IDs, so that we can avoid
modifying the result objects.
benjamn added a commit that referenced this pull request Jun 12, 2018
Restoring non-enumerability of the ID_KEY Symbol in #3544 made ID_KEY
slightly more hidden from application code, at the cost of slightly worse
performance (because of Object.defineProperty), but tests were still
broken because Jest now includes Symbol keys when checking object equality
(even the non-enumerable ones).

Fortunately, given all the previousResult refactoring that has happened in
PR #3394, we no longer need to store ID_KEY properties at all, which
completely side-steps the question of whether ID_KEY should be enumerable
or not, and avoids any problems due to Jest including Symbol keys when
checking deep equality.

If we decide to bring this ID metadata back in the future, we could use a
WeakMap to associate result objects with their IDs, so that we can avoid
modifying the result objects.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants