(feat) Left hand navigation to queue by status table component #984
Conversation
|
Size Change: -55.8 kB (-2%) Total Size: 2.97 MB
ℹ️ View Unchanged
|
|
Thanks for this Mike. From the user interface, I see we'll render tabs for the different queue statuses. What is the exact use case for this, and how will it work with what already exists in the queuing module? Thanks |
The tabbed interface is already committed (see this commit), and available as an alternative view. It's just another view, it doesn't change what is already there. This DRAFT PR is just showing a possible approach to navigation using the left nav bar, where the links are dynamic and not hard-coded. For example, if we want to have a link for all queues in the system, we want to iterate over all of the queues and then render a link that will render a component, passing that queue in as a prop. I don't know if we have any existing examples of how this might be accomplished (the code in this PR doesn't really work as I'd want it to. it "works", but it refreshes the entire for each item that is clicked, and is more of a POC to get the idea across.) @ibacher / @denniskigen FYI - I hadn't really intended for this to be broadly discussed, but as long as we are, looping you in. |
|
I do want to re-emphasize that it was never the intention to have a "service-queues" app like this and that the designs that we're supposed to be working towards for queues is this, where the queue selected or visible priorities are changed via drop-down. |
Well, one place where queues are currently designed for use is in the "outpatient app", yes. And those designs have the dropdown as shown. But there may be lots of apps or places where we want to show queues in different ways, and not all of those have been designed out yet. The approach we are trying to take is to build configurable components that can be easily composed together into different UIs as needed. The "tabbed" view we just committed adds a new "queue table" component that allows one to easily display a table of queue entries with a configurable set of columns that can be extended by implementations. Then, it uses that queue table in one possible view in which a queue's active entries are displayed in tabs based on status. But this same table could/should easily be used in the "outpatient app" view that you describe @ibacher , and this could certainly change the queue entries that are displayed in the table based on what is selected in one or more dropdowns/filters. Our intention would be that we continue work on the existing components in the service-queues app and refactor them in this direction. I think we can also all agree that the Left Nav is has not been particularly well utilized in the Home App, and that we could do more here to provide easy access to the tools that people need. And that this is intended to be fully configurable via extension points. My goal here is to determine whether we could have a lightweight component that could iterate over a set of dynamic data to provide links in the LHN, and then a particular implementation could choose (or not) to add this in as an extension. |
mseaton
changed the title
chibongho
force-pushed
the
queue-nav-menu
branch
from
7d5fcd9
to
7878540
Compare
chibongho
force-pushed
the
queue-nav-menu
branch
from
7878540
to
9f87e15
Compare
|
@mseaton , @mogoodrich , @ibacher ok, this CSS is a bit more cleaned up now and ready for review. Again, non-standard UI here. But is only slotted into the side nav via extensions / configurations. OpenMRS.7.-.-.Microsoft.Edge.2024-03-11.09-17-06.mp4 |
There was a problem hiding this comment.
This looks great @chibongho - thanks! Unfortunately I can't approve being an author.
There was a problem hiding this comment.
LGTM, thanks @mseaton @chibongho
So then to get this to appear, in the PIH we disable the "service-queues-dashboard" extension and enable this one? Or am I already forgetting how extensions work? :)
| "component": "queueTableByStatusMenu", | ||
| "meta": { | ||
| "name": "service-queues", | ||
| "slot": "service-queues-dashboard-slot", |
There was a problem hiding this comment.
I'm forgetting, why do we need to have the slot listed in the meta here?
There was a problem hiding this comment.
It's just the way the home page app extensions work. I think it basically serves to connect the link component with the dashboard component that it renders.
Yes, see here @mogoodrich : https://github.com/PIH/openmrs-config-pihemr/pull/494/files |
This does not work correctly, it is just intended to show something quick for review. Do not merge.