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

(fix) O3-3350: Resolve infinite re-rendering of the dropdown component in the tablet viewport #326

Merged
merged 1 commit into from
Jun 19, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 1 addition & 5 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,7 @@
"access": "public"
},
"dependencies": {
"@carbon/react": ">1.47.0 <1.50.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samuelmale Is there a specific reason you made this a dependency and not a peerDependency?

I've read the linked issues/pr and the issue with the downshift dependency in carbon which has since been resolved. After pulling the latest changes and linking with the form-builder, i got some errors from carbon because of version conflicts.

  1. On one end adding this range resolved the issue with the downshift library but it also creates either a conflict or multiple versions of @carbon/react running within microfrontends that have dependencies out of that range for example esm-form-builder and other esms are currently running on @carbon/react@npm:1.37.0 which will in turn affect the bundle size. Would this necessitate us updating the frontends that pull the FE directly to at least 1.47.0 to have this fix working?
Screenshot 2024-06-21 at 11 02 10
  1. Doesn't having the same range of versions as a peer dependency yield the same result but with the benefit of not duplicating instances of @carbon/react?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, the overwhelming consensus on the dependency management strategy for Carbon in O3 is having it as a normal dependency as opposed to a singleton (peer).

"ace-builds": "^1.33.2",
"classnames": "^2.5.1",
"dayjs": "1.x",
Expand All @@ -41,7 +42,6 @@
"yup": "^1.4.0"
},
"peerDependencies": {
"@carbon/react": "1.x",
"@openmrs/esm-framework": "5.x",
"@openmrs/esm-patient-common-lib": "8.x",
"dayjs": "1.x",
Expand All @@ -52,7 +52,6 @@
"swr": "2.x"
},
"devDependencies": {
"@carbon/react": "^1.37.0",
"@openmrs/esm-framework": "next",
"@openmrs/esm-patient-common-lib": "next",
"@swc/cli": "^0.1.65",
Expand Down Expand Up @@ -107,8 +106,5 @@
"*.{ts,tsx}": "eslint --cache --fix --max-warnings 0",
"*.{css,scss,ts,tsx}": "prettier --write --list-different"
},
"resolutions": {
"@carbon/react": "1.37.0"
},
"packageManager": "yarn@4.2.2"
}
2 changes: 1 addition & 1 deletion src/components/inputs/select/dropdown.component.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ const Dropdown: React.FC<FormFieldProps> = ({ question, onChange, handler, previ
.filter((answer) => !answer.isHidden)
.map((item) => item.value || item.concept)}
itemToString={itemToString}
selectedItem={field.value}
selectedItem={field.value || null}
onChange={({ selectedItem }) => handleChange(selectedItem)}
disabled={question.isDisabled}
readOnly={question.readonly}
Expand Down
Loading