Update PageHeader/Nav to not throw #1149
Conversation
✅ Deploy Preview for veda-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
This brings up a broader discussion of how do want to better handle errors on UI side? We should have a standard of logging errors and then when we throw, we should make sure the app doesn't break. Instead these throws should bubble up and be caught at some point and component returns null instead of breaking... more standard and better practice. |
There was a problem hiding this comment.
@sandrahoang686 Could you provide some steps for what to look for when testing the PR please?
|
@dzole0311 with the preview, you'd just wanna make sure it works as expected. To test fail case, you can pull down code locally and update the navConfig to have an unexpected type. This would be a good test case scenerio 🤔 |
## 🎉 Features - [E&A] Implement colormap configurability #1117 - [E&A] Feature flag colormap configurability #1147 - Add font md size as 20px for new Design System #1125 ## 🚀 Improvements - [E&A] Return default value of colormap along with other settings #1128 - Create new raster paint layer module and factor out BaseTimeseriesProps #1105 - Consolidate a place where to check linkProps #1121 #1160 - Expose Data Catalog and update child components to pass in routing/nav for library build #1096 #1159 - Set up eslint rule for no trailing spaces #1146 - Replace cmr-stac with titiler-cmr #1131 ## 🐛 Fixes - Update external link in top navigation target #1145 - Update PageHeader/Nav to not throw #1149 - [E&A] Fix to convert the time to usertzdate #1151 - Use sourceparams as it is when it is there #1148 - Fix compare label on block map #1153 - Discard the previous sourceExclusive value to fix the case when the datasets with different sourceExclusive can be selected together #1161 - Show the name of the selected filter on story hub #1161
Was playing around a bit with nav header with next instance and noticed something I did not catch in the initial PR review. But we dont want to throw an error when type is incorrect. This will break the app because nothing is catching it. Instead we should still render the rest of the nav items that are correct.
I opted in for logging the error for incorrect types but if we prefer a different way like catching and bubbling up the error, lmk.
Updated behavior looks like:
