gatsby: Comparing a component's "type" to the component is not producing expected result

Description

I have a few components that rely on React.Children.map to eventually compare child.type to the expected child component. This code works fine in all my React projects that use ordinary react (like Create React App), but doesn’t work in Gatsby or NextJS (perhaps something to do with SSR) All my code is on the same version of React and Node (listed below)

Here is a basic example of a “compound components” pattern where <Foo> expects <Bar> as it’s child. In my CRA apps I get “Bar: world” as the end result (which is correct), but with Gatsby I get “not same” which shows a difference in how the two environments evaluate this code child.type === Bar

const Foo = (props) => {
  const newChildren = React.Children.map(props.children, child => {
    return child.type === Bar
      ? React.cloneElement(child, { hello: 'world' })
      : <div>not same</div>
  })
  return <div>{newChildren}</div>
}

const Bar = (props) => (
  <div>bar: {props.hello}</div>
)

const App = () => (
  <Foo><Bar /></Foo>
)

In a quick twitter chat with gatsby, I was asked if refreshing made a difference, it does not

Environment

Gatsby version: 1.1.28 Node.js version: 8.2.1 Operating System: macOS High Siera

Actual result

child.type is not === to what it should be equal to

Expected behavior

It should be equal

Steps to reproduce

Copy the above demo code and implement with <Foo><Bar /></Foo>

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 24 (14 by maintainers)

Most upvoted comments

@scottyeck that looks great. A little utility lib + a docs page explaining what the heck is going on that we can direct people to should suffice for now.

Glad it’s sorta working now! 😃

KyleAMathews on Feb 8, 2018

@scottyeck @KyleAMathews As I’m reading through that thread, I saw that one option is to do child.type === <Bar />.type instead of child.type === Bar. Turns out that is also mentioned in their v3 docs. For v4, they plan on providing a helper function instead

I guess this is complex and I see why that might be their best solution, but it’s a little funky for me because my app doesn’t depend on react-hot-loader directly for the helper function. So I tried child.type === <Bar />.type and it works for me now in Gatsby.

Although I hope you can still get some sort of Babel plugin to work so users of Gatsby don’t have to know all this 😉

bradwestfall on Feb 8, 2018

Ahh looks like react-hot-loader https://github.com/gaearon/react-hot-loader/issues/304

KyleAMathews on Feb 8, 2018

I’m really sorry I’ve been absent from this thread, I still really want to get this solved but I got pulled away on other projects. But bottom line is that I can’t use Gatsby at the moment with some important components I have because of this. I hope to look at it again soon but I’m very unfamiliar with Gatsby internals so it’s hard to know where to start

if this helps, I get the same problem with NextJS. So there must be some common trait with these SSR tools, if that gives you any clues. I’ve never done anything SSR related except for using Next and Gatsby, and also never had this problem before with components that compare types

bradwestfall on Feb 7, 2018

I just haven’t had time to keep looking at this yet, but I will soon I hope

bradwestfall on Jan 29, 2018