react-testing does not print name of component wrapped in memo correctly

[BPScott]

Overview

I was recently testing some stuff in web when I came across a case where react-testing was not returning the name of a component correctly and was instead falling back to the default of "Component"

 ● <FileInsuranceClaim /> › on save › with errors › displays server error toast and restore submit button if server error occurs

    expect(received).toContainReactComponent(expected)

    Expected the React element:
      <Async(FileInsuranceClaim) />
    To contain component:
      <Component />
    But no matching <Component /> elements were found.

      1438 |         await submit(fileInsuranceClaim);
      1439 | 
    > 1440 |         expect(fileInsuranceClaim).toContainReactComponent(Toast);

I would have expected that to say:

To contain component:
      <Toast />

I believe this is because this Toast component in question is the one from polaris which is a Component wrapped in a React.memo, rather than a plain old functional component.

I suspect this is because the printType utility does not correctly handle finding the name for components that are wrapped in React.memo(). I'd wager components wrapped in React.forwardRef() are also affected in the same way. You should also test components that are do React.memo(React.forwardRef(function SomeComponent() { return 'hi'; }))

facebook/react#17274 from the react repo might be some useful related reading as it fixes up some logic around how names are extracted from these exotic components in the react dev tools.

[BPScott]

@patsissons points out that nodeName() in

quilt/packages/react-testing/src/toReactString.ts

Lines 97 to 112 in 7044ae7

	export function nodeName<Props>({type}: Node<Props>) {
	if (type && typeof type === 'object' && '_context' in type) {
	const context = (type as any)._context;
	return `${context.displayName || 'Context'}.${
	type === context.Provider ? 'Provider' : 'Consumer'
	}`;
	}
	if (type == null) {
	return 'Node';
	}
	return typeof type === 'string'
	? type
	: type.displayName || type.name || 'Component';
	}

is implemented in a very similar way to printType and likely suffers from the same issues. This seems like an opportunity to avoid duplicating functionality between these two very similar functions.

[stale]

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

[BPScott]

Still an issue

[stale]

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