Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.0] Make nodes fully immutable by adding API for allowing plugins to add fields #1035

Merged
merged 17 commits into from
May 26, 2017

Conversation

KyleAMathews
Copy link
Contributor

No description provided.

@KyleAMathews
Copy link
Contributor Author

WIP still

@KyleAMathews KyleAMathews changed the title [1.0] Make nodes fully immutable by letting other plugins add fields May 24, 2017
@gatsbybot
Copy link
Collaborator

Deploy preview ready!

Built with commit f9faf17

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

@gatsbybot
Copy link
Collaborator

gatsbybot commented May 24, 2017

Deploy preview ready!

Built with commit a57cbc2

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

@gatsbybot
Copy link
Collaborator

gatsbybot commented May 24, 2017

Deploy preview ready!

Built with commit a57cbc2

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

@gatsbybot
Copy link
Collaborator

gatsbybot commented May 24, 2017

Deploy preview ready!

Built with commit a57cbc2

https://deploy-preview-1035--gatsbyjs.netlify.com

// The plugin which created this node.
pluginOwner: String,
// Stores which plugins created which fields.
fieldPluginOwners: Object,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave out the word plugin in all of these keys to make things more terse. I think the fact that they are created / owned by plugins is not that interesting. Because these fields will be used in users graphql queries I'd keep them as simple as possible without obscuring things.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was more to namespace things as "fields" is a pretty common name nodes might want to use... agree/disagree? And yeah, I dislike how long it is plus it's heavier conceptually which I dislike too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's true that a name clash with fields is a little more likely to occur, but I would still choose a cleaner api over that.

Copy link
Contributor Author

@KyleAMathews KyleAMathews May 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, thinking about it more, fields would be a bit of a weird name within Gatsby for a plugin to use when creating nodes as either you just put data as a top-level field or they should be children nodes.

Another argument for pluginFields however is that people will be confused as to why some data is in top-level fields and other is under fields. pluginFields would make it sorta obvious what the difference is. Though... perhaps not obvious enough to counter the extra length.

Most people doing anything with Gatsby will soon learn the distinction as adding custom fields to nodes is something many people will need to do for anything of medium or higher complexity...

Other thoughts? @jquense @fabien0102 @fk @scottyeck @nicholaswyoung

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also @ivanoats

@@ -26,18 +26,18 @@ describe(`Process JSON nodes correctly`, () => {
node.content = JSON.stringify(data)

const createNode = jest.fn()
const updateNode = jest.fn()
const boundActionCreators = { createNode, updateNode }
const addChildNodeToParentNode = jest.fn()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one already existed, but I can't help to suggest making this one shorter too 🙂 If you add a node to a parent it is obviously a child. So addChildNode or addNodeToParent would have been enough imo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It already existed?

Noted on length. Yeah, I like really explicit APIs. I'll make it addNodeToParent.

// Ensure node isn't directly setting pluginFields.
if (node.pluginFields) {
throw new Error(
`Plugins creating nodes can not set data on the reserved field "pluginFields"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember reading somewhere that common-tags were used. Would be nice to use stripIndent here, so that indentation can follow the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

} else {
if (typeOwners[node.internal.type] !== plugin.name) {
throw new Error(
`The plugin "${plugin.name}" created a node of a type owned by another plugin.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same stripIndent

// the current plugin is the same as the previous.
if (oldNode && oldNode.internal.pluginOwner !== plugin.name) {
throw new Error(
`Nodes can only be updated by their owner. Node ${node.id} is
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another one

const fieldOwner = node.internal.fieldPluginOwners[fieldName]
if (fieldOwner && fieldOwner !== plugin.name) {
throw new Error(
`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You get my point 😉

@KyleAMathews
Copy link
Contributor Author

@KyleAMathews
Copy link
Contributor Author

After sleeping on it, went with removing "plugin" from key names as @0x80 suggested.

Another argument in favor of that is everything in Gatsby happens via plugins so unnecessary to label things as such.

@KyleAMathews
Copy link
Contributor Author

Andddddd we're done!

@KyleAMathews KyleAMathews merged commit 55845c9 into 1.0 May 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants