(chore) export openmrsComponentDecorator #1193
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chibongho
requested review from
mseaton,
brandones,
mogoodrich,
denniskigen and
ibacher
mogoodrich
approved these changes
Oct 31, 2024
|
Size Change: -39.2 kB (-0.64%) Total Size: 6.12 MB
ℹ️ View Unchanged
|
|
Can you say more about the motivation here? I'm not terribly keen on having the component decorator become part of the public API, as it limits our ability to make changes to what is mostly an internal implementation detail. |
|
Yeah, this can be a somewhat dangerous change. In this (PR), different sub-components of the patient banner is moved to in style guide. I think the idea is that we can mix and match these components into different looking patient cards in the search results workspace if desired, and eliminate the need of Not implemented in that PR, but I think the next step would be to have the patient search workspace accept a custom For this to work, any sub-components included in (This approach also avoids the pattern of rendering N extensions for N patient cards in a loop, something we had difficulty with in the ward app.) Besides search results, I also have another use case of needing to show a patient header at the top of the clinical form workspace. In the patient chart, there is no ambiguity on which patient we opened the workspace for. But in the ward app (where we can click on any ward patient to open their workspace), we need to display a patient header. (The ward app also has its own app-specific patient header different from the regular one) |
|
@ibacher and others, interested in your thoughts / concerns about this, especially on:
|
|
If we're just exporting components from the styleguide, there's no reason to make this a public export. We can just use the component decorator directly in the styleguide (things inside the framework are allowed to import from the framework internals / non-public APIs; other code can, but we don't support it long-term). That is, I think, my preferred solution here. |
|
I think we also want to use components defined outside of styleguide though, and they require the decorator or something similar to wrap the elements. In the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
feat,fix, orchore, among others). See existing PR titles for inspiration.For changes to apps
If applicable
Summary
Screenshots
Related Issue
Other