user1600124
user1600124

Reputation: 440

when to use globalIdField

As far as I can tell, relay relies on nodeDefitions for queries when variables are being changed.

It'd appear that all objects with an id field should be a valid node. However, if I have data like this:

type User {
  id: globalIdField('User'),
  name: String,
  folders: [ Folder ]
}
type Folder {
  id: ???,
  ...
}

The data is stored in a document based solution, and the Folder objects are nested in the User object. But Folder objects are given an id so that some other objects could reference the Folder objects under the context of a User.

If Folder implements the nodeInterface, and uses globalIdField, then I need to figure out a way to fetch the Folder object from a globalId, meaning that I might have to scan through all the Users to find it, have a data map that'd allow me to find the object, or normalize the data so that Folders are in their own table. If it doesn't implement the nodeInterface, and just uses Strings as id field, what happens when I try to mutate some fields on the Folder object?

Upvotes: 2

Views: 1193

Answers (1)

kassens
kassens

Reputation: 4475

It's often useful for these objects to have ids, even if there's no real id directly in your database. For example, if you want to write a mutation to rename a folder, it'd be great to have a global ID to reference this folder. Relay also uses them internally when the UI requests some additional data on a node that's not loaded yet.

One way to generate a global ID for the folder could be to take a prefix and add the user id and a way to identify the folder within the user, for example:

var folderID = ['folder', userID, folderID].join(':');

Whenever you want to resolve this id on your server, you split at the :, see that you want to load a folder by looking at the first part and then go via user to the right folder.

Upvotes: 2

Related Questions