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

Throw in reducer is not cancel computation of other reducers #90

Closed
artalar opened this issue May 1, 2019 · 6 comments
Closed

Throw in reducer is not cancel computation of other reducers #90

artalar opened this issue May 1, 2019 · 6 comments
Labels
invalid This doesn't seem right

Comments

@artalar
Copy link
Contributor

artalar commented May 1, 2019

If someone forwarded you here, this is an outdated discussion which can not and must not be used as proof of the issues of any kind.

Calling of pure function cannot be detected by definition, thereby preventing from using them in a suggested way
That is, the inability to throw an exception is what make functions pure.
And that is what effects were being made for: effect is a function, which might throw an exception, which triggers a fail branch, which you can subscribe on.

Reducers in .on, functions in .map are pure. You shall not branch them by throwing exceptions. This is not an issue, this is what makes computations predictable and stable.

Original issue:

Code to reproduce the issue:
repl

Expected behavior:
Throw all computation

Actual behavior:
Receive wrong data

Versions of packages used:
0.18.16

@artalar artalar added bug Something isn't working needs triage labels May 1, 2019
@zerobias zerobias added enhancement New feature or request and removed bug Something isn't working needs triage labels May 1, 2019
@zerobias zerobias added this to the 19.0.0 milestone May 1, 2019
@artalar

This comment has been minimized.

@zerobias
Copy link
Member

zerobias commented May 1, 2019

related issue #51

@artalar
Copy link
Contributor Author

artalar commented Jun 13, 2019

Workaround

@zerobias zerobias removed this from the 20.0.0 milestone Jun 27, 2019
@zerobias zerobias added invalid This doesn't seem right and removed enhancement New feature or request labels Jun 27, 2019
@zerobias
Copy link
Member

Throwing errors is the completely wrong way to organize business logic, you don't need it at all because of filters, created especially for such cases. It more readable and significantly less error-prone than dealing with throw on a daily basis https://share.effector.dev/0zxWY3px

@artalar
Copy link
Contributor Author

artalar commented Jun 27, 2019

@zerobias
The predicate for the throw is not validation (from business logic) - it is just an example to testify a problem

@zerobias
Copy link
Member

Solution testified as well. You are trying to blame for the lack of support of double binding which latest significant appearance was in AngularJS more than five years ago

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

2 participants