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

[PageContainer] Allow full-size content #4480

Merged
merged 16 commits into from
Dec 12, 2024

Conversation

apedroferreira
Copy link
Member

@apedroferreira apedroferreira commented Nov 26, 2024

Closes #4324
Closes #4072
Needed it already in the CRUD for the list table to take up the full space in the layout.

As per the discussion in #4324:

  • Allow full-size content inside PageContainer with flex: 1 or height: 100%.
  • Add sx prop to PageContainer.
  • Separate PageHeader from PageContainer to optionally be used as a standalone component
  • Documented both the cases above

https://deploy-preview-4480--mui-toolpad-docs.netlify.app/toolpad/core/react-page-container

BREAKING CHANGE: toolbar slot was moved to PageHeader component which can be configured with the header slot in PageContainer. Updated examples in docs to reflect this. It should just be a step towards separating the components as proposed in #4525.

@apedroferreira apedroferreira added core Infrastructure work going on behind the scenes bug 🐛 Something doesn't work component: PageContainer labels Nov 26, 2024
@apedroferreira apedroferreira self-assigned this Nov 26, 2024
@@ -1,5 +1,5 @@
{
"props": {},
"props": { "children": { "type": { "name": "node" } } },
Copy link
Member Author

@apedroferreira apedroferreira Nov 26, 2024

Choose a reason for hiding this comment

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

Proptypes are now being generated for the components which don't match the name of the folder (secondary components), I think that should be a good thing?
Changed it in the script that generates proptypes so that the API documentation for PageHeader would be there, auto-generated.

@@ -204,7 +204,7 @@ async function run(argv: HandlerArgv) {
folderName = folderName.slice(9);
}

return fileName === folderName;
return !fileName.endsWith('.test');
Copy link
Member Author

@apedroferreira apedroferreira Nov 26, 2024

Choose a reason for hiding this comment

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

Generates proptypes for all non-test files inside the folder of each component.

Copy link
Member

Choose a reason for hiding this comment

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

This is also generating proptypes for components marked as @ignore in the JSDoc comments - something to fix?

Copy link
Member Author

@apedroferreira apedroferreira Nov 27, 2024

Choose a reason for hiding this comment

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

I guess we can try to exclude them if it's easy to do.
done!

@apedroferreira apedroferreira changed the title [PageContainer] Allow full-size content inside [PageContainer] Allow full-size content Nov 26, 2024
@apedroferreira apedroferreira added scope: toolpad-core Abbreviated to "core" and removed core Infrastructure work going on behind the scenes labels Nov 26, 2024
@apedroferreira
Copy link
Member Author

Looks like the CI is having out of memory issues again, we probably either need to manage dependencies to stay under or increase instance sizes?

@bharatkashyap
Copy link
Member

Looks like the CI is having out of memory issues again, we probably either need to manage dependencies to stay under or increase instance sizes?

Yes, although I'm wondering what exactly triggered the CI out of memory issues

Copy link
Member

@bharatkashyap bharatkashyap left a comment

Choose a reason for hiding this comment

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

Looks good, just some suggestions on the docs demo and one flag on the proptypes script.

Also, I'm guessing this counts as a breaking change since we are renaming PageContainerToolbar to PageHeaderToolbar

apedroferreira and others added 5 commits November 27, 2024 14:10
…r.md

Co-authored-by: Bharat Kashyap <bharatkashyap@outlook.com>
Signed-off-by: Pedro Ferreira <10789765+apedroferreira@users.noreply.github.com>
bharatkashyap

This comment was marked as outdated.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 28, 2024
Copy link
Member

@bharatkashyap bharatkashyap left a comment

Choose a reason for hiding this comment

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

On second thought:

Apart from standalone usage, should we make the PageHeader composable inside the PageContainer as well? Just as we made the ThemeSwitcher composable inside ToolbarActions?

Something like

<PageContainer>
  <PageHeader slots={{toolbar: CustomToolbar}} />
  {children}
</PageContainer>

This way, we could also move the toolbar slot to PageHeader, which better reflects its position anyway.

Wdyt? I know it's a tangential part of this PR, so feel free to extract the rest if this feels too blocking

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Nov 28, 2024
@apedroferreira
Copy link
Member Author

apedroferreira commented Dec 2, 2024

On second thought:

Apart from standalone usage, should we make the PageHeader composable inside the PageContainer as well? Just as we made the ThemeSwitcher composable inside ToolbarActions?

Something like

<PageContainer>
  <PageHeader slots={{toolbar: CustomToolbar}} />
  {children}
</PageContainer>

This way, we could also move the toolbar slot to PageHeader, which better reflects its position anyway.

Wdyt? I know it's a tangential part of this PR, so feel free to extract the rest if this feels too blocking

Sounds like a probably good idea, we can discuss it just to make sure.
The only drawback from that suggestion would be that the PageContainer wouldn't work as well out of the box, but we could probably fix that by giving it a slot for the header content with PageHeader as the default?

@bharatkashyap
Copy link
Member

bharatkashyap commented Dec 2, 2024

Sounds like a probably good idea, we can discuss it just to make sure. The only drawback from that suggestion would be that the PageContainer wouldn't work as well out of the box, but we could probably fix that by giving it a slot for the header content with PageHeader as the default?

I feel we can enforce a migration now to a composable API and remove the header and toolbar slots entirely given that it is likely to be the more popular way of customization. The breaking change would have to be adding a:

<PageContainer>
+  <PageHeader>
+     <PageHeaderBreadcrumbs /> // would contain the default breadcrumbs
+    <PageHeaderToolbar> ... </PageHeaderToolbar>// (optional, this would replace the `toolbar` slot)
+  </PageHeader>
   {children}
 </PageContainer>

to all uses of PageContainer to get the breadcrumbs out of the box.

We can discuss this tomorrow or in next week's grooming 👍🏻

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Dec 3, 2024
@Janpot
Copy link
Member

Janpot commented Dec 3, 2024

What would be the difference between PageContainer and

On second thought:

Apart from standalone usage, should we make the PageHeader composable inside the PageContainer as well? Just as we made the ThemeSwitcher composable inside ToolbarActions?

Something like

<PageContainer>
  <PageHeader slots={{toolbar: CustomToolbar}} />
  {children}
</PageContainer>

This way, we could also move the toolbar slot to PageHeader, which better reflects its position anyway.

Wdyt? I know it's a tangential part of this PR, so feel free to extract the rest if this feels too blocking

what would be the difference between the PageContainer and a @mui/material Container? Wouldn't it be enough to just build a PageHeader component?

@apedroferreira
Copy link
Member Author

apedroferreira commented Dec 9, 2024

Sounds like a probably good idea, we can discuss it just to make sure. The only drawback from that suggestion would be that the PageContainer wouldn't work as well out of the box, but we could probably fix that by giving it a slot for the header content with PageHeader as the default?

I feel we can enforce a migration now to a composable API and remove the header and toolbar slots entirely given that it is likely to be the more popular way of customization. The breaking change would have to be adding a:

<PageContainer>
+  <PageHeader>
+     <PageHeaderBreadcrumbs /> // would contain the default breadcrumbs
+    <PageHeaderToolbar> ... </PageHeaderToolbar>// (optional, this would replace the `toolbar` slot)
+  </PageHeader>
   {children}
 </PageContainer>

to all uses of PageContainer to get the breadcrumbs out of the box.

We can discuss this tomorrow or in next week's grooming 👍🏻

One of the main advantages of using Toolpad is that it does standard things for you with little code. I feel like if we separate the container into too many sub-components that usually need to be used it kind of complicates things.

I prefer the approach where we provide a few components and more detailed customization can be made with slots.

what would be the difference between the PageContainer and a @mui/material Container? Wouldn't it be enough to just build a PageHeader component?

Not a lot right now, but at the moment the PageContainer has styles that make it so that the content inside it can take up the full height inside the layout, and some default spacing around its content.

It seems like these wouldn't be difficult to do with a standard Container, especially if we provide an example on the docs on how to do full-size content in a page... So we could export the PageHeader only and include an example like that in its documentation.

@apedroferreira
Copy link
Member Author

apedroferreira commented Dec 9, 2024

As discussed, the PageContainer will have a header slot for now that uses PageHeader by default.
Also as discussed, we can eventually deprecate the PageContainer and have a PageHeader only. Created an issue for that in #4525

Also, as a global discussion, we can start considering a more composable API for customization with different sub-components as opposed to slots in some cases at least.

@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Dec 9, 2024
Copy link
Member

@bharatkashyap bharatkashyap left a comment

Choose a reason for hiding this comment

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

Looks good! We should make sure to mark this as a breaking change in the release notes

apedroferreira and others added 3 commits December 12, 2024 13:06
…ntainer.tsx

Co-authored-by: Bharat Kashyap <bharatkashyap@outlook.com>
Signed-off-by: Pedro Ferreira <10789765+apedroferreira@users.noreply.github.com>
…ntainer.js

Co-authored-by: Bharat Kashyap <bharatkashyap@outlook.com>
Signed-off-by: Pedro Ferreira <10789765+apedroferreira@users.noreply.github.com>
@apedroferreira apedroferreira merged commit 46a3e8c into mui:master Dec 12, 2024
13 checks passed
@apedroferreira apedroferreira deleted the full-size-page-container branch December 12, 2024 13:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something doesn't work component: PageContainer scope: toolpad-core Abbreviated to "core"
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow PageContainer Children to Fully Utilize Viewport Height [core] Add PageHeader
3 participants