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

Proxied observable class prevents altering descriptors in getOwnPropertyDescriptor trap while proxied observable object allows. #3742

Closed
n-lark opened this issue Aug 10, 2023 · 2 comments
Labels

Comments

@n-lark
Copy link

n-lark commented Aug 10, 2023

Intended outcome:

Attempting to proxy an instance of a class, and within that proxy change the enumerability of specific keys through getOwnPropertyDescriptor trap.

Actual outcome:

See codeSandbox, when proxying the instance of a class, any attempts to alter the enumerability of an observable property through getOwnPropertyDescriptor trap throws the error:

TypeError: 'getOwnPropertyDescriptor' on proxy: trap returned descriptor for property 'id' that is incompatible with the existing property in the proxy target

This works with basic objects, however something about classes prevents the altering of any enumerability through the proxy. I believe this may be intentional, due to the warning given for the linting option safeDescriptors:

MobX makes some fields non-configurable or non-writable to prevent you from doing things that are not supported or would most likely break your code.

Is this a bug or is this intentional behavior? I would like to find a way to make this possible for my use case with classes, and it seems strange that objects would allow this but classes wouldn't. Any guidance is appreciated.

How to reproduce the issue:

See codeSandbox.

Also, I apologize if this isn't really a bug and more of a question.

@urugator
Copy link
Collaborator

urugator commented Aug 10, 2023

Don't have time to elaborate, but the motivation behind the behavior is mostly explained here #2641 (point 2.)

@n-lark
Copy link
Author

n-lark commented Aug 11, 2023

Thank you for the explanation @urugator, closing this.

@n-lark n-lark closed this as completed Aug 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants