-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Changes from 1 commit
449173e
cdf2539
f9faf17
7cdbda6
b8317cf
62bbd99
d89607f
918003a
8f77c1a
a31d391
54d271b
e883aa1
f44aa4b
9e23038
c847be1
02a8ac3
a57cbc2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
…nd 'addFieldToNode'
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
const boundActionCreators = { createNode, addChildNodeToParentNode } | ||
|
||
await onNodeCreate({ | ||
node, | ||
loadNodeContent, | ||
boundActionCreators, | ||
}).then(() => { | ||
expect(createNode.mock.calls).toMatchSnapshot() | ||
expect(updateNode.mock.calls).toMatchSnapshot() | ||
expect(addChildNodeToParentNode.mock.calls).toMatchSnapshot() | ||
expect(createNode).toHaveBeenCalledTimes(2) | ||
expect(updateNode).toHaveBeenCalledTimes(1) | ||
expect(addChildNodeToParentNode).toHaveBeenCalledTimes(1) | ||
}) | ||
}) | ||
|
||
|
@@ -49,8 +49,8 @@ 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() | ||
const boundActionCreators = { createNode, addChildNodeToParentNode } | ||
|
||
await onNodeCreate({ | ||
node, | ||
|
@@ -71,8 +71,8 @@ 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() | ||
const boundActionCreators = { createNode, addChildNodeToParentNode } | ||
|
||
await onNodeCreate({ | ||
node, | ||
|
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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 underfields
.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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also @ivanoats