Replies: 5 comments
|
used V0 to slim down the sidebar. IMO, this is far more useful for devs that are using shad to build a custom registry for their company. We don't need so many options crammed into one monolithic component. Instead of the mega- component pattern why not just have a few styles of sidebar? A company does not want each dev working on a project to make a unique sidebar. The goal is to be consistent. FYI: This is just a start and has not really been tested. |
|
You're not alone — this is a common frustration. The 1. Extract context, discard layout (the surgical approach) Pull only the context logic out of 2. CSS grid override via data attributes If you don't want to fork the component, use a wrapping container to coerce the sidebar into your grid layout: [data-slot="sidebar"] {
position: relative !important;
width: var(--sidebar-width) !important;
}Fragile on update, but quick. 3. Roll a minimal sidebar from scratch (honestly, not that bad) The sidebar is ~90% state management (mobile detection, cookie, toggle, keyboard shortcut) and ~10% layout. A minimal version is ~100 lines:
The Most projects in production I've seen end up at option 1 or 3 — keeping the context behavior and replacing the layout shell. The provider is doing the right thing internally (cookie, keyboard, mobile detection, state), it just shouldn't be deciding your page layout. |
|
Clean solution: separate the context from the layout entirely, let your CSS grid own the DOM. |
|
We could suggest using composition: render SidebarProvider as a wrapper only for context, and handle layout outside with grid, maybe using a custom wrapper component that provides context but doesn't enforce layout. Or suggest using the primitive Sidebar component from Radix UI and building your own layout. Just give suggestion. So start with "Consider" or "One way". Also avoid rhetorical questions ending with "?" mid-explanation |
|
Your read on it is right, For the specific case of a site-wide header above the sidebar, the technique that works with the stock component is offsetting with a CSS variable instead of fighting the flex wrapper: <div className="[--header-height:3.5rem]">
<SiteHeader className="fixed inset-x-0 top-0 z-50 h-(--header-height)" />
<SidebarProvider className="!min-h-[calc(100svh-var(--header-height))]">
<AppSidebar className="top-(--header-height) h-[calc(100svh-var(--header-height))]" />
<SidebarInset>{children}</SidebarInset>
</SidebarProvider>
</div>The official blocks gallery has a variant built exactly this way (the "sidebar with a site header" block), so it is a supported shape, just not the default. If you want grid to own the page layout, the cleaner surgery is to open That is also my honest take on the philosophy question: the mega-component exists so the default copy works for the 80 percent case, but the whole point of the copy-in model is that layout opinions are yours to remove. For a company registry your instinct is right, publish a slimmed provider plus two or three fixed sidebar recipes instead of the full option matrix. |
Uh oh!
There was an error while loading. Please reload this page.
Overall, the shadcn sidebar is a good component. well, at least until you start to make more complex layouts. recently I have realized that
SidebarProvideris trying to do too much. It is controlling layout when it should just be handling context. This makes it difficult to incorporate into other page-level layouyts. Want to have a site-wide header above the Sidebar? Nope.I was just wondering if other people have been running into the same issue and what you didi to alleviate. I did not want to have to bail on the shad sidebar, but more and more it looks like I am going to have to stop using it. It's just far too complex and tries to do everything for every site. It's using flex, which is not great bc page-level layouts are best handled by grid.
Has anyone else has some success wrangling the sidebar under control or have you bailed and just started rolling your own?
All reactions