fix(toc): prevent misnamed mdx components from breaking TOC

[dannobytes]

	Fix CX-2543

🧰 Changes

Discovered through this ticket
that the TOC generated by the MDX renderer would become broken with
miscalculated nesting depths and exposing h3s or other heading depths that shouldn't be included.

This happened when a jsx element was embedded inside the MDX body and
the custom component name did not match the exported jsx elements.

For example:

I'm not entirely sure whether this is an edge-case we should be guarding
against from inside our custom component editor. Like, adding validation to
ensure that the component name matches what's being exported from it. My
gut tells me it'd be really hard to enforce that.

So, the fix (for now) is to simply take this edge-case into account and add
protections for the cases where this happens.

When a component name doesn't match the jsx element name, it previously
was making its way into the plugin/toc flow. But b/c it has no
tagName, the getDepth() calculation would break and return a NaN
instead of a valid integer. This would break the nesting logic in
toctoHast() and cause all headers to render at the first level.

Fixed this by:

1. filtering away these mismatched components that make it through
2. additionally updating the getDepth() function to be more fail-proof
   and handle the case where tagName is undefined

before	after

🧬 QA & Testing

Tests should pass

• Broken on production.
• Working in this PR app.

[dannobytes]

this is the edge-case that was causing the malformed TOCs in some projects.

when they have custom components that exports a JSX element that differs from the saved file name, this is what happens. the components hash keys are something different than the exported elements.

[dannobytes]

when everything works properly, the subheading should be indented one level like this

[dannobytes]

the exported JSX elements are the nodes (i.e. node.name) and the components is a hash of custom component files. previously, it was matching node.name in components which would be false when the filename didn't match the exported module. otherwise, it'd return the mdxJsxFlowElement node, which would then make its way into the getDepth() function above on L74.

now, if the node type is an mdx jsx element, we'll return an empty array instead, which essentially filters it out completely. i think this is the desired result, but i put in a patch in the getDepth() function just in case something other than a heading element makes it in

[kevinports]

Looks good to me!

[rafegoldberg]

This PR was released!

🚀 Changes included in v11.7.6