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

Remove hydrate() warning about empty container #10345

Merged
merged 3 commits into from
Aug 2, 2017

Conversation

gaearon
Copy link
Collaborator

@gaearon gaearon commented Aug 1, 2017

It used to have false positives for cases where we legitimately don't render anything.
Per #10339 (comment).

It used to have false positives for cases where we legitimately don't render anything.

itRenders('emptyish values', async render => {
let e = await render(0);
expect(e.nodeType).toBe(3);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using Element.TEXT_NODE instead of 3? Is that possible?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Want to send follow up? We actually already have this as a constant in the same file. But literal is used in more than one test.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Existing constant is TEXT_NODE_TYPE.

expect(await render(false)).toBe(null);
expect(await render(true)).toBe(null);
expect(await render(undefined)).toBe(null);
expect(await render([[[false]], undefined])).toBe(null);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just checks a complex component structure of no-render values? Pretty neat that this can just be data.

@nhunzaker
Copy link
Contributor

nhunzaker commented Aug 1, 2017 via email

@gaearon
Copy link
Collaborator Author

gaearon commented Aug 1, 2017

I mean changing existing toBe(3) throughout this suite with toBe(TEXT_NODE_TYPE). Although I don't care strongly if you get it from Element instead.

@nhunzaker
Copy link
Contributor

Ah. I don't mind doing that. Consider it done.

@gaearon
Copy link
Collaborator Author

gaearon commented Aug 1, 2017

There's another follow up here if you're interested. This test file is getting huge. We need to think about how to split it into a separate file for each describe without duplicating the helpers. It may be a bit tricky since we also need to put resetModules in some reusable module, but then how do we get those variables?


// TODO: This one is broken because client renders a node
// but server returns empty HTML.
// expect(await render('')).toBe(null);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some test I've instead tested that parent.textContent === '' since that's what really matters. That there's no significant text content. More resilient to algorithm changes.

You could do:

expect((await render(<div>{''}</div>)).textContent).toBe('');

@gaearon gaearon merged commit 35e3133 into facebook:master Aug 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants