-
Notifications
You must be signed in to change notification settings - Fork 210
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
(chore) export openmrsComponentDecorator #1193
base: main
Are you sure you want to change the base?
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.
Defer to others, but looks straightforward to expose this!
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 |
Sorry... I think I dropped the ball on this. Anyways, if we do need to export the openmrsComponentDecorator, then we need to add doc strings to it explaining how it is meant to be used. Nothing should exist in the public API with documentation like that. |
Sure. I originally meant to use the function as a proof of concept. If there is no objection to the proposed use cases (to pass configurable / translatable components across different ESMs), I can improve on it. TBH, while the
|
While that's true, I like the idea of exposing the The other issue is that let component: ReactElement<T>;
if (isValidElement<T>(Comp)) {
Comp.props = { ...this.props };
component = Comp;
} else {
component = createElement<T>(Comp, { ...this.props });
} and I'm trying to find a different way; with direct children, that becomes even messier). |
Yeah... I was looking into it just now and realized the higher order component is harder to refactor that I thought. I'll let it be for now. |
Requirements
feat
,fix
, orchore
, among others). See existing PR titles for inspiration.For changes to apps
If applicable
Summary
Screenshots
Related Issue
Other