Page component flexibility

[yesenia-perezcruz]

The Page component is one of the most complex components in Polaris. It's used 366 times in admin and is used on highly used pages. This is a good candidate for making components more flexible.

Issues I see today:

• It's used to build the outer wrapper of the page but visually, it just looks like the page header.
• The design guidance for the component only talks about the page header, even though the component is called page.
• Page titles in admin are both system-generated and user-generated, which creates wrapping issues when the page title is too long.
• The rigidity in the component means that we can't adjust the page header to work well for different primitives (i.e. an Order vs a Product)

Opportunities:
Rather than having one big component, Page component could be broken apart into:

1. guidance for how to construct an admin page, including where to place page actions (today it's confusing when to place them on the top vs bottom)
2. a composable Page header pattern that specifies where actions, breadcrumbs, and the page title should be placed, but allows for more customization based on the admin primitive

I'd like to use this discussion to collect other issues, opportunities, and ideas to improve the Page component.

[alex-page]

I agree with all of the points raised.

I would like to decouple or simplify the rollup logic. It's very complex and sometimes causes more friction then benefits. It often hides the buttons too early or rolls up important buttons that users can lose.

[kyledurand]

+1 to all the points above. If we could decouple the header from the page component then what we're left with is basically a container with padding at varying widths (fullWidth , narrowWidth, defaultWidth. All of the complexity lies in the header component which has 9 props, some of which allow for multiple types of elements i.e. an array of actions or a ReactNode. It also manages a combination of layout logic based on CSS breakpoints and breakpoints in JS.

All that to say it's very tough to maintain. I think breaking it down into separate components would allow teams to compose pages and contribute more effectively

[zecarlostorre]

+1 to all said above, specially the idea of breaking this into smaller components + guidance.

One other issue that multiple designers have brought to me, is the position of titles in narrow widths (mobile), which I believe happens because of some limitations around this component, rather than being an intentional design decision.

[SeanyB]

+1 to the above. From the lens of an app builder, the Page component is very useful as a container for each page of the app with different padding options. However, the title and action props are best ignored, instead using the App Bridge Titlebar. Conversely, core admin builders should use the title and action props. Splitting these apart could help Shopify clarify how and when to use each piece.

[heyjoethomas]

I also think there is some visual change that would just tidy things up a bit. For instance, I think the buttons feel really big and take up too much space. The back button in particular feels too prominent and it creates misalignment of the title to the content below.

[demipeppas]

Hey all! I'm excited to see this being talked about because our team has been challenged by this component recently.

The Customer segmentation team and the Orders team are testing a new navigation pattern in the Page component. We’re adding an interactive element to the page title that allows a Merchant to filter the context of the page. This element is a button that triggers a popover selector, and this element can be named anything by the Merchant. This can potentially make the title of the page extremely long.

The current solution in place forces the name to wrap, similar to how we handle it for Detail pages across the admin, but because the Customers Index is an Index and not a Detail page, the behaviour is different, and exacerbated by the fact that on Indexes, page title elements do not stack vertically under the Page-level action buttons as the page scales. Here is a video of both Index and Detail wrap behaviours.

I wrote about the problem more in this doc, so if you want more context on the specific issue we're facing, and how we've tried to troubleshoot, take a look there. But the gist of it is in this comment.

[mirualves]

The Core Optimize team is working on a new cohort analysis report and want to improve the page component. Additionally, we would like to fix all the other reports with the same issue on the mobile web view.

As we are all aware, this is how the page component looks like on mobile:

If we keep it this way, this is what happens: lots of unnecessary white space at the top of the report.

This is what I'm proposing:

Along with the poor usage of real estate, the back button from the page component conflicts with the app's back button. It causes duplication, and we should keep only one of them (app level).
The report title should be part of the page component (currently, it's not possible to have strings on the page component - if I'm not mistaken), so it doesn't create the weird and unnecessary space (as you can see on the images I'm sharing). This problem is even more noticeable on the horizontal view of reports.

Figma page with the images I shared in this comment

Closed GitHub issue highlighting the problem a while ago.

[heyjoethomas]

One thing to note here is the distinction between native app and web. Mobile web won't have access to the app navigation and within the app itself there are native views and embedded web views. The back button is needed on mobile web and probably will show in some web views where a fully native screen wouldn't see it.

I massive change like this I think would also need to be thoroughly tested since it would effect every page.

I do agree we could make this better than it is today and the issues you raised are 100% correct and worth trying to solve.