createBentoProvider() should merge the props.config with the config from parameters instead of replacing it

[mperrando]

Hi @veej and @gabro, I would like to have your opinion on what follows.

In the case one defines its own DesignSystemProvider

export const DesignSystemProvider = createBentoProvider(myDefaultConfig, sprinkles);

and then, when using the DesignSystemProvider, tries to override a property of the config

        <DesignSystemProvider config={{ dropdown: { chipColor: "pink" } }} defaultMessages={defaultMessages}>

the config in the props is replaced and not merged, and all the customisations of myDefaultConfig are lost.

IMO the user expects to override that single property, maintaining all the customisation done on DesignSystemProvider.

I propose to change the line in createBentoPorvider()

<BentoConfigProvider value={props.config ?? config}>

to

<BentoConfigProvider value={{ ...config, ...props.config }}>

[veej]

Hi @mperrando.
Thank you for your suggestion! I’ll review the current behavior and get back to you soon.
In the meantime, if you could describe your use case, it would help us understand the best approach for this behavior.

As per current behavior, if you nest two BentoProvider instances (or a BentoProvider with a BentoConfigProvider), the configuration passed to the inner provider should already be merged with the parent one.
The idea is that the outermost wrapper is always the exact BentoProvider you created with the config passed to createBentoProvider (without passing any config), and then you can have other nested BentoProvider to override specific configs.

Is there a specific reason to override the config passed to createBentoProvider in the outermost provider instead of passing the right one directly to createBentoProvider?

[mperrando]

The scenario is the following.

We share a common DesignSystemProvider among different applications that customises a lot of things.
We want to override the dropdown chip color only for a single application.

Thank you!

[veej]

Thank you, @mperrando. Your use case makes perfect sense. I’ll try to open a PR with the change soon.

[veej]

PR opened: #999