-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
The value returned from computed(() => ...)
shouldn't have a set(...)
method
#3767
Comments
Please follow the issue template when filing a bug.
…On Tue, 26 Sept 2023, 09:52 Sebastian Malton, ***@***.***> wrote:
Current Behaviour:
computed(...) currently returns the IComputedValue<T> type which has the
following signature:
interface IComputedValue<T> {
get(): T;
set(value: T): void;}
However, actually using that .set(...) results in an error being thrown TypeError:
cannot call function undefined.
Expected Behaviour:
computed(...) should return a type that only has the get() field as valid.
Notes:
I tried providing a set impl through the options for computed but the
same was still the case
versions:
mobx -> 6.10.9
—
Reply to this email directly, view it on GitHub
<#3767>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN4NBH7PPUFWTIWSMNNIGTX4LMYZANCNFSM6AAAAAA5HYOYPY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Would you like me to recreate this filling then? |
yes, or copy in the template. |
done |
The above example is working as expected if no custom setter is defined. There is a .set method, and you are able to call it successfully, it just throws because the preconditions aren't met, not because the method doesn't exist. N.b. note that in general in an issue report a reproduction is something "runnable". For further follow up questions make sure to attach a codesandbox or something. |
Sure, but won't it be better for |
Well, '.set' is a valid API of |
It is actually rather easy, see my playground here |
Intended outcome:
Have strict and complete type safety to help with refactoring.
Actual outcome:
The return type of
computed()
andobservable.box()
both haveset()
andget()
methods, but the return type ofcomputed()
doesn't have aset()
method so a type error is thrown at run time.How to reproduce the issue:
Versions
The text was updated successfully, but these errors were encountered: