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

BREAKING: Rework card config system (supports O3-3242) #1263

Merged
merged 2 commits into from
Aug 5, 2024

Conversation

brandones
Copy link
Contributor

@brandones brandones commented Jul 31, 2024

Requirements

  • This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
  • My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
  • My work includes tests or is validated by existing tests.

Summary

Simplifies the config schema. No more polymorphic config objects. Makes each card row other than the header and footer into an extension. Right now there's just the "coloredObsTags" extension, which is used for displaying risk factors.

This means that card rows should be configured using the extension configuration system. This is the one thing that is a little less intuitive than it was before, since the row config lives somewhere separate from the card config. However, what we get from the trade-off is that new types of rows can be introduced by third-party modules without needing to modify esm-ward-app.

The new KGH config should be

{
  "@openmrs/esm-ward-app": {
    "wardPatientCards": {
      "obsElementDefinitions": [
        {
          "conceptUuid": "3cee82de-26fe-102b-80cb-0017a47871b2",
          "id": "gravida"
        },
        {
          "id": "admission-reason",
          "conceptUuid": "86a2cf11-1ea5-4b8a-9e4b-08f4cdbe1346",
          "onlyWithinCurrentVisit": true,
          "orderBy": "ascending",
          "label": "REASON"
        }
      ],
      "addressElementDefinitions": [
        {
          "id": "patient-address",
          "fields": [
            "countyDistrict"
          ]
        }
      ],
      "cardDefinitions": [
        {
          "id": "default",
          "headerRowElements": [
            "patient-age",
            "patient-address",
            "patient-identifier",
            "admission-reason"
          ],
          "footerRowElements": [
            "gravida"
          ],
          "patientAddressElementFields": [
            "countyDistrict"
          ],
          "appliedTo": []
        }
      ]
    }
  },
  "colored-obs-tags-card-row": {
    "conceptUuid": "447f14be-4f34-4cba-9f80-8e091e23c6e3",
    "summaryLabel": "Pregancy Complication(s)",
    "tags": [
      {
        "color": "red",
        "appliedToConceptSets": [
          "447f14be-4f34-4cba-9f80-8e091e23c6e3"
        ]
      }
    ]
  }
}

No UI change.

Screenshots

image

Related Issue

https://issues.openmrs.org/browse/O3-3242

Other

I'm not 100% sure the admission-reason config is working & correct because none of the admitted patients seem to have the relevant obs.

It wouldn't be unreasonable, I think, to rename colored-obs-tags-card-row to colored-obs-tags, since there's actually nothing very specific to the card row situation about it. It could just as easily be dropped in to lots of places. The card itself is providing the row styling.

NOTE: I've left all the file names intact in order to facilitate reviewing. Once this approach is something we're happy moving forward with, I'll rename files and folders into a structure more appropriate for the new setup.

Copy link
Contributor

github-actions bot commented Jul 31, 2024

Size Change: -7.12 kB (-0.12%)

Total Size: 5.89 MB

ℹ️ View Unchanged
Filename Size Change
packages/esm-active-visits-app/dist/106.js 8.63 kB 0 B
packages/esm-active-visits-app/dist/130.js 315 kB 0 B
packages/esm-active-visits-app/dist/255.js 2.5 kB 0 B
packages/esm-active-visits-app/dist/271.js 813 B 0 B
packages/esm-active-visits-app/dist/316.js 42.9 kB 0 B
packages/esm-active-visits-app/dist/319.js 709 B 0 B
packages/esm-active-visits-app/dist/382.js 1.22 kB 0 B
packages/esm-active-visits-app/dist/443.js 6.98 kB 0 B
packages/esm-active-visits-app/dist/460.js 824 B 0 B
packages/esm-active-visits-app/dist/574.js 615 B 0 B
packages/esm-active-visits-app/dist/6.js 26.9 kB 0 B
packages/esm-active-visits-app/dist/635.js 1.22 kB 0 B
packages/esm-active-visits-app/dist/644.js 812 B 0 B
packages/esm-active-visits-app/dist/725.js 632 B 0 B
packages/esm-active-visits-app/dist/729.js 3.08 kB 0 B
packages/esm-active-visits-app/dist/757.js 719 B 0 B
packages/esm-active-visits-app/dist/784.js 2.63 kB 0 B
packages/esm-active-visits-app/dist/788.js 628 B 0 B
packages/esm-active-visits-app/dist/807.js 959 B 0 B
packages/esm-active-visits-app/dist/833.js 765 B 0 B
packages/esm-active-visits-app/dist/879.js 3.02 kB 0 B
packages/esm-active-visits-app/dist/966.js 51.3 kB 0 B
packages/esm-active-visits-app/dist/967.js 600 B 0 B
packages/esm-active-visits-app/dist/main.js 82.6 kB 0 B
packages/esm-active-visits-app/dist/openmrs-esm-active-visits-app.js 3.33 kB 0 B
packages/esm-appointments-app/dist/130.js 315 kB 0 B
packages/esm-appointments-app/dist/152.js 259 B 0 B
packages/esm-appointments-app/dist/23.js 14.4 kB 0 B
packages/esm-appointments-app/dist/255.js 2.51 kB 0 B
packages/esm-appointments-app/dist/265.js 1.79 kB 0 B
packages/esm-appointments-app/dist/271.js 2.31 kB 0 B
packages/esm-appointments-app/dist/303.js 259 B 0 B
packages/esm-appointments-app/dist/319.js 2.15 kB 0 B
packages/esm-appointments-app/dist/460.js 2.37 kB 0 B
packages/esm-appointments-app/dist/501.js 7.02 kB 0 B
packages/esm-appointments-app/dist/574.js 1.94 kB 0 B
packages/esm-appointments-app/dist/581.js 9.03 kB 0 B
packages/esm-appointments-app/dist/591.js 16.8 kB 0 B
packages/esm-appointments-app/dist/644.js 2.31 kB 0 B
packages/esm-appointments-app/dist/646.js 250 kB 0 B
packages/esm-appointments-app/dist/729.js 3.08 kB 0 B
packages/esm-appointments-app/dist/757.js 2.19 kB 0 B
packages/esm-appointments-app/dist/784.js 2.62 kB 0 B
packages/esm-appointments-app/dist/788.js 1.94 kB 0 B
packages/esm-appointments-app/dist/807.js 2.56 kB 0 B
packages/esm-appointments-app/dist/833.js 2.29 kB 0 B
packages/esm-appointments-app/dist/85.js 30.5 kB 0 B
packages/esm-appointments-app/dist/89.js 143 kB 0 B
packages/esm-appointments-app/dist/903.js 879 B 0 B
packages/esm-appointments-app/dist/main.js 410 kB 0 B
packages/esm-appointments-app/dist/openmrs-esm-appointments-app.js 3.39 kB 0 B
packages/esm-bed-management-app/dist/130.js 315 kB 0 B
packages/esm-bed-management-app/dist/148.js 1.22 kB 0 B
packages/esm-bed-management-app/dist/169.js 6.98 kB 0 B
packages/esm-bed-management-app/dist/271.js 680 B 0 B
packages/esm-bed-management-app/dist/319.js 680 B 0 B
packages/esm-bed-management-app/dist/460.js 680 B 0 B
packages/esm-bed-management-app/dist/501.js 7.03 kB 0 B
packages/esm-bed-management-app/dist/542.js 395 B 0 B
packages/esm-bed-management-app/dist/574.js 681 B 0 B
packages/esm-bed-management-app/dist/591.js 16.8 kB 0 B
packages/esm-bed-management-app/dist/644.js 680 B 0 B
packages/esm-bed-management-app/dist/668.js 26.5 kB 0 B
packages/esm-bed-management-app/dist/729.js 3.08 kB 0 B
packages/esm-bed-management-app/dist/757.js 726 B 0 B
packages/esm-bed-management-app/dist/766.js 113 kB 0 B
packages/esm-bed-management-app/dist/784.js 2.63 kB 0 B
packages/esm-bed-management-app/dist/788.js 680 B 0 B
packages/esm-bed-management-app/dist/805.js 49.6 kB 0 B
packages/esm-bed-management-app/dist/807.js 680 B 0 B
packages/esm-bed-management-app/dist/833.js 680 B 0 B
packages/esm-bed-management-app/dist/main.js 3.87 kB 0 B
packages/esm-bed-management-app/dist/openmrs-esm-bed-management-app.js 3.25 kB 0 B
packages/esm-patient-list-management-app/dist/112.js 73.3 kB 0 B
packages/esm-patient-list-management-app/dist/130.js 315 kB 0 B
packages/esm-patient-list-management-app/dist/255.js 2.51 kB 0 B
packages/esm-patient-list-management-app/dist/271.js 99.8 kB 0 B
packages/esm-patient-list-management-app/dist/319.js 1.51 kB 0 B
packages/esm-patient-list-management-app/dist/37.js 9.49 kB 0 B
packages/esm-patient-list-management-app/dist/382.js 1.23 kB 0 B
packages/esm-patient-list-management-app/dist/384.js 1.58 kB 0 B
packages/esm-patient-list-management-app/dist/443.js 6.98 kB 0 B
packages/esm-patient-list-management-app/dist/460.js 1.72 kB 0 B
packages/esm-patient-list-management-app/dist/574.js 1.34 kB 0 B
packages/esm-patient-list-management-app/dist/591.js 16.9 kB 0 B
packages/esm-patient-list-management-app/dist/635.js 1.23 kB 0 B
packages/esm-patient-list-management-app/dist/644.js 1.58 kB 0 B
packages/esm-patient-list-management-app/dist/729.js 3.08 kB 0 B
packages/esm-patient-list-management-app/dist/757.js 1.51 kB 0 B
packages/esm-patient-list-management-app/dist/784.js 2.63 kB 0 B
packages/esm-patient-list-management-app/dist/788.js 1.34 kB 0 B
packages/esm-patient-list-management-app/dist/807.js 1.85 kB 0 B
packages/esm-patient-list-management-app/dist/833.js 1.59 kB 0 B
packages/esm-patient-list-management-app/dist/main.js 177 kB 0 B
packages/esm-patient-list-management-app/dist/openmrs-esm-patient-list-management-app.js 3.31 kB 0 B
packages/esm-patient-registration-app/dist/130.js 314 kB 0 B
packages/esm-patient-registration-app/dist/152.js 264 B 0 B
packages/esm-patient-registration-app/dist/169.js 6.71 kB 0 B
packages/esm-patient-registration-app/dist/255.js 2.5 kB 0 B
packages/esm-patient-registration-app/dist/271.js 2.13 kB 0 B
packages/esm-patient-registration-app/dist/290.js 61.6 kB 0 B
packages/esm-patient-registration-app/dist/303.js 264 B 0 B
packages/esm-patient-registration-app/dist/319.js 2.05 kB 0 B
packages/esm-patient-registration-app/dist/371.js 547 B 0 B
packages/esm-patient-registration-app/dist/460.js 2.22 kB 0 B
packages/esm-patient-registration-app/dist/501.js 7.03 kB 0 B
packages/esm-patient-registration-app/dist/540.js 85 kB 0 B
packages/esm-patient-registration-app/dist/574.js 1.78 kB 0 B
packages/esm-patient-registration-app/dist/591.js 16.8 kB 0 B
packages/esm-patient-registration-app/dist/623.js 7.74 kB 0 B
packages/esm-patient-registration-app/dist/644.js 2.13 kB 0 B
packages/esm-patient-registration-app/dist/729.js 3.08 kB 0 B
packages/esm-patient-registration-app/dist/735.js 465 B 0 B
packages/esm-patient-registration-app/dist/757.js 2.15 kB 0 B
packages/esm-patient-registration-app/dist/784.js 2.63 kB 0 B
packages/esm-patient-registration-app/dist/788.js 1.78 kB 0 B
packages/esm-patient-registration-app/dist/807.js 2.51 kB 0 B
packages/esm-patient-registration-app/dist/833.js 2.06 kB 0 B
packages/esm-patient-registration-app/dist/879.js 3.03 kB 0 B
packages/esm-patient-registration-app/dist/main.js 149 kB 0 B
packages/esm-patient-registration-app/dist/openmrs-esm-patient-registration-app.js 3.35 kB 0 B
packages/esm-patient-search-app/dist/130.js 315 kB 0 B
packages/esm-patient-search-app/dist/255.js 2.5 kB 0 B
packages/esm-patient-search-app/dist/271.js 920 B 0 B
packages/esm-patient-search-app/dist/319.js 861 B 0 B
packages/esm-patient-search-app/dist/382.js 1.23 kB 0 B
packages/esm-patient-search-app/dist/420.js 22.4 kB 0 B
packages/esm-patient-search-app/dist/443.js 6.98 kB 0 B
packages/esm-patient-search-app/dist/460.js 939 B 0 B
packages/esm-patient-search-app/dist/574.js 742 B 0 B
packages/esm-patient-search-app/dist/591.js 16.8 kB 0 B
packages/esm-patient-search-app/dist/634.js 75.2 kB 0 B
packages/esm-patient-search-app/dist/635.js 1.23 kB 0 B
packages/esm-patient-search-app/dist/644.js 920 B 0 B
packages/esm-patient-search-app/dist/729.js 3.08 kB 0 B
packages/esm-patient-search-app/dist/757.js 871 B 0 B
packages/esm-patient-search-app/dist/784.js 2.63 kB 0 B
packages/esm-patient-search-app/dist/788.js 736 B 0 B
packages/esm-patient-search-app/dist/807.js 1.04 kB 0 B
packages/esm-patient-search-app/dist/833.js 877 B 0 B
packages/esm-patient-search-app/dist/main.js 101 kB 0 B
packages/esm-patient-search-app/dist/openmrs-esm-patient-search-app.js 3.3 kB 0 B
packages/esm-service-queues-app/dist/130.js 315 kB 0 B
packages/esm-service-queues-app/dist/152.js 261 B 0 B
packages/esm-service-queues-app/dist/169.js 6.98 kB 0 B
packages/esm-service-queues-app/dist/186.js 8.99 kB 0 B
packages/esm-service-queues-app/dist/199.js 1.35 kB 0 B
packages/esm-service-queues-app/dist/236.js 5.86 kB 0 B
packages/esm-service-queues-app/dist/255.js 2.51 kB 0 B
packages/esm-service-queues-app/dist/265.js 118 kB 0 B
packages/esm-service-queues-app/dist/271.js 4.52 kB 0 B
packages/esm-service-queues-app/dist/303.js 261 B 0 B
packages/esm-service-queues-app/dist/319.js 3.82 kB 0 B
packages/esm-service-queues-app/dist/366.js 7.87 kB 0 B
packages/esm-service-queues-app/dist/392.js 7.86 kB 0 B
packages/esm-service-queues-app/dist/460.js 4.74 kB 0 B
packages/esm-service-queues-app/dist/484.js 158 kB 0 B
packages/esm-service-queues-app/dist/501.js 7.03 kB 0 B
packages/esm-service-queues-app/dist/574.js 3.85 kB 0 B
packages/esm-service-queues-app/dist/591.js 16.8 kB 0 B
packages/esm-service-queues-app/dist/6.js 1.75 kB 0 B
packages/esm-service-queues-app/dist/604.js 6.98 kB 0 B
packages/esm-service-queues-app/dist/644.js 4.53 kB 0 B
packages/esm-service-queues-app/dist/670.js 10 kB 0 B
packages/esm-service-queues-app/dist/727.js 8.12 kB 0 B
packages/esm-service-queues-app/dist/729.js 3.08 kB 0 B
packages/esm-service-queues-app/dist/752.js 1.62 kB 0 B
packages/esm-service-queues-app/dist/757.js 3.89 kB 0 B
packages/esm-service-queues-app/dist/760.js 7.14 kB 0 B
packages/esm-service-queues-app/dist/784.js 2.63 kB 0 B
packages/esm-service-queues-app/dist/788.js 3.82 kB 0 B
packages/esm-service-queues-app/dist/800.js 1.68 kB 0 B
packages/esm-service-queues-app/dist/807.js 5.1 kB 0 B
packages/esm-service-queues-app/dist/818.js 2.55 kB 0 B
packages/esm-service-queues-app/dist/828.js 1.39 kB 0 B
packages/esm-service-queues-app/dist/833.js 4.43 kB 0 B
packages/esm-service-queues-app/dist/911.js 7.78 kB 0 B
packages/esm-service-queues-app/dist/940.js 21.4 kB 0 B
packages/esm-service-queues-app/dist/main.js 279 kB 0 B
packages/esm-service-queues-app/dist/openmrs-esm-service-queues-app.js 3.31 kB 0 B
packages/esm-ward-app/dist/130.js 315 kB 0 B
packages/esm-ward-app/dist/152.js 255 B 0 B
packages/esm-ward-app/dist/169.js 6.97 kB 0 B
packages/esm-ward-app/dist/198.js 0 B -7.89 kB (removed) 🏆
packages/esm-ward-app/dist/255.js 2.5 kB 0 B
packages/esm-ward-app/dist/268.js 7.85 kB 0 B
packages/esm-ward-app/dist/303.js 255 B 0 B
packages/esm-ward-app/dist/384.js 27.5 kB 0 B
packages/esm-ward-app/dist/474.js 11.9 kB -64 B (-0.53%)
packages/esm-ward-app/dist/501.js 7.02 kB 0 B
packages/esm-ward-app/dist/526.js 13 kB 0 B
packages/esm-ward-app/dist/574.js 1.06 kB +51 B (+5.07%) 🔍
packages/esm-ward-app/dist/591.js 16.8 kB 0 B
packages/esm-ward-app/dist/729.js 3.07 kB 0 B
packages/esm-ward-app/dist/761.js 648 B 0 B
packages/esm-ward-app/dist/767.js 25.1 kB +465 B (+1.89%)
packages/esm-ward-app/dist/784.js 2.62 kB 0 B
packages/esm-ward-app/dist/940.js 21.4 kB 0 B
packages/esm-ward-app/dist/960.js 342 B 0 B
packages/esm-ward-app/dist/999.js 4.99 kB 0 B
packages/esm-ward-app/dist/main.js 55.7 kB +317 B (+0.57%)
packages/esm-ward-app/dist/openmrs-esm-ward-app.js 3.3 kB 0 B

compressed-size-action

@chibongho chibongho requested review from mseaton and ibacher August 1, 2024 18:44
Copy link
Contributor

@chibongho chibongho left a comment

Choose a reason for hiding this comment

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

This simplifies the config a bit. Some things here don't feel right, but I think they are fixable.

Previously, I envisioned the config system to allow for arbitrary number of rows, each row can have any of the predefined elements, or even extension elements (not yet implemented). A custom "row" can technically be implemented as a row with an extension element. If I understand correctly, the changes in this PR are:

  • we treat each element type defined here as first-class objects. They are unique enough to define even their own props; the logic of what to passed in is taken care of by the unique cases in the big switch statement. (I'd prefer that all take in a common set of props, but I don't feel too strongly about it)
  • The header and footer rows get first class support. All other rows sandwiched in between are to be added as extensions.
  • The WardPatientCodedObsTags is so specific and unique that it's elevated from being an element to being an extension row, with its own extension config. (This feels strange, but again I don't feel too strongly about it)

Some questions I have:

  • How would someone add an extension element to the header and footer? (somewhat likely) We need to consider what props we should pass into it, and how we define the extension slot name.
  • How would someone add predefined elements into the sandwiched extension rows? (perhaps less likely) Would it only be possible if we also make the predefined elements available as extensions?

