Use a WeakMap to store parent of subobjects in nodes

[pieh]

this prevents mutating plugin data that is deeper in object properites
fixes #2772

For context check #2772 and my comment there

[gatsbybot]

Deploy preview ready!

Built with commit 11c2dd3

https://deploy-preview-2812--gatsbygram.netlify.com

[gatsbybot]

Deploy preview ready!

Built with commit 11c2dd3

https://deploy-preview-2812--using-drupal.netlify.com

[jquense]

thanks for the PR! I think the better option to fix this is probably to have createNode not mutate the input in the first place...or whereever the mutation is happening. We don't necessarily want to work around that behavior when it probably isn't intentional in the first place

[pieh]

Updated PR with suggested change.

Previous version of "fix" just in case for reference - pieh@f4e52bd

[jquense]

Sorry! this isn't what I meant. I'd like to avoid a deep clone entirely because it can very expensive, and we have no idea what content or structure nodes will have. Instead I'd like to find the places where mutation is happening and remove them, rather then make mutation safe.

[pieh]

oh, right, I had brain lag or something - now i read your comment again and think to myself how did I understand it the way I did before ...

So if gatsby shouldn't mutate then you would have revert this - 656299d

[KyleAMathews]

Hmmmm yeah we could move that code into a library that then is used in source/transformer plugins that need it.

[jquense]

yeah this is a bit tough, since we sort of need to hope consumers play nice and don't mutate...the problem tho is that enforcing generally it is pretty costly especially here where nodes may be/are complex data structures.

[pieh]

Could you elaborate a little what problem 656299d fixed? Is it needed in all nodes or is just for source/transformers plugins? Maybe I could just change createNode and add argument to opt-out of adding _PARENT fields and just opt-out of it for plugin data? This would avoid any cloning at all (obviously prefered solution).

[KyleAMathews]

See this comment #2567 (comment) It's basically a workaround for GraphQL as it doesn't let you know what the parent of a sub-object is which breaks Gatsby in subtle ways.

Avoiding mutating plugins would be a great start. So yeah, question is should we opt-in to adding _PARENT or opt-out.

I think it's a generally useful/needed pattern which is why I added it to actions.js so I'm leaning towards opt-out. Thoughts?

[jquense]

maybe instead of tagging each sub object we could use a WeakMap hashing objects to parent id? e.g. something like:

map = new WeakMap()

eachChildObject(node, obj => { 
  map.set(obj, node.id)
})

then expose a getParent api perhaps?

[KyleAMathews]

Ooo that's good! Yeah, that sounds much nicer. @pieh you have time to work on this by chance? I'm pretty strapped for time over next few days / week.

[pieh]

updated PR

tested against repository linked in #2567 (comment) to check if "parent fix" still works

[KyleAMathews]

🙇 this is awesome!

[jlengstorf]

Hiya @pieh! 👋

This is definitely late, but on behalf of the entire Gatsby community, I wanted to say thank you for being here.

Gatsby is built by awesome people like you. Let us say “thanks” in two ways:

1. We’d like to send you some Gatsby swag. As a token of our appreciation, you can go to the Gatsby Swag Store and log in with your GitHub account to get a coupon code good for one free piece of swag. (We’ve got t-shirts and hats, plus some socks that are really razzing our berries right now.)
2. If you’re not already part of it, we just invited you to join the Gatsby organization on GitHub. This will add you to our team of maintainers. You’ll receive an email shortly asking you to confirm. By joining the team, you’ll be able to label issues, review pull requests, and merge approved pull requests.

If you have questions, please don’t hesitate to reach out to us: tweet at @gatsbyjs and we’ll come a-runnin’.

Thanks again! 💪💜