Skip to content
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

Merged
merged 1 commit into from
Jul 23, 2024

Conversation

tomzemp
Copy link
Member

@tomzemp tomzemp commented Jul 22, 2024

See https://dhis2.atlassian.net/jira/software/c/projects/LIBS/issues/LIBS-644

I've updated to

  • use useDataQuery rather than <DataQuery>
  • added i18n.t wrapping on the error and loading text (I changed ... to Loading..., 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.
  • I've done a conditional return with error/loading that does not include the <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.
  • added some optional chaining to 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)

@tomzemp tomzemp requested review from KaiVandivier and a team July 22, 2024 14:16
Copy link
Contributor

@Topener Topener left a 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

@KaiVandivier
Copy link
Contributor

KaiVandivier commented Jul 23, 2024

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,

  1. If !error && !loading, then data should be defined
  2. If data is defined, so should data.me because of how the query object is constructed
    So I'd advocate for using data.me.name here

Copy link
Contributor

@KaiVandivier KaiVandivier left a 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

@tomzemp tomzemp force-pushed the LIBS-644/update-initial-app-code branch from afc17d0 to 9fff97c Compare July 23, 2024 13:23
@tomzemp tomzemp changed the title chore: update initial app code [LIBS-644] feat: update initial app code [LIBS-644] Jul 23, 2024
@tomzemp
Copy link
Member Author

tomzemp commented Jul 23, 2024

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 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 😜

@tomzemp tomzemp requested a review from KaiVandivier July 23, 2024 13:31
@KaiVandivier
Copy link
Contributor

KaiVandivier commented Jul 23, 2024

Yeah I see your point -- maybe it's best evaluated on a case-by-case basis

And yeah, catching a breaking change in useDataQuery as soon as possible would be helpful 😅

@KaiVandivier KaiVandivier merged commit bd6cfc0 into master Jul 23, 2024
8 checks passed
@KaiVandivier KaiVandivier deleted the LIBS-644/update-initial-app-code branch July 23, 2024 17:31
@KaiVandivier
Copy link
Contributor

Merged this so I can pull it into alpha 😊 (I need to make it create a .jsx file there)

dhis2-bot added a commit that referenced this pull request Jul 23, 2024
# [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))
@dhis2-bot
Copy link
Contributor

🎉 This PR is included in version 11.7.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

dhis2-bot added a commit that referenced this pull request Jul 23, 2024
# [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))
@dhis2-bot
Copy link
Contributor

🎉 This PR is included in version 12.0.0-alpha.4 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants