-
Notifications
You must be signed in to change notification settings - Fork 16
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
feat: update initial app code [LIBS-644] #866
Conversation
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.
LGTM! So much cleaner this way
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,
|
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.
Requesting changes because this should be a feat
since it changes the behavior of d2-app-scripts init
afc17d0
to
9fff97c
Compare
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
useDataQuery
rather than<DataQuery>
i18n.t
wrapping 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)