Custom Preview provider not working on bit.cloud

[rickykenny]

Description

I'm making a custom aspect to wrap compositions with a HOC, and it works fine locally but bit.cloud never actually injects anything into the composition.

I've put together a contrived and extremely simple case to rule out issues with dependencies etc, just wrapping compositions with a div that adds a border to its children. Here is the scope: https://bit.cloud/hutly/test

react.registerProvider([({ children }: any) => <div style={{ border: "2px solid blue" }}>{children}</div>]);

Specifications

• Bit version: 0.0.833
• Node version: 16.17.0
• npm version: 8.15.0
• Platform: windows 11
• Bit compiler (include version): unsure how to find this?
• Bit tester (include version): unsure how to find this?

Context and additional information

I'm ultimately trying to create a custom aspect to wrap my Chakra-ui components with a theme provider. I'm aware that I'll need to add resolveFromEnv in my aspect's main.runtime.ts file when I want to use a react context to provide the theme, however this example is just a simple div, so I assume this isn't necessary. Nevertheless, it doesn't work on bit.cloud.

[benjgil]

Hi @rickykenny Your example env had a few issues, which once clearing up then fix the main issue in this thread, but throw up another bug that i'll open.

Issues with your env:

1. You dont actually register the env - e.g. see line 445 in our react env. Without this your env won't be registered and won't work as a bit env.
2. You've configured the aspect env for your env, and not teambit.envs/env. Again that'll affect how the env behaves, especially with regards component Preview
3. You hadn't actually applied your env to your component - if you hover over the env icon next to the react/test component you'll see it's using our core react env.

After fixing all these issues and tagging i can see that the blue border is applied to compositions as configured. If you temporarily add me to the hutly org I can export the new components there for you so you can see what i've changed and that the compositions are working fine (barring the new issue below)

~~New issue - the preview wrapper gets applied in the composition page, but not when rendering the composition inside the gallery on the Overview page~~ New issue (or existing issue?) It seems the preview wrappers are getting applied to the whole of the Overview page instead of just to each composition in the gallery, so you get this (note blue border): Instead of a blue border around each composition, e.g.

@GiladShoham something we should do differently...

[GiladShoham]

Thanks @benjgil @odedre or me will have a look on the wrapper issue

[MilesNorton]

@rickykenny I've added Ben to the test scope to apply the fixes

[rickykenny]

Thanks @benjgil for the awesome support! Perhaps I misunderstand the relationship between envs and aspects, I'll admit I'm still a little unsure of how it works 😅 If I understand your answer correctly, you're suggesting I should be creating a new env (based on the teambit/react env) rather than creating an aspect to modify the teambit/react env preview runtime?

This is the mental model I'm working from:

• Envs are the environment that bit uses to run and test the components, such as React or Node. Eg the React env has jest preconfigured for tests. A component can only use one env.
• Aspects allow teams to extend an env with extra features, such as modifying the jest config in the React env or wrapping compositions with a provider/HOC.

Based on this understanding, I was hoping to keep my components using the react env, create a chakra aspect that extends the React env's preview runtime to wrap compositions in a theme provider, and create a formik aspect that wraps compositions in a formik provider.

Then I can configure the react/chakra directory to use the chakra aspect, and configure the react/chakra/components/formik-inputs directory to use both the chakra aspect and the formik aspect.

1. Am I misunderstanding envs and aspects?
2. Are there other aspects (pardon the pun!) of envs that would make them a better choice for this scenario? I'd love to have my tests able to use react-testing-library wrapped with my chakra and formik providers, so I don't have to include those in every test. That's a whole other question, but I figured it might play into the env vs aspect decision?

[rickykenny]

I just stumbled on this tutorial of an env for MUI: https://bit.dev/blog/how-to-build-material-ui-components-with-bit-l3isiibs/ Looks like it answers most of my questions 🙏

[benjgil]

@rickykenny Apologies also for the delayed response to your questions above. Aspects and envs are two concepts which are central to bit, but shouldn't be confused. Aspects, and specifically with regards Bit, are shareable components which interact with Bit itself, and change how Bit behaves. They have a specific syntax, which allows bit to load them and inject their other aspect dependencies so that they can interact with other Aspects in Bit. E.g. there's the Tester aspect, which anyone who wants to run a test with Bit needs to interact with. The Compiler aspect for running compilcation. etc etc.

Envs are a specific type of aspect, which have been configured to interact with a number of other aspects - Tester, Compiler, DependencyResolver, etc - to run the full life-cycle of a component's creation from a central, shareable place.

Bit's core Envs contain the configurations for the various toolsets that we've identified as covering the vast majority of the market, so we have a react env that utilises Webpack as its Bundler, and Typescript as it's compiler. And the core Envs contain what we consider best-practice configurations for those tools so that the vast majority of use-cases for each tech-stack are covered by our own pre-baked Envs.

In order to for one aspect to change the behaviour of another (via the principle of Inversion of Control) the influenced aspect must provide APIs - called slots in Bit - to allow other aspects to interact with it and customise the aspect's behaviour.

At the moment our envs don't have any slotss to allow customisation via external aspects - and adding them is complicated - so you wouldn't be able to customise an Env's configurations etc via a custom aspect.