packages/esm-ward-app/src/hooks/useMostRecentObs.ts Outdated Show resolved Hide resolved
packages/esm-ward-app/src/hooks/useMostRecentObs.ts Outdated Show resolved Hide resolved
@@ -207,23 +149,33 @@ export interface WardConfigObject {
}

export interface WardPatientCardsConfig {
patientCardElementDefinitions: Array<PatientCardElementDefinition>;
obsElementDefinitions: Array<ObsElementDefinition>;
identifierElementDefinitions: Array<IdentifierElementDefinition>;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think patientAddressElementFields should belong here instead of the WardPatientCardDefinition interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good. That does mean that the same address elements will necessarily be used for every ward, but that's probably fine.

Copy link
Contributor

Choose a reason for hiding this comment

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

Wait... why? Each value in obsElementDefinitions and identifierElementDefinitions can specify which element id to apply the config to. Can't we just do the same thing with patientAddressElementFields?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh I see, is what you're suggesting that instead of having 'patient-address' be a built-in element that is configurable, that instead we should provide a system for defining elements of type 'patient-address' which can then be included, but where the only real difference between the different patient-address elements is which fields are shown?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah. That follows the same pattern as the identiferElement and obsElement, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, it does.

if (obsConfig) {
return <WardPatientObs patient={patient} visit={visit} config={obsConfig} />;
} else if (idConfig) {
return <WardPatientIdentifier patient={patient} config={idConfig} />;
Copy link
Contributor

Choose a reason for hiding this comment

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

It feels off to have WardPatientIdentifier appear twice in this switch statement, one for having it take the default config and one for having it take a custom config.

I think the id field of obsElementDefinition / identifierElementDefinition is supposed to specify which element it configures. Can we have the id be nullable, in which case it applies the config to the default element (patient-identifier / patient-obs)? I think this should simplify the logic here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, the config system doesn't support types being nullable. null can be provided as a default value, but an element with type Type.String cannot have null provided as the value by configuration.

I'm not sure what feels off about this, but it seems like a more intuitive API to provide than one in which there is a magic value of id that modifies the default identifier element.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh I think I figured out a slightly better way about it

Copy link
Member

@ibacher ibacher left a comment

Choose a reason for hiding this comment

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

I don't feel I'm well-placed to evaluate this commit. However, broadly speaking, I'm in favour of anything that keeps the configuration relatively simple as a design goal of O3 is to have it configurable by implementers with minimal programming knowledge.

return WardPatientBedNumber;
case 'patient-name':
return WardPatientName;
export const WardPatientCardElement: React.FC<{ elementId: string; patient: Patient; visit: Visit }> = ({
Copy link
Member

Choose a reason for hiding this comment

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

Minor, but something which renders a React element, as opposed to data-fetching, feels like it should be in a .component.tsx file rather than a .resource.tsx file (even though this MFE doesn't do a great job of following the Coding Conventions).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah certainly, lots of files will get renamed after the dust settles a little, before I merge this PR.

@mogoodrich
Copy link
Member

mogoodrich commented Aug 1, 2024

I'll generally defer to @chibongho has he is more up-to-speed on the original design of this, but I'll keep an eye on the PR and weigh in on things I see.

A few thoughts:

  • I do agree that being able to insert rows via extension is a good idea (was this not possible before?)
  • But I do thing we need to able to apply custom elements to the header/footer (and that this may be a common use case, as @chibongho notes); though, fwiw, I suppose it would be enough to support replacing the entire header row with a custom row (which, practically, would just be a matter of having a property to suppress the default header or footer)?

@brandones
Copy link
Contributor Author

Thanks so much for your thoughtful reviews, @chibongho , @mogoodrich , and @ibacher .

The WardPatientCodedObsTags is so specific and unique that it's elevated from being an element to being an extension row, with its own extension config. (This feels strange, but again I don't feel too strongly about it)

Yeah, the idea is that each row is an extension—so the baby row, when it's time to add that, will also be an extension.

How would someone add an extension element to the header and footer? (somewhat likely) We need to consider what props we should pass into it, and how we define the extension slot name.

Good thought! I've added extension slots for those.

How would someone add predefined elements into the sandwiched extension rows? (perhaps less likely) Would it only be possible if we also make the predefined elements available as extensions?

Right now the only rows that are in any designs I've seen are quite different than the contents of the header and footer. The expectation encoded in this approach is that rows will be coded from scratch. I think this is the most appropriate way about it, because all of the existing row designs are highly idiosyncratic, and each row is pretty small and self-contained, easy to build from scratch. If someone really needs a row that displays the value of an obs in plain text, and for some reason they don't want to just put it in the header, they'll have to write a fetcher for that obs, and that's probably okay. It won't pollute any other code anyway.

@brandones
Copy link
Contributor Author

Ok, I've updated the address and identifier configurations. I'll fix the merge conflicts shortly.

@brandones brandones force-pushed the O3-3242-card-config branch from b73b046 to e538700 Compare August 5, 2024 18:01
@brandones brandones force-pushed the O3-3242-card-config branch from 045c335 to 95ab9e0 Compare August 5, 2024 18:21
@brandones brandones requested a review from chibongho August 5, 2024 18:23
Copy link
Contributor

@chibongho chibongho left a comment

Choose a reason for hiding this comment

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

Looks ok. Pretty scary change TBH. Hoping that nothing breaks (or that they are easy fixes).

encounterAssigningToCurrentInpatientLocation={encounterAssigningToCurrentInpatientLocation}
/>
))}
<ExtensionSlot name={headerExtensionSlotName} state={extensionSlotState} />
Copy link
Contributor

Choose a reason for hiding this comment

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

I was hoping there is an ExtensionElement that can be placed with other elements in arbitrary instead of at the end, but we can do that in a different PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't understand, could you elaborate on this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, typo. should be "in arbitrary order". So we can have, for example, bed-number, patient-name, extension-element, patient-identifier (instead of having the extension-element at the end)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If that becomes a real need, the thing to do would probably be to turn the elements that come after the patient name into extensions and have an extension slot come after name. I would suggest not treating bed number and patient name as arbitrary "bento box" elements, but rather as things that are managed by the card itself. So in the main card you'd have

bed number | patient name | header extension slot

And then in the admission request card you'd have

patient name | header extension slot

And then all of those elements, obs display etc, would be configurable directly using extension config (so the card wouldn't have anything to do with their configuration), and you'd just use the config system to add/remove/rearrange them.

But that would come with some performance cost (which would be significantly lightened by O3-1418). So I'd recommend not doing that until it's clear that there is a use case.

@brandones
Copy link
Contributor Author

I've updated the config in the PR description; that should work. Thanks @chibongho !

@brandones brandones merged commit e0288a0 into main Aug 5, 2024
6 checks passed
@brandones brandones deleted the O3-3242-card-config branch August 5, 2024 22:20
@chibongho
Copy link
Contributor

I've updated the config in the PR description; that should work. Thanks @chibongho !

@brandones the new config seems to work. thanks!

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

Successfully merging this pull request may close these issues.

4 participants