-
Notifications
You must be signed in to change notification settings - Fork 10
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
HL-642: Handler state check icons #2156
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #2156 +/- ##
============================================
- Coverage 27.75% 11.90% -15.85%
============================================
Files 759 163 -596
Lines 15484 4535 -10949
Branches 3454 1125 -2329
============================================
- Hits 4297 540 -3757
+ Misses 10618 3824 -6794
+ Partials 569 171 -398
... and 599 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Helsinkibenefit-bf-hdlr is deployed to: https://helsinkibenefit-bf-hdlr-2156.test.kuva.hel.ninja 🚀🚀🚀 |
Helsinkibenefit-bf-appl is deployed to: https://helsinkibenefit-bf-appl-2156.test.kuva.hel.ninja 🚀🚀🚀 |
Helsinkibenefit-bf-bknd is deployed to: https://helsinkibenefit-bf-bknd-2156.test.kuva.hel.ninja 🚀🚀🚀 |
TestCafe result is success for https://helsinkibenefit-bf-appl-2156.test.kuva.hel.ninja! 😆🎉🎉🎉 |
Not sure why context / provider pattern is needed here as data is handled on application item level only and not needed globally (my guess at least?). Other than that, looks good to me! Good work 👍 |
It's for the review state and related update function. Context provider reduces a lot of prop drilling here at least. |
{ | ||
onSuccess: () => { | ||
void queryClient.invalidateQueries('reviewState'); | ||
}, |
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.
isUpdatingReviewStateError
is used here on component level. I've previosly implemented all the error handling on hook level with onError
callback. If toasting is the only thing done when an error occurs, I'd maybe use onError as it's more of a network / data error thing than a GUI feature
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.
You can ditch the whole useEffect
actually, if you use onError
.
Description ✨
In handling view, the check icons can now be clicked.