feat: update initial app code [LIBS-644] #866
Conversation
|
Nice! Thanks for doing this 🙌 I have reservations about the optional chaining -- I'd argue this isn't the best practice, because it can end up causing quiet failures that can be overlooked and become hard to diagnose, especially if a value is passed to other functions or components, where it becomes harder to identify where the problem stems from I think a better practice is to handle the loading and error states, because problems after that would probably be code errors, where it's helpful to "fail early" and see error messages, where it's easier to catch in development In this particular case,
|
tomzemp
force-pushed
the
LIBS-644/update-initial-app-code
branch
from
afc17d0 to
9fff97c
Compare
tomzemp
changed the title
I clearly like quiet failures more 😄, but it's a bit of a nuanced conversation and depends on whether the app is likely to be fixed or not if it crashes. In this case, I agree, that the code should not need the optional chaining ... unless something goes wrong / changes with useDataQuery. If it were a real app, and the only purpose was to display a name to the user, I'd argue this was a fine case to have the quiet failure, so user could otherwise use the app. Obviously, though, if useDataQuery starts behaving incorrectly, it would be nice if we noticed that in the code we initialize our apps with 😜 |
|
Yeah I see your point -- maybe it's best evaluated on a case-by-case basis And yeah, catching a breaking change in |
|
Merged this so I can pull it into alpha 😊 (I need to make it create a |
# [11.7.0](v11.6.4...v11.7.0) (2024-07-23) ### Features * update boilerplate app code for init command [LIBS-644] ([#866](#866)) ([bd6cfc0](bd6cfc0))
|
🎉 This PR is included in version 11.7.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
# [12.0.0-alpha.4](v12.0.0-alpha.3...v12.0.0-alpha.4) (2024-07-23) ### Bug Fixes * use i18next-scanner v3 for better i18next compatibility ([#864](#864)) ([84a5a59](84a5a59)) * **deps:** update i18next-scanner version to support old plurals format again ([#861](#861)) ([d0e433b](d0e433b)) * plugin boundary retry if plugin logic is skipped ([#862](#862)) ([01a3160](01a3160)) ### Features * update boilerplate app code for init command [LIBS-644] ([#866](#866)) ([bd6cfc0](bd6cfc0))
|
🎉 This PR is included in version 12.0.0-alpha.4 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
See https://dhis2.atlassian.net/jira/software/c/projects/LIBS/issues/LIBS-644
I've updated to
useDataQueryrather than<DataQuery>i18n.twrapping on the error and loading text (I changed...toLoading..., so it doesn't look like we're just translating ellipses. I suppose that might be a valid translation as I don't know if other languages use ellipses in the same way, but it seems a bit confusing). I have changed this just to display best practice of translating strings.<div className={classes.container}>element. I've just done this for readability / mimic what we generally do in our apps. I thought repeating the div would be distracting as would refactoring to make it a common wrapper.data?.me?.name. Again, I've done this mostly as I think it's useful practice to model this as it helps prevent unnecessary crashes when something gets returned incorrectly.(After this is merged, https://github.com/dhis2/cli dependencies need to be updated)