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

Add AbortSignal to OpenSRPServer service #625

Closed
wants to merge 25 commits into from
Closed

Conversation

peterMuriuki
Copy link
Collaborator

@peterMuriuki peterMuriuki commented Dec 16, 2019

closes #554, close #356

  • Refactors the openSRPService to include an abort signal that can be used to abort pending Promises.
  • Adds growl to a few components.
  • Add cleanup functions to Functional components that aborts fetch calls to opensrp reason : 16eba72

@peterMuriuki peterMuriuki changed the title {WIP}Abort pending openSRPservice api calls on component unmount Abort pending openSRPservice api calls on component unmount Dec 19, 2019
Copy link
Contributor

@cKellyDesign cKellyDesign left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@p-netm this is looking great, love how you're using the useEffect return to abort the signal! Just a few requests below:

src/containers/forms/OrganizationSelect/index.tsx Outdated Show resolved Hide resolved
src/containers/pages/IRS/assignments/index.tsx Outdated Show resolved Hide resolved
Comment on lines 123 to 130
return () => {
controller.abort();
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might it be DRY'er to have a util function that does this instead of re-writing the anon function?

const controllerAborter = (controller) => { controller.abort() };
...
useEffect(() => {
  ...
  return controllerAborter(controller);
}, []);

(but with a better name than controllerAborter?)

the goal for abortFetch was to prevent the error of setStating on
an unmounted component. Meaning we only truly need abortFetch in
components whose async operations' callbacks have a setState call.

For most other components the async operations dispatch the response
to the store other than call a setState in the callback. i think
we should retain the callback's functionality since in this case it will
not cause the aforementioned error and also I believe we might want for
resolved data to be added to store if even if we unmount a component.
Refactor container tests that assumed mandatory usage of Abortsignal
@coveralls
Copy link

coveralls commented Apr 16, 2020

Coverage Status

Coverage decreased (-0.006%) to 76.795% when pulling c33e1cb on 554-abortFetch into 5b0a408 on master.

@peterMuriuki peterMuriuki changed the title Abort pending openSRPservice api calls on component unmount Add AbortSignal to OpenSRPServer service Apr 16, 2020
@peterMuriuki peterMuriuki requested review from moshthepitt, kelvin-muchiri, ciremusyoka and kahummer and removed request for FrankApiyo April 17, 2020 07:49
Comment on lines -74 to +70
if (loading === true) {
if (plan === null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this change?

).catch(e => {
throw e;
});
).catch(err => err);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to use displayError here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naah!, this is part of the test, I want the error to actually fail the test.

Copy link
Contributor

@moshthepitt moshthepitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we not using the official OpenSRP service package?

const allOpenMRSUsers = await loadOpenMRSUsers();
)
.list()
.catch((err: Error) => displayError(err));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to add a test that displayError is, in fact, called?

@@ -99,7 +98,7 @@ const IRSAssignmentPlansList = (props: PlanAssignmentsListProps) => {
loadData().catch(error => displayError(error));
}, []);

if (loading) {
if (plans.length < 1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we get 0 plans from the API, does this mean we will show the loading indicator forever?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i was thinking about this wrong. let me refactor.

}
}

useEffect(() => {
loadData().catch(err => displayError(err));
}, []);

if (loading === true) {
if (plans.length < 1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we get 0 plans from the API, does this mean we will show the loading indicator forever?

@moshthepitt
Copy link
Contributor

@p-netm can we add notes on how to proceed, and then possibly close this?

@moshthepitt
Copy link
Contributor

Going to close this.

@moshthepitt moshthepitt deleted the 554-abortFetch branch March 22, 2021 06:28
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

Successfully merging this pull request may close these issues.

Refactor setLoading usage Fix UpdatePlan bug
4 participants