You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)`
The text was updated successfully, but these errors were encountered:
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.
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!
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:The text was updated successfully, but these errors were encountered: