Render JSX in t.snapshot arguments

[vadimdemedes]

See #1154 (comment). During the development of magic-assert PR, we decided to extract t.jsxEqual from it and land it bit later with a more clear purpose.

I do have one idea for these, but not sure if that can be implemented to be stable enough. We (or community) could write a babel plugin for react/preact/inferno, which detects t.jsxEqual and convert:

t.jsxEqual(<This/>, <That/>);

into:

t.jsxEqual(renderer.create(<This/>).toJSON(), renderer.create(<That/>).toJSON());

to save the user from typing that manually or creating shortcuts (as mentioned in #1175).

---

Also related #1175

[novemberborn]

I wonder if we could advocate JSX transforms that just do this for deepEqual. Was there any specific behavior in jsxEqual?

[vadimdemedes]

Nope, there wasn't any specific behavior inside t.jsxEqual. I just thought it may be easier for 3rd-party transforms to detect what needs to be transformed, if we had t.jsxEqual.

[jfmengels]

Jut so I'm sure I understand: Why do we wish to have a new jsxEqual assertion method? Is it because doing

t.deepEqual(<This/>, <That/>);

creates an unreadable object that does not look like what you expect to see in the DOM?

[novemberborn]

I think this comes down to #1175. We can't do a generic jsxEqual because we need to render the JSX somehow, which means choosing a particular implementation (e.g. React). The solution for that was to encourage Babel plugins that would translate the JSX for use with the assertion. But I'm not convinced those plugins need to latch onto t.jsqEqual calls. They can just detect the JSX AST nodes.

[vadimdemedes]

@jfmengels I thought to add it, just to clearly indicate for 3rd-party babel plugins what JSX needs to be transformed.

@novemberborn Actually, this issue can be closed, since goal is to not have restrictive preferences and be open & universal to all JSX-based libraries. I should create a new issue describing my thoughts and a possible route we can take.

But I'm not convinced those plugins need to latch onto t.jsqEqual calls. They can just detect the JSX AST nodes.

I don't have experience in that area, so I can't argue with this. If it's just easy as detecting t.jsxEqual, I'm fine with having just t.deepEqual.

One thought: would this confuse users who'd use t.is with JSX too?

[novemberborn]

Detecting JSX nodes is pretty easy, yeah.

One thought: would this confuse users who'd use t.is with JSX too?

You can't use that to compare objects though, can you?

[vadimdemedes]

Nope, but I'm wondering if users will assume t.is is for shallow compare (JSX) and t.deepEqual for deep JSX.

[novemberborn]

That confusion doesn't seem exclusive to JSX object comparisons.

[vadimdemedes]

Yes, also true.

[vadimdemedes]

New developments on this issue. It's now centered around t.snapshot() instead of testing equality of JSX. The idea is to have separate and optional babel plugins, which would transform t.snapshot(<Hello/>) into t.snapshot(reactTestRenderer.create(<Hello/>).toJSON()). Those plugins would only be responsible for injecting the renderer and placing JSX into reactTestRender.create(JSX).toJSON() code and putting it inside t.snapshot() args.

Renderers:

• react-test-renderer for React
• preact-render-to-json for Preact

User should be free to choose any test renderer they desire, but in case we already have a babel plugin for it, they can just go with that.

[novemberborn]

We'd be happy to promote plugins written for this purpose, but this isn't something that AVA needs to support by itself.