refactor: [DHIS2-20281] run rule engine asynchronously#4396
refactor: [DHIS2-20281] run rule engine asynchronously#4396
Conversation
Replaces confusing logic which did not quite work.
simonadomnisoru
left a comment
simonadomnisoru
left a comment
There was a problem hiding this comment.
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 :-) |
|
|
🚀 Deployed on https://deploy-preview-4396.capture.netlify.dhis2.org |
2 participants
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