-
Notifications
You must be signed in to change notification settings - Fork 35
refactor: [DHIS2-20281] run rule engine asynchronously #4396
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
base: master
Are you sure you want to change the base?
Conversation
Replaces confusing logic which did not quite work.
simonadomnisoru
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work @superskip on adding the WebWorker! 👏
I added a few comments. I'm also wondering if we know of any specific implementations that are currently running slowly due to the rules engine, and if we can obtain their DB and use it to properly test this PR. On the Sierra Leone DB, I didn't really notice any improvement in page speed and performance.
Thank you!
...re_modules/capture-core/components/DataEntries/Enrollment/actions/enrollment.actionBatchs.ts
Outdated
Show resolved
Hide resolved
...re_modules/capture-core/components/DataEntries/Enrollment/actions/enrollment.actionBatchs.ts
Outdated
Show resolved
Hide resolved
.../components/Pages/EnrollmentAddEvent/ProgramStageSelector/ProgramStageSelector.container.tsx
Show resolved
Hide resolved
|
Thanks for the review @simonadomnisoru! 🎉 There actually is a slight performance improvement which can be noticed in the SL demo database (see updated PR description)! According to the redux action time stamps in the console, approximately 0.6 seconds get shaved off the delay between the button click to the UI update. I'm currently looking into what causes the remaining delay, and it seems to be because every field in the form gets re-rendered whenever a single value in the form is commited. If we just stop doing that, the editing might suddenly turn into a snappy and nice experience... I'm eager to find out! Currently working on a fix for it :-) |
simonadomnisoru
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
|
|
🚀 Deployed on https://deploy-preview-4396.capture.netlify.dhis2.org |



DHIS2-20281
This PR moves the program rule execution into a separate thread, hoping this will make the UI more responsive.
Currently the worker thread will process all rule executions to completion. If the app makes a new call to the rule engine before the last call is done, the result of the ongoing execution gets discarded as soon as it is ready.
This event is useful for testing performance:
#/enrollmentEventEdit?eventId=AUEQ24HuW4H&orgUnitId=DiszpKrYNg8