-
-
Notifications
You must be signed in to change notification settings - Fork 310
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
[account] [docs] Add <Account />
in sidebarFooter
#4255
[account] [docs] Add <Account />
in sidebarFooter
#4255
Conversation
…into enh/account-3
…into enh/account-3
Feel free to remind me to review this one once the others are merged! |
Should be ready to review now! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some visual things and figuring out how we should type slots!
); | ||
} | ||
|
||
function SidebarFooterAccount() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs some logic to handle the mini-drawer variant, not to overflow.
The mini
prop should always be available in this slot, it's just a boolean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed that! I've modified the demo to be able to handle the mini
state
<Account | ||
slots={{ | ||
preview: AccountSidebarPreview, | ||
popoverContent: SidebarFooterAccountPopover, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In these docs demos, opening and closing the popover automatically scrolls unless they have the disableAutoFocus
prop, maybe we could have that somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great find! I've added disableAutoFocus
as true by default on the Account popover, but overridable by users through the slotProps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'm not 100% sure if we'd need it in a normal app though, maybe it's just a problem in the demo iframes.
@@ -0,0 +1,247 @@ | |||
import * as React from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the expanded
variant, could there be an option to choose whether the popup appears on the right or the top side?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to customize the popover's position (as well as the placement of the arrow) using the slotProps
- the demo on the docs will showcase this using the transformOrigin
and anchorOrigin
props
@@ -146,3 +146,7 @@ This allows you to add, for example: | |||
- footer content in the sidebar. | |||
|
|||
{{"demo": "DashboardLayoutSlots.js", "height": 400, "iframe": true}} | |||
|
|||
Through this, you can also modify the position of the `<Account />` component and use it inside the sidebar: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In #4340 I'm adding an Examples section here, I guess that we can just have this under that section once it gets added.
@@ -66,7 +66,7 @@ export interface DashboardLayoutSlots { | |||
* Optional footer component used in the layout sidebar. | |||
* @default null | |||
*/ | |||
sidebarFooter?: React.JSXElementConstructor<SidebarFooterProps>; | |||
sidebarFooter?: React.ElementType; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the SignInPage
slots are typed as React.JSXElementConstructor<Props>
but the slots in Account
are React.ElementType
?
Shouldn't it be consistent all around? What do the other MUI component use?
Also the SidebarFooterProps
have a mini
boolean prop that can be useful, so we need the types to be aware of it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the sidebarFooter
type as well as the types of the Account
slots; agree on the need for consistency - we can probably discuss this and raise a PR separately to bring consistency across all other components
…ap/mui-toolpad into feat/account-sidebar-variant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!! Thanks for the changes!
/** | ||
* To override the default `sx` value on the `Stack` component in the "expanded" variant | ||
*/ | ||
sx?: SxProps; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it applies to the expanded variant only? Probably ideally it would apply to any variant to be less confusing.
If you're not using it yet maybe we can skip this prop for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, we can leave it out for now, adding it will not be a breaking change later
…ap/mui-toolpad into feat/account-sidebar-variant
Account
#4102Summary of grooming discussion
Props:
hideToolbarAccount
prop, users can pass a component which returnsnull
into thetoolbarAccount
slot when using<Account />
inside the sidebar footerSlots:
export composable components:
=> for the sidebar version =
scenarios:
https://deploy-preview-4255--mui-toolpad-docs.netlify.app/toolpad/core/react-dashboard-layout