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

[bradwestfall]

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>

[bradwestfall]

If I add some console logs like this:

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

Notice the output suggests they are the same "component", but again the truthiness is false leading to the "not same" output

[KyleAMathews]

Ah, think I figured it out

gatsby/packages/gatsby/cache-dir/production-app.js

Line 163 in 125faad

...props,

We're cloning the children prop.

[KyleAMathews]

We should probably just pass it in directly then yeah?

[bradwestfall]

@KyleAMathews I don't fully understand the context of the code you showed, but do you mean something like this to preserve children?:

return createElement(ComponentRenderer, {
  page: true,
  ...props,
  children: props.children
})

[KyleAMathews]

Yeah exactly. When you have a chance, could you test that to make sure it works and then PR the change?

[bradwestfall]

@KyleAMathews I followed all the steps to use gatsby-dev-cli, and I'm fairly certain it's working -- when I make changes to my cloned repo in that file, I can see the same file in my site get the change, I have the watch running etc. However, when I do a refresh on the site I don't see changes. I tried doing this console log to prove this function was every running:

render: routeProps => {
  attachToHistory(routeProps.history)
  const props = layoutProps ? layoutProps : routeProps

  console.log('here')

  if (loader.getPage(props.location.pathname)) {
    return createElement(ComponentRenderer, {
      page: true,
      ...props
    })
  } else {
    return createElement(ComponentRenderer, {
      page: true,
      location: { pathname: `/404.html` },
    })
  }
}

...and I didn't get a log in dev tools. Also made the props change because I'm not sure if this is a SSR method, but that didn't work. I'm sure I'm doing something wrong here with dev work in Gatsby, but this is a needle in a haystack situation for me since I'm pretty unfamiliar with Gatsby setup. Any pointers?

[KyleAMathews]

Yeah, making changes to production-app.js is a bit tricky as it's only used for "production" e.g. when you run gatsby build. root.js and app.js are used during development. Try building your site and then see if your logs show up.

[bradwestfall]

@KyleAMathews we're making progress, made a production build then cd 'd to public and ran http-server to run it, I get the console log, and the problem with <Foo><Bar /></Foo> is fixed - it outputs "bar: world" instead of "not same". So that's great, but I didn't have to change anything to get it to work, so there's a discrepancy between dev and production. Just for the heck of it, I changed this line of root.js for dev:

              if (pageResources && pageResources.component) {
                return createElement(ComponentRenderer, {
                  key: `normal-page`,
                  page: true,
                  ...props,
                  children: props.children,
                  pageResources,
                })
              } else {

... to include the children: props.children idea, and it didn't work for dev mode

[KyleAMathews]

Awesome!

That's surprising the same change didn't work in dev. Double check your change is being applied? The children component must be being cloned elsewhere still.

[bradwestfall]

I probably didnt say the last message clear enough, the only thing I did in production was the console log. So production always works without any changes but development doesn't work

[KyleAMathews]

Oh ok, gotcha. So mystery is still unsolved

[bradwestfall]

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

[scottyeck]

FWIW, we can confirm @bradwestfall 's observation that this behavior currently only affects the local gatsby develop environment. We're going to do some digging. If anybody's got thoughts on a path forward, we'd love to hear. 😎

[bradwestfall]

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

[scottyeck]

I'm also not able to spend the time on this that I wanted to unfortunately. For anyone who's interested, I set up @bradwestfall 's test case in an example repo here: https://github.com/fabrictech/gatsby/tree/example-check-types/examples/check-types