Graphiql: react hot loader incompatible with children customizations

[EliseJane]

This is what react-hot-loader has to say about this issue:

We know this problem, but could not do anything to solve it. At least today.
The only proper way to write your code is to compare the same things:

node.type === .type

Could you update GraphiQL in this way so that I can customize the toolbar, etc.?

[nicosuave]

I was able to resolve this by changing the child checks from child.type -> child.type.displayName and replacing the compared value with the stringified version (less the dot).

Feels kind of wrong to change for react-hot-loader (so no PR from me), just an FYI.

[joshmadewell]

@acao Is there any movement or recommended workaround on this? Willing to open a PR if there's a suggested fix.

[acao]

yikes! good question. i will have to look into this soon. we are about to change the react implementation significantly, so we can likely revisit this in the process

[acao]

@nicosuave that sounds like a fine workaround. it seems it would be a more resilient solution to the problem that code originally aimed to solve, if im not mistaken. its possible it could ameliorate more issues than react hot loader. also we have a TON of users who use bundlers, likely also needing HMR, because our niche is customizeability.

[joshmadewell]

I've been digging into cold functionality https://github.com/gaearon/react-hot-loader/issues/938 which is exposed by react-hot-loader but unfortunately, mixing this with a deferred loading of the GraphiQL component isn't playing nicely making it seem like we the only real course of action for us is to work around this inside graphiql.

I wonder if a PR checking for either a strict type comparison OR a displayName comparison would be suitable?

Also worth noting, to use the cold functionality, you need to do cold(GraphiQL.Logo). Just calling cold on the default export won't be enough :(

[acao]

ok just took a peek and i see which offending code to which you are referring.
yes we plan on deprecating this interface in 1.0.0 as well, however there will be an interface for plugins that will provide a similar capability considering using the jsx pragma

in the meantime @joshmadewell if you want to submit a PR as you describe that would be awesome, actually i think all components 15.x+ should have type.displayName, right? maybe write some tests to confirm that with RFCs and functional components in react 15, and if it breaks add the fallback for type == type?