These versions will need to be updated depending on when/if this makes it in.

Let's remove version numbers entirely; there's no need to specify it here.

Let's remove version numbers entirely; there's no need to specify it here.

mount itself has no direct tie to React; it should be able to work as long as the adapter supports it (which might not be react at all)

Sounds good. Is there any prior art for what to do in a case where an adapter does not support a feature? For example, I'm assuming we'll never want to add support for this API to adapters that handle react@<16.3.

cloning elements is very slow and should be avoided. why is it needed here?

The goal is to convert the provider elements the user passes into a tree:

So this:

mount(<MyComponent />, {
  providers: [
    <ContextA.Provider value="A" />,
    <ContextB.Provider value="B" />,
    <ContextC.Provider value="C" />,
  ],
});

Is rendered as:

<ContextA.Provider value="A">
  <ContextB.Provider value="B">
    <ContextC.Provider value="C">
      <MyComponent />
    </ContextC.Provider>
  </ContextB.Provider>
</ContextA.Provider>

And I figured cloneElement() was the most idiomatic way to do this. I'm also working under the assumption that mutating the providers the user passes in would be a bad idea. Would a more manual

// not sure if this will actually work
{
  ...parentElement,
  props: {
    ...parentElement.props,
    children: childElement,
  },
}

be preferable, or is it the copying itself that is too slow to be acceptable?

this API means there's never any way to remove a provider, only to replace existing ones or add new ones.

Separately, providers being an array implies that the order matters - why and how? If it matters because it's nested into a tree, then it seems much simpler to only ever allow a single provider element, and come up with an alternative solution that lets the user determine their own nesting yet also indicate where children should be rendered.

I think you can effectively remove a provider by doing

wrapper.setProviders([<Context.Provider value={undefined} />]);

As for order mattering, it doesn't. I used an array because objects can only have strings as keys and it seemed wrong to require configuration options that do not have a literal syntax (like Set or Map.) I wrote a bit about my thought process when coming up with the API in the PR description.)

But I'm open to an entirely different API if you have some ideas. 😊

I'm a bit confused why multiple providers are needed, since you can do:

<Provider1>
  <Provider2 />
</Provider1>

and provide a single provider

Ah got it! I was a bit confused by what you meant by "a single provider". I was thinking about the new context API in terms of individual values (as is the case with the old API), but perhaps that was me trying to make the new API into something that it is not.

The way you compose multiple contexts in the new React API is by nesting components—perhaps the enzyme API should reflect that, as you've pointed out! So, what do you think about this:

mount(<MyComponent />, {
  providers: (
    <ContextA.Provider value="A">
      <ContextB.Provider value="B">
        <ContextC.Provider value="C" />
      </ContextB.Provider>
    </ContextA.Provier>
  ),
});

And then changing via context by

wrapper.setProviders(
  <ContextA.Provider value="A">
    <ContextB.Provider value="foo">
      <ContextC.Provider value="C" />
    </ContextB.Provider>
  </ContextA.Provier>
);

My only concern is that this API makes it a bit challenging to change just a single provider's value without having to re-specify the entire tree. I think it will be common to be dealing with a bunch of different contexts from different libraries, all of which are required for a component to render. But each individual spec will deal with the how the component responds to just one of those contexts changing. So, what do you think about (in addition to the .setProviders() API) having an API like this:

wrapper.updateProvider(<ContextB.Provider value="foo" />);

Which would update just that provider, wherever it is in the tree, and throw an error if the provider is not already in the tree.

Also, I don't feel strongly about any of these names if you'd like them to be different. I am leaning towards keeping the plural "providers" because I think it makes it a bit more clear that the element can have many nested providers, though I do realize you are only passing a single react element.

Re-specifying the entire tree is already the case if you want to change a child of the element you wrapped, for example - i'm also not clear on the use case of changing providers after initially wrapping.

