feat(widgets): Update SplitterWidget

[Pessimistress]

This PR proposes a new model for the SplitterWidget that does not rely on use callback to manipulate deck views.
The user passes a layout descriptor to the widget, and the widget takes over the settings of deck.props.views.

const deck = new Deck({
  layers: [],
  widgets: [
    new SplitterWidget({
      // style: DarkTheme,
      viewLayout: {
        orientation: 'horizontal',
        views: [
          new MapView({id: 'left', controller: true}),
          {
            orientation: 'vertical',
            views: [
              new MapView({id: 'right-top', controller: true}),
              new MapView({id: 'right-bottom', controller: true}),
            ],
          }
        ],
      }
    }),
  ]
});

Screen.Recording.2026-03-06.at.8.47.19.PM.mov

This would run into a racing state if the user attempts to set views from outside, e.g. the DeckGL React component always sets views to null on rerender if it's not specified by the user. I see two options in mitigating this:

• Provide views as a parameter in the onChange callback, and ask React users to always use this widget with views as a controlled state. This is more work for the user but avoids any confusion.

• Change the React component's behavior to avoid resetting layers and views to the default value. This will make sure that deck's props are not implicitly overwritten. In the case where there is indeed a user error, i.e. deck.props.views has an unexpected value (not null or the last value set by us), the widget can stop writing to this prop and issue a warning to the console.

Change List

• Redesign SplitterWidget props & model
• Move hardcoded CSS to stylesheet
• Documentation

[coveralls]

coverage: 91.011%. remained the same
when pulling 5e97e81 on x/widget-splitter
into 1d10e01 on master.

[ibgreen]

Good to see another concrete proposal here.

Quick thoughts (to the extent that I have understood this correctly).

I personally think a layout system could be an extremly valuable addition for our views. We increasingly need some CSS like way to "grid" or "flexbox" our views.

That said I would have hoped to see such support in the main deck.gl view prop. At least on initial thought, I am less keen on seeing it added it to a specific widget. (But one could perhaps envision a "global" layout design where widget could influence a some parameters of a global view layout somehow, rather than completely define and override it).

The general discussion about the widget/deck integration model have been helf before. I would much prefer letting the widget add views rather than overwrite them, but I expect this is a philosophical difference that is not easily resolved.

on a side note, I heard from @chrisgervang that he was working on a bigger proposal for imperative control of deck.gl focused on widget needs and was perhaps naively hoping that some principles might emerge from that discussion that could guide us here.

Anyway, willing to be open minded during audit so that we can finally get to a decision here, the SplitterWidget deserves a chance to finally show what it can do.

[Pessimistress]

I agree that deck needs a better native layout system. I see widgets as a testing ground for such ideas with limited impact. Even if we add such a system in the future, I don't see the (very simple) APIs of this widget getting scratched.