In regard of #11407: This component currently has style parameters required for the background color parameter => is this okay in this case?

If I may already request for a feature: double-clicking the divider will reset it back to its initial position/value.

In regard of #11407: This component currently has style parameters required for the background color parameter => is this okay in this case?

Private style builders are fine if necessary, but we would remove public members StyleFirstPanel, StyleSecondPanel, etc. I should clarify that in the PR

I wonder if a debounce would help with some of the UI lag while adjusting the panels

@91378246 Really excited about this new component! 🎉

A split panel is such an important building block for docking panels, it opens the door to powerful UI layouts where users can drag, drop, and resize their views with tabs and panels. You see this pattern all the time in dashboards, monitoring tools, and trading applications.

Here’s a neat open‑source example if you’d like to check it out: https://dockview.dev/demo?theme=dark

Not sure what direction you’re planning to take, but it would be awesome to keep the idea of more “advanced docking options” in mind as this evolves.

Not sure what direction you’re planning to take, but it would be awesome to keep the idea of more “advanced docking options” in mind as this evolves.

I, on the contrary, wouldn't include anything advanced and would keep it as simple as possible to reduce the space for bugs and make it easier for others to maintain. If someone needs an advanced docking system, they can take the same dockview and wrap it in a Blazor component, it's not that hard. Reasons why I say so:

1. Making complex dock with split, grid etc is hard. It's enough to look at dockview with 2k commits and the core code.
2. We're not Syncfusion, Telerik, or DevExpress with a large team working on it full-time. Their approach is to create as many components and features as possible that clients want, in order to hook them into the stack and make money from it, which makes sense.

If I may already request for a feature: double-clicking the divider will reset it back to its initial position/value.

@Yomodo Good idea, added it

I wonder if a debounce would help with some of the UI lag while adjusting the panels

@danielchalmers It just looks laggy in the screen recording (I recorded it with 60fps, i guess github compresses the gif more?)

Not sure what direction you’re planning to take, but it would be awesome to keep the idea of more “advanced docking options” in mind as this evolves.

@Pinox I thought about it during development but it would be a lot of work to implement that in an easy to use and user-friendly way => I agree with @ScarletKuro that this is currently out of scope for this pr.

@ScarletKuro Thanks for the thoughtful response, I completely agree on keeping MudBlazor's core lean and maintainable. That's one of its biggest strengths as an open-source project without a massive commercial team behind it.

I didn't mean to suggest bloating the SplitPanel with advanced docking features (grids, tabs, etc.) definitely out of scope. Wrapping something like dockview is a solid path for complex needs.

What I had in mind is more like how Microsoft introduced hybrid caching patterns in .NET, then the community (e.g., FusionCache) built richer implementations on top. Similarly, a minimal SplitPanel in MudBlazor could provide core resizing logic and events, then an external library could add docking, persistence, multi-panel layouts, etc., without touching the main repo.

You rightly point out wrappers are a great solution (e.g., Blazor-ApexCharts). That does raise an interesting question: why include charts in core when extensive alternatives exist? I suppose it comes down to someone writing clean, small, useful code and if it fits, it ships. Fair point!

I think this might be wishful thinking (and a touch of ignorance) on my part ;)) but who knows? With AI and agentic coding advancing fast, converting something like dockview to C# might not be far-fetched in a year or two.

Either way, super excited about this component in its current form, great work on the PR! 🚀