Maybe instead of this feature being specific to createContext providers, it could be more general - something like, "wrapWith". A single render prop function that gets passed a child, and wraps it as needed.

Example:

const wrapper = mount(<Foo />, {
  wrapWith(root) {
    return (
      <ContextA.Provider value="A">
        <ContextB.Provider value="foo">
          <ContextC.Provider value="C">
            {root}
          </ContextC.Provider>
        </ContextB.Provider>
      </ContextA.Provider>
    );
  },
});

The API could throw if your wrapWith function failed to render the child (solo, ie, with no siblings), and then wrapper in this case would be <Foo />, not any of the providers, but they'd still be exercised in the rendering path.

I think the use-case is something like this:

Imagine you have a react-flag-like library and some future version of react-redux that uses the new context API. You'd render your component like this (using the wrapWith API):

// my app's feature flags
const flags = {
  foo: false,
  bar: false,
};

const wrapper = mount(<Foo />, {
  wrapWith: root => (
    <FlagProvider value={flags}>
      <ReduxProvider value={store}>{root}</ReduxProvider>
    </FlagProvider>
  ),
});

And now we want to test that some side-effect in <Foo />'s componentDidUpdate gets called when the feature flag changes. We need some way of changing <FlagProvider />'s value, and it would be nice if we didn't have to re-setup the <ReduxProvider /> when we do that.

Also, if our component starts depending on a new provider in the future, it'd be really nice to only have to add it to the options we pass enzyme, and not every place where we're just changing a single provider's value.

I'm guessing the API for changing the wrapWith function could be something like

wrapper.setWrapWith(root => (
  <FlagProvider value={{ ...flags, bar: true }}>
    <ReduxProvider value={store}>{root}</ReduxProvider>
  </FlagProvider>
));

But that doesn't address my concern about having to respecify the entire tree. One solution that comes to mind (just spitballing here) is making wrapWith a component:

const wrapper = mount(<Foo />, {
  wrapper: {
    component: (props) => {
      const { flags, store, children } = props;

      return (
        <FlagProvider value={{ ...flags, bar: true }}>
          <ReduxProvider value={store}>{children}</ReduxProvider>
        </FlagProvider>
      );
    },
    props: { store: createStore, flags },
  },
});

And then having an API that lets you set the wrapper component's props:

wrapper.setWrapperProps({
  flags: {
    ...flags,
    foo: true,
  },
});

(wrapWith seemed like a better name for a function than a component so I changed it to just wrapper; but it also seems a bit confusing because wrapper is the conventional name for a ReactWrapper instance.)

(We can bikeshed the names later)

OK, so you're suggesting the user be able to provide a "wrapping component", and provide explicit setProps/setState access on it - what about instead, wrapper.getWrappingComponent(), that returned a normal enzyme wrapper around that component - providing you with the same APIs?

I like that idea a lot! I'll implement and then drop you a comment here so we can discuss. I really appreciate the time you've taken to work through this with me. Thank you!

We need a reliable way to get the node that was passed as the first argument to mount() and this seemed like the simplest way. Is it acceptable? Are there going to be performance implications of using a ref?

we should avoid using ref, yes.

There's no reason this feature couldn't work in react 13, but the tests don't because react 13 uses owner-based context instead of parent-based. Is it worth coming up with a different test methodology for react 0.13, or are we okay with not supporting this feature in the 0.13 adapter? (I'm not sure how useful this feature is without parent-based context.)

ideally we'll solve it for react 13 as well; it's probably OK if we defer for now as long as we're confident this enzyme API won't need to change to support it.

UNRENDERED needs to be set to call .setProps() on the wrappingComponent. It didn't seem like there was any harm in setting it to nodes regardless of !root. (All the tests still passed.)

This is a bit hacky. Is it acceptable? We don't want this new ReactWrapper to render itself, but we do want it to be a root (so we can .setProps() on it.)

We could also decide to not support .setProps() and make it a non-root. In that case, we could just get by using .setState() to change the context.