Type safe way to pass kwargs to sub-components

[maartenbreddels]

See #194, #50, #154, #182

If a solara component does not expose an argument/kwarg/prop that the underlying vuetify library supports, a user is stuck.

However, if we simply add **kwargs support, we lose type safety/strict argument checking. However, if we use something like

import solara
solara.SliderInt(..., slider_kwargs=solara.v.Slider(tick_labels=[....]))

We can provide a type safe way of passing kwargs to subcomponents.

In the case of #194, with the card component, we wrap multiple components, which cannot use a single **kwargs argument. Using our solution above, we can support it using:

import solara
solara.Card(...., card_text_kwargs=solara.v.CardText(....), card_kwargs=solara.v.Card(...))

Would be good to get feedback on this idea from @mangecoeur @Jhsmit @mariobuikhuizen or others.

[Jhsmit]

Yes i like it. I think something distinguishing the vuetify component from the solara component would helpful, which is something **kwargs does not do, rather it suggests they are more or less the same.

using solara.v.Slider does seem like a clean way to pass this information using the already available typing information from generated code.

Should they still be called kwargs now with this API? They arent really kwargs anymore, how about this:

import solara
solara.SliderInt(..., slider=solara.v.Slider(tick_labels=[....]))
solara.Card(...., card_text=solara.v.CardText(....), card=solara.v.Card(...))

now the kwargs more directly describe which view part of the component they reference to.

Perhaps this API could also be repurposed in the future to pass non-vuetify views/widgets to components?

import solara
solara.SliderInt(..., slider=solara.material.Slider())

By the way, the solara.Button component at the moment does pass kwargs

[mangecoeur]

Its an interesting solution, i tried something similar with my own Card component with a 'card_text_style' kwarg, although I didn't actually use it in the end.

The conceptual question is, are the solara components convenience wrappers around Vuetify components, or are they "solara's own" components that just happen to be implemented with vuetify elements? If they are solara 'internal' components then maybe they should better have their own api not related to vuetify.

On the other hand if they are mainly convenience wrappers this makes sense, i guess for advanced cases you'd want to use the vuetify components directly.

[maartenbreddels]

@mangecoeur

are they "solara's own" components that just happen to be implemented with vuetify elements

It is this. I think a user should be able to use the solara components for most of the work without having to know about (ipy)vuetify. But, for advanced users we do not have to hide that they are built using vuetify, and we can provide an escape hatch when you do need this specific-almost-never-used-vuetify-prop. I don't think we should expose the whole surface of vuetify, though, since it's just overwhelming.

@Jhsmit

import solara
solara.SliderInt(..., slider=solara.material.Slider())

This does imply that also the behaviour/implementation will be overridden, while originally it was only meant as a way to pass extra props/kwargs to underlying components. Maybe there is a good reason to do this, if not, maybe every vuetify component should have a TypedDict (also generated from the same reacton code generator) that can be used for typing the kwargs, e.g.:

@solara.component
def Card(...., card_text_kwargs:solara.v.CardTextDict = {}, ...)
    ...


======

class CardTextDict(TypedDict):
    # 100 vuetify props