Why there's no "NODE_ADD" type?

[coodoo]

Since there are NODE_DELETE and RANGE_DELETE types, I'm wondering why NODE_ADD is not needed?

Personally I'm guessing that's because when you create a new object, it should always belong to one of the edges, hence RANGE_ADD is good enough, is that correct?

[yuzhi]

Great Question! I think you got the gist of the idea.
The mutation configs we have right now serves two main purposes:

1. Tells us how to handle the different mutation fields
2. Helps us figure out what fields need to be refetched with the mutation based on what we have stored for a particular node so far.
   Reason number 2 is the one I want to focus more on. When a completely new node is added, there is no way for Relay have stored any fields for that new node so far.
   If the new node is going to be a field referenced another node (ex. updating a User’s current_status), we can use that node (the User node in this case) to figure out what fields we’ll need to fetch with the mutation as part of a FIELD_CHANGE mutation config.
   If a new node is going to be referenced from a connection (ex. adding a comment in a connection of comments), we can look at the fields under edges that has been fetched for that connection (comments connection) to figure out the fields we would need for this new node as part of a RANGE_ADD mutation config.
   If the new node is not referenced by another node, it is unlikely for the current view to need any data on the new node. However, we have seen people do a route transition after a new node is created. Even though no fields are needed to update the current view, it’s possible to use REQUIRED_CHILDREN to always fetch any additional fields (like the new node's id) so that it could be used during an onSuccess mutation callback.

[coodoo]

Thanks for the great details!

[thenikso]

I dig this. however I'm wondering how would one go to handle something like a "signup" flow; where the viewer (ie: a query root type) will go from, let's say, an empty object to an actual user.

At this point I'm thinking that a route change or reload would make sense but is there another way? I guess one would want to have something like #233 in the future?

[kassens]

@thenikso Since so many things might change when you log in, we currently recommend just doing a classical page refresh to clear all data. In the future a something like #233 might be useful.