Add support for passing context

[laurakelly]

I have a component in my app that has a router passed to it via context:

const contextTypes = { router: React.PropTypes.func.isRequired, };

Reagent tests currently do not support passing in a context and will throw this error:

Error: expected zero console.warn calls, got 1:
      warn(Warning: Failed Context Types: Required context `router` was not specified in `MyComponent`.) at warning (node_modules/react/lib/warning.js:48:15)
    at Context.<anonymous> (spec/javascripts/_failTestsOnErrors.js:21:23)

It would be great to be able to pass context into shallow.

[lelandrichardson]

I think this would be a great addition! The only remaining question is what the right API is.

I propose that we add a second argument to mount, shallow, and render which is simply an object named options in order to be most flexible with future changes.

options could have a context property that, if defined, would be passed in as context to the parent component.

const context = { router: mockReactRouter() };
const wrapper = shallow(<MyComponent />, { context });
// ...

cc @ljharb @goatslacker thoughts?

[blainekasten]

That is the same API, TestUtils.shallowRenderer().render uses. So I would second that and stay consist when possible. 👍

[lelandrichardson]

@blainekasten to be clear, I'm recommending that on object hash with a context prop be passed in as a second argument to shallow and the like, NOT that the context object itself be the second argument. The latter, I believe, is the current API for the shallowRenderer

[blainekasten]

My bad. Why that approach? What other keys would be used and why?
On Sun, Dec 6, 2015 at 3:04 PM Leland Richardson notifications@github.com
wrote:

@blainekasten https://github.com/blainekasten to be clear, I'm
recommending that on object hash with a context prop be passed in as a
second argument to shallow and the like, NOT that the context object
itself be the second argument. The latter, I believe, is the current API
for the shallowRenderer

—
Reply to this email directly or view it on GitHub
#49 (comment).

[lelandrichardson]

My thinking is that it allows other "options" be passed in as well in the future, rather than just having a bunch of arguments at random slots of the function signature.

One such thing we discussed internally was the ability to have an option for mount which indicated the node it mounts onto actually be attached to the document body:

const wrapper = mount(<Foo />, { attach: true });

Which could come in handy if you're wanting to test a component that uses DOM api's such as elem.getBoundingClientRect(); that require the DOM nodes be attached to a document.

[lelandrichardson]

@laurakelly context support is now available on enzyme v1.2.0

[laurakelly]

@lelandrichardson Great, thank you! I'll try it out

[havenchyk]

@lelandrichardson well, it looks like {attach: true} doesn't work for me with getBoundingClientRect

[bscherminator]

@lelandrichardson How does one mock getBoundingClientRect using the options?

[lelandrichardson]

@bscherminator what environment are you using getBoundingClientRect in?

getBoundingClientRect will always return a zero'd out rectangle if you're using jsdom. This will only work in something like karma with a browser runner