It’s probably not ideal for a new user to have to dig into the source to find this type definition.

I’d suggest exporting ViewOrViews from core, since it’s used in the public Widget class and the intent is to mirror how Deck props are typed.

haha, yes, I anticipated this comment.

As usual, I'm stuck in my old school view, where a problem with typescript is that through this type of issues, suddenly users want little helper types exported, leading to big, often unaudited increases in the supported public API.

This one really sounded like an internal helper so I opted not to export it.

I guess I could even have avoided redefining it, and just typed it out where needed.

Oh well...

I figured this was probably intentional on your part. And given that ViewOrViews is an older, stable type, it’s unlikely to change.

To your point, widgets really stress the API.. similar to writing layers or effects from scratch. Suddenly there’s a pull to externalize internal APIs because widget authors are effectively changing Deck’s top-level behavior.

One key difference I’m seeing vs. our other components is that widgets often override Deck behavior (e.g., taking control of initialViewState). That’s the opportunity, but also why we’ve struggled.

Would it be worth documenting where we draw the line here - maybe a page in the unfinished “custom widget” guide that outlines what’s supported, what’s discouraged, and where the boundaries are?