Should node id's be unique and meaningless?
See original GitHub issueSummary
I’m writing a source plugin where I download JSON from an API and create nodes - all pretty standard. Objects I receive have an a field called topicId
with is a guid (uuid) that represents the main id of the item.
Now I could use this field directly as the node id in Gatsby like this:
createNode({
id: item.topicId
})
However, the createNodeId
function exists (to create guid ids) so it seems like I should use it, and store the topicid
as its own field, like this:
const { topicId } = item;
createNode({
id: createNodeId(topicId),
topicId
})
So the question is, should id’s be unique and meaningless? And therefore which approach above is favourable?
One of the benefits of createNodeId
is that it ‘will generate different IDs for different plugins if they use same input’. In my particular case, this is irrelevant because I’ve already got a guid, so I could probably safely just use it directly.
Relevant information
This comment suggests that node ids should be unique and meaningless, so people don’t rely on them for anything, which makes sense.
However, I couldn’t find anything about this in the docs either in node creation or createNodeId. In fact, several of the examples in the docs actually don’t use createNodeId
and use predictable ids directly.
I’d be happy to contribute to the docs if anyone thinks this needs adding/clarifying.
Environment (if relevant)
N/A
File contents (if changed)
gatsby-config.js
: N/A
package.json
: N/A
gatsby-node.js
: N/A
gatsby-browser.js
: N/A
gatsby-ssr.js
: N/A
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:7 (4 by maintainers)
Top GitHub Comments
id
s should be unique - we have dictionary of nodes byid
so if two nodes share sameid
- then it would just mean that one overwrites the other. Note that the this is in global scope, so even if nodes have different types - they still can’t use sameid
https://github.com/gatsbyjs/gatsby/issues/22004 is example of issues when
id
s are not unique (in this case those have different types but sameid
).The “meaningless” part is somewhat related to uniqueness - it’s not strict requirement, but it is good practice - when users would want to query by
id
(and not by something liketopicId
) it just increases chance of colissions, because you need to factor in that nodes that you create in your plugin or site are just parts of all the nodes that exist in data layer - other plugins share the sameid
pool. So best way to go about it is to makeid
meaningless (so users don’t use this) and have meaningful identifiers as some other field (topicId
).It does sound like the documentation adjustments is good idea, but there is always nuance. Sometimes we don’t want to go on tangential problem when explaining some particular concept. So we might need to evaluate this for each documentation page separately - do you have examples in mind?
Hey again!
It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it. Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m
HUMAN_EMOTION_SORRY
. Please feel free to reopen this issue or create a new one if you need anything else. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!Thanks again for being part of the Gatsby community! 💪💜