Add detail view page

[cameron-bowery]

Love this library and where it's headed. 🙏 Thanks!

Is your feature request related to a problem? Please describe.
Often a table can't display clearly all information about an entity, Would prefer not having to horizontally scroll.

Describe the solution you'd like

1. I would like to be able to view an entity with perhaps many fields as a vertical scroll rather than in table form (horizontal) on a separate page from "List". Call it "View"
2. I would suggest losing the hamburger menu and replacing it with a "View" button
3. And from this "View" page give the option to "Edit"
4. And move the delete option to the "Edit" page or have "Delete" next to "Edit" on the "View" page, either way

Describe alternatives you've considered
Using the edit page as the detail page. Not ideal.

Would you accept a PR for this?

[tfwright]

Hey, thanks for kicking off the discussion on this. I've been putting off adding a "detail view" since as you noted, the edit page can perform that function even if it is not ideal. However, I think now that the architecture is a bit more stable it's probably a reasonable time to do it. If you want to open a PR I'd be happy to review it.

Some current thoughts:

The table buttons/links are one thing that's changed a lot. Beside the edit and delete controls, which used to each be separate buttons, the hamburger also lists any "actions" defined on the resource. Since there can potentially be a few of those, I wanted to avoid rendering buttons for each, and I don't want to force the user to enter a detail view to run them. Another option there would be to introduce a row selection UX (e.g. checkboxes) which could be used to run any of those supplementary actions on one or multiple rows using a single dropdown, in which case we could replace the row hamburger with a view button. But that seems beyond the scope of this discussion, so for now I think that needs to stay.

As for the detail view itself, one thing I've been going back and forth on is whether it should be a separate route, or a modal that is shown when a given url param is present on the list view. I am a bit inclined to the latter because my guess the UX will feel a bit snappier to enter/exit detail views quickly, but I'd be interested in your thoughts there.

cheers

[cameron-bowery]

Awesome to hear this is aligned with your vision.

Re hamburger button: How about we just leave is as is and add the "view" action for now? Or is your preference for word "detail"?

Re View/Detail as modal. I see how how a page redirect is unnecessary because the data is already there. The modal is like a "zoom in", more ephemeral experience. But our needs for the library differ quite a bit from that. We want a "View" page because each individual entity will have various actions and extra contextual data that doesn't fit nicely into a modal or the table. The "View" page is where we would end up having custom templates for the most part, not just custom actions (that could go in the hamburger menu).

Maybe the table-first approach makes more sense for a library though -- with actions embedded there. Somehow our admin pages "List" pages are more like listViews (with filters and sorting only) and actions on the entity instance level. Not sure if that's the case for other people.

[cameron-bowery]

One other quick point on this. We noticed there isn't a link for association fields. Which makes sense: If an article has a authorId column, clicking the cell couldn't possibly have a destination link without the "View" as a page. We have a certain need for this in our admin.

[tfwright]

How about we just leave is as is and add the "view" action for now? Or is your preference for word "detail"?

Yes I think for let's just add a link to the new component alongside the other actions in the hamburger. I think "View" or "Show" make the most sense. I am planning on gettext integration at some point hopefully so users will be able to customize this kind of copy easily.

We want a "View" page because each individual entity will have various actions and extra contextual data that doesn't fit nicely into a modal or the table.

This makes sense to me. A separate route is the most customizable so let's go with that. It can work similar to most of the existing routes that load a component inside the Container depending on route.

We noticed there isn't a link for association fields.

I think association cells in the table did actually link to the edit page at one point. I removed that when I added the ability to override the render logic for each field (you can use the render option for association fields to turn them into links to wherever you want currently). The logic there has become a bit complex and might take some refactoring to get it to work, so although I agree we should figure out a way to get it to link to this new view, we can tackle that in a separate PR after the show itself has been added.