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

Handle results of async operations triggered from within withHandlers in correct order #37

Open
viacheslaff opened this issue Apr 17, 2018 · 0 comments

Comments

@viacheslaff
Copy link
Contributor

If user triggers an async operation method, such as fetching data from the server, there's no specific time when the result will arrive and be processed. It's not a problem while there's only one async process running. But when two or more requests are running, then we cannot guarantee that the last result to arrive is from the request that was sent last.

This is how it can look over time:

Time        ------------------------------------------>
Request #1  -----REQ1--------------------------RESP1-->
Request #2  ------------REQ2-------RESP2-------------->

Multiple requests can be a result of user triggering fetching too frequently, or the server responding too slowly. It's the things beyond developer's control, but the code should handle those cases.

Example of the code having the issue. props.setRows(res.data) can be executed at any time, even when result for the response which is no longer relevant arrives. And as the result, wrong info will be displayed to the user:

withHandlers({
    fetchRows: (props, app) => (params) => {
        props.setLoading(true);

        app.get('api').getData(params)
            .then((res) => {
                props.setRows(res.data);
                props.setLoading(false);
            })
            .catch((error) => {
                props.setErrorMessage(error.message);
                props.setLoading(false);
            });
      }
});

Generally, it's preferred to handle the result of the last request, ignoring all previous requests (or cancelling them). This is generally the approach for read operations. It's the logic that switchMap has.

While for write operations, you might want to queue them (concatMap) or receive all responses asynchronously (mergeMap).

So the question is how we can support such logic with current API or by changing API that we have?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant