Giter Site home page Giter Site logo

Comments (4)

kassens avatar kassens commented on May 8, 2024 1

@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.

from relay.

yuzhi avatar yuzhi commented on May 8, 2024

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.

from relay.

coodoo avatar coodoo commented on May 8, 2024

Thanks for the great details!

from relay.

thenikso avatar thenikso commented on May 8, 2024

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?

from relay.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.