Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReactTestRenderer custom depth rendering #7612

Closed
lasekio opened this issue Aug 30, 2016 · 5 comments
Closed

ReactTestRenderer custom depth rendering #7612

lasekio opened this issue Aug 30, 2016 · 5 comments

Comments

@lasekio
Copy link
Contributor

lasekio commented Aug 30, 2016

Do you want to request a feature or report a bug?
Feature

What is the current behavior?

// MyComponent.js
import React from "react";
import ThirdPartyComponent from 'third-party-component';

function MyInternalComponent() {
  return <div>test</div>;
}

export default function MyComponent() {
  return <div>
    <MyInternalComponent></MyInternalComponent>
    <ThirdPartyComponent someProp={true}></ThirdPartyComponent>
  </div>;
}

// test.js
import ReactTestRenderer from "react-test-renderer";
import React from "react";
import MyComponent from "./MyComponent.js";

const renderer = ReactTestRenderer.create(<MyComponent/>);

console.log(renderer.toJSON());

This renders whole tree of DOM which is actually expected behaviour. The problem is, that I dont want render ThirdPartyComponent, only MyInternalComponent. Shallow renderer isnt answer because shallow would not render MyInternalComponent at all. Which is problem because it's hard to divide component into smaller, internal chunks.

I have done some work in order to achieve this in #5513. It was fully working patch. It was done as part of ShallowRenderer but now we have TestRenderer. Besides this patch is pretty old so resolving conflicts would be very hard.

What is the expected behavior?

I would love to provide "blacklist" of components which I don't want to render:

import ThirdPartyComponent from 'third-party-component';
//...

const renderer = ReactTestRenderer.create(
    <MyComponent/>, 
    {
        dontRender: [ThirdPartyComponent]
    }
);

This would return jsx:

<div>
    <div>test</div>
    <ThirdPartyComponent someProp={true}></ThirdPartyComponent>
</div>

So we can test props returned for ThirdPartyComponent and internal logic.

It's combine of full and shallow renderer.

I have some ideas of implementation but i dont want waste my time writing code which won't be marged into master anyway.

This possibly would allow to resolve enzymejs/enzyme#250.

@lasekio lasekio changed the title ReactTestRenderer custom depth render ReactTestRenderer custom depth rendering Aug 30, 2016
@aweary
Copy link
Contributor

aweary commented Aug 30, 2016

This possibly would allow to resolve enzymejs/enzyme#250.

For reference, this change would not affect Enzyme's API as it does not rely on ReactTestRenderer

@ngbrown
Copy link

ngbrown commented Jul 12, 2017

How about using jest.mock() to blacklist imports? There's a pretty good example of it here.

This is the key functionality, in this case, mocking an <Async/> component from the react-select dependency:

jest.mock('react-select', () => {
  const { createElement } = require('react')
  const ReactSelect = require.requireActual('react-select')

  const MockedAsync = props => createElement('Async', props)
  MockedAsync.propTypes = ReactSelect.Async.propTypes
  MockedAsync.defaultProps = ReactSelect.Async.defaultProps
  ReactSelect.Async = MockedAsync

  return ReactSelect
})

It seems like that sort of mocking could be wrapped up into a function and library so it doesn't get too repetitive.

@gaearon
Copy link
Collaborator

gaearon commented Oct 4, 2017

FWIW, jest.mock is how we solve this problem at FB. But I agree a first-class API would be nice.

@stale
Copy link

stale bot commented Jan 10, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
@stale
Copy link

stale bot commented Jan 19, 2020

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

@stale stale bot closed this as completed Jan 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants