Create context aggregator something like a ClayManager

[matuzalemsteles]

Going back to our conversations we had in #2250 related to Clay's context aggregator. I think we should start implementing this as the number of contexts within Clay is starting to grow.

The implementation may look similar to this.

<ClayManager
    value={{
        // It may just be an initial empty object that can be passed to DataProvider,
        // it helps to cache here and be reused on different pages...
        storage: {},
        // Some settings to enable the use of ModalProvider...
        modal: '...',
        // We may have some setting to enable or disable tooltip...
        tooltip: '...',
        spritemap: '...',
        linkComponent: Link,
    }}
>
   <MyApp />
</ClayManager>

[bryceosterhaus]

Are you thinking of including this in @clayui/shared or its own package? Primarily I am thinking of how we want to handle importing the package-level contexts and managing those dependencies.

We might want it to be its own package since we don't want people to have to depend on modal when they use shared.

[matuzalemsteles]

Are you thinking of including this in @clayui/shared or its own package? Primarily I am thinking of how we want to handle importing the package-level contexts and managing those dependencies.

I actually want to expose ClayManager and leave it as its own package (@clayui/manager).

We might want it to be its own package since we don't want people to have to depend on modal when they use shared.

Hmm, I don't know if I understand this well but do you mean that if the user depends on the @clayui/manager package we don't want him to depend on modal?

[bryceosterhaus]

I was referencing whether we would do import ClayManager from '@clayui/manager' or import {ClayManager} from '@clayui/shared'.

The dependencies of ClayManager component would be

• @clayui/link
• @clayui/icon
• @clayui/modal
  etc..

I think we are on the same page though, if it is its own package, we should be fine with a handful of dependencies.

[matuzalemsteles]

Oh I see, yeah I think we're fine to have your own package.

[matuzalemsteles]

I am adding this to our final milestone of v3.0.0, it would be interesting to see this in this release but it does not prevent us from adding it in future releases.

[diegonvs]

Makes sense adding a sizing like property on the provider for forcing sizing style variations of some components? It will be like:

<ClayManager
    value={{
        // It may just be an initial empty object that can be passed to DataProvider,
        // it helps to cache here and be reused on different pages...
        storage: {},
        // Some settings to enable the use of ModalProvider...
        modal: '...',
        // We may have some setting to enable or disable tooltip...
        tooltip: '...',
        spritemap: '...',
        linkComponent: Link,
		sizing: 'small'
    }}
>
   <MyApp />
</ClayManager>

and it will force all small properties to be true on Provider's children.

/cc @victorg1991 @sandrodw3

[bryceosterhaus]

I don't think design is as clear cut as that. I think they typically use a mix of all sizes in an app, so I don't think it'd make sense to default to a different size than the components already offer. Design could probably help answer this though.

[kresimir-coko]

Hey @bryceosterhaus @matuzalemsteles this sounds like an interesting issue, are we going to proceed with it, or is it off the table?

[matuzalemsteles]

@kresimir-coko I think this is still worth it, we have some contexts out there. This was downgraded at the time, but we can re-validate the cases again and start implementing this.

[bryceosterhaus]

Yeah I agree with @matuzalemsteles, I think its still worth it and will probably need in the future, but it's not pressing at the moment.