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

Create annotation that allows you to mutate observable members directly #3200

Closed
ghsolomon opened this issue Nov 9, 2022 · 3 comments · Fixed by #3206
Closed

Create annotation that allows you to mutate observable members directly #3200

ghsolomon opened this issue Nov 9, 2022 · 3 comments · Fixed by #3206

Comments

@ghsolomon
Copy link
Contributor

If possible- create an annotation that overrides the Javascript setter for a member and wraps it with runInAction so developers can write code like this:

@mutatable myProperty; // Makes myProperty observable and wraps the JS setter with `runInAction`
myProperty = newValue // "Under the hood", executes: `runInAction(() => myProperty = newValue)`

@lbwexler
Copy link
Member

Hi @ghsolomon

So a really fascinating discussion about this in the mobx community from 2017. Mwestrate proposese something called @box.

mobxjs/mobx#839
(its a very long thread, but worth reading through to the end)

Makes me think:

a) do we really need to be using strict mode? What is it really getting us?
b) If we do continue to use strict mode we should probably introduce this.

The name you mention is interesting, and seems more intuitive (to me) then @box. I wish that we had not already used up "bindable"!

@lbwexler
Copy link
Member

I think the @mutable term implies that without it, somehow the data is immutable (which is definitely not the case).

I would probably lean toward just enhancing @bindable so that it continues to create a setter, but also creates a set method. The only problem there would be with existing uses that are overriding the setter that @bindable creates. That seems like a weird usage, but definitely one we have supported.

@lbwexler
Copy link
Member

As to what "strict/enforceActions" mode is getting us -- I really think it just comes down to a fairly coarse way of ensuring that applications use @action wherever possible to generate transactions and avoid extra re-rendering/reactions. I guess the fear is that if you don't require it people won't use it at all!

@lbwexler lbwexler linked a pull request Nov 25, 2022 that will close this issue
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants