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

🛠 Tailwinding Care #3742

Closed
41 tasks done
rithviknishad opened this issue Oct 10, 2022 · 2 comments · Fixed by #5839
Closed
41 tasks done

🛠 Tailwinding Care #3742

rithviknishad opened this issue Oct 10, 2022 · 2 comments · Fixed by #5839

Comments

@rithviknishad
Copy link
Member

rithviknishad commented Oct 10, 2022

do not assign this issue

This issue is an EPIC to track the progress of making custom tailwind components for care, sub-issues will be created).
Link this issue on pull requests that implement or modify a tailwind component without a closing keyword.

Notes

  • Follow the Figma design provided when implementing the components.

  • Add redesign label to related issues / PR.

  • When implementing or redesigning an entire form that replaces components with the custom tailwind components, name the branch in the format: tailwind/{branch-name}, for example: tailwind/asset-registration or tailwind/patient-filters or tailwind/patient-consultation.

  • Form field components shall be wrapped by FormField so that the design stays consistent across the app and achieves a uniform component API interface.

Components to be built

We can use tailwind/headlessui for building some of the components

Other related tasks

Migrations

cc: @gigincg

@rithviknishad rithviknishad changed the title Tailwinding Care 🛠 Tailwinding Care Oct 10, 2022
@khavinshankar
Copy link
Member

@rithviknishad do you need any help with this?

@rithviknishad
Copy link
Member Author

@khavinshankar definitely!! Could you help tailwind the async autocomplete field in the #3744 patient filters?

Generally, apart from that, I was thinking of having all the input components have their own validators and also be compliant with form reducers across care since we mostly have only set_form and set_error only.

so that, the component's API interface would just take in the additional props (validator, reducerProps) see this.

however, the components API should still be usable when not used with reducers.
So I was just taking time to document it clearly so that it's easily maintainable by everyone and changing the component API interface later would be a hassle.

For example, the text input is composed like this:
https://github.com/coronasafe/care_fe/pull/3744/files#diff-e0e39dd41cb8f0b76d60275fa706cd765c8648107e45183f24781aa0cd51145f
and when used with reducers, the amount of code we write would be so less, but still, it'll render out the errors and field labels without having to write separate components each time.

This was referenced Feb 27, 2023
This was referenced Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants