Widgets with specific "slots"

[craig0990]

One example is Gtk.Window and it's set_titlebar() method. Other examples include non-Gtk.Buildable widget components like a Gtk.StackPage ¹.

I simply can't think of a "nice" way to expose these kinds of widgets in the tree-style of JSX.

For example one "idiomatic" style of building a Gtk.Stack might be:

<stack>
    <stackPage name="Tab 1"><label label="My Text" /></stackPage>
    <stackPage name="Tab 2"><label label="My Text" /></stackPage>
</stack>

But:

• I can't append a Gtk.StackPage based on my current strong preference for just delegating to new and vfunc_add_child
• If we moved on that, we could add a list of "manual" constructables, but we'd have to implement some kind of wrapper for handling children for these classes, effectively "wrapping" any non-Buildable components and leaving us behind if upstream updates / adds new classes

It's worse for some items like a Gtk.Window where a custom titlebar might be desirable - like a Gtk.HeaderBar - since there's no point at which the titlebar is "appended" to the parent widget, there's never a point where the reconciler appendChild function gets called. In an example:

<window titlebar={<headerBar ... />}>
</window>

The JSX is fine, but the reconciler never sees the <headerBar /> getting inserted into the tree, so appendChild is never called. This is similar to the StackPage issue above: in other React libraries you could think of these as "named slots" and the render prop pattern, but in React DOM they would ultimately get appended with domElement.appendChild - and here, they don't...

Wrapping each widget with a custom class might alleviate some of these difficulties, but I'm loathe to consider it, because it would be nice to continue piggy-backing off the exitsing GObject/GJS bindings and not having to do this extra work to track upstream.

No solutions here, just pegging a note to remind myself why this repository hasn't moved.

Things that have crossed my mind:

• Multiple React roots for forcing a render of things like titlebar attributes, but this feels like a bad idea for complexity when reconciling state/prop updates throughout the tree
• Portals, which might well be nice, but they suffer the same "out-of-tree" problem described for titlebar - it never gets appended in the tree, so it never gets rendered
• Refs, which currently give us an escape hatch to mutate the rendered widget programatically, but that rather defeats the point of the React integration in the first place - there's currently an example of this
• Wrappers, obviously 😔

Footnotes

1. In fact, it doesn't seem to be recommended to instantiate these yourself at all ↩