.key() isn't consistent with unwrapped element .key

[noinkling]

Current behavior

If a key is not specified on an element, Enzyme returns undefined from .key()

Expected behavior

I would expect .key() to return null the same as React does for .key on an (unwrapped) element.

Contrived example: https://codesandbox.io/s/xpj8pvpj2o

My use case is that I'm writing a test for a library that ensures that an element generated from a shorthand prop (on a parent) matches a specific factory-generated counterpart. Part of this process involves the optional generation of a key, so I need to check that the keys match (which isn't covered by .contains() or similar).

As you can see from the example, the assertion works fine when a key is provided/expected, but breaks when it isn't. There are easy workarounds:

• Use .get() to retrieve the unwrapped element
• Compare with loose equality
• Wrap the other element

...but I thought I'd bring it up anyway.

Your environment

API

• shallow
• mount
• render

Version

library	version
Enzyme	3.3.0
React	16.0.0

Adapter

• enzyme-adapter-react-16
• enzyme-adapter-react-15
• enzyme-adapter-react-15.4
• enzyme-adapter-react-14
• enzyme-adapter-react-13
• enzyme-adapter-react-helper
• others ( )

[noinkling]

I suspect this might be related to #1240 / #1254

[ljharb]

It seems like this could be addressed by changing all the || undefineds to || null, but then that might retrigger #1240.

If you'd like to write a PR that attempts to fix this (especially if it maintains consistency across the adapter versions), I'd love to review it.

[bdwain]

Can't the fix just be isolated to the key() method on the wrapper? If the internal value is undefined, it can return null, otherwise it can return the internal value (which should be a string) anyway.

[ljharb]

@bdwain that seems like it might work. Want to try out a PR?

[bdwain]

yea i can do it.

[bdwain]

made #1536