[WIP] Optimistic UI

[davidwoody]

TODO:

• Use merge instead of assign to combine optimistic data
• Optimistic reducer should use the exact same logic for data as a real mutation result
• Update CHANGELOG.md with your change
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass
• Make sure all of the significant new logic is covered by tests

closes #287

[abhiaiyer91]

How does Optimistic Data get reset or trashed? I might have missed that in the PR?

[stubailo]

We should also make sure that the optimistic result is applied using the merged real and optimistic data, so that you can apply multiple optimistic updates on top of each other.

[abhiaiyer91]

Bump on my question @davidwoody

[abhiaiyer91]

What is the lifecycle of optimistic state?

[davidwoody]

Does the logic in the optimistic reducer make sense to you? Basically on init it simulates the result action and on the last result action it throws away the optimistic cache. It waits until the last outstanding result action to avoid the flickering issue I was explaining in Slack the other day.

[davidwoody]

I wasn't sure how best to "throw away" the one optimistic result after the server result became available if there was still another optimistic result applied to the cache and waiting for the server responses. So I just wait to throw away the optimistic results until all outstanding sever mutations resolve.

[stubailo]

So I just wait to throw away the optimistic results until all outstanding sever mutations resolve.

This seems like a good approach for now.

[stubailo]

Hey, heads up @davidwoody I rebased on master and force pushed

[davidwoody]

@stubailo Got it. Also, it looks like the travis builds are failing because the gzipped size of index.min.js exceeds 34kb... I'm guessing we can just increase that from 34kb to 36kb?

https://travis-ci.org/apollostack/apollo-client/jobs/141736810#L1343

[Slava]

Plan for new tests for this functionality:

• reuse the mutations tests structure for different types, that the result is optimistically reflected synchronously:
  • correctly integrates a basic object at the end
  • deletes object from array and store
  • runs the custom reducer
  • deletes an object from array but not store
• test error handling
  • one optimistic update in a stack
  • multiple in a stack, one fails (in the beginning or middle)
• two mutations running concurrently and returning in some order. every intermediate state is validated

[Slava]

Added some tests that demonstrate the problem of not passing the previous data state (with optimistic updates so far).

[Slava]

Completed the test suite planned by me and @stubailo awhile ago.

[stubailo]

This is not in the right location, should be moved to the top.

[stubailo]

Can we add a test that makes sure that the optimistic patch is small, and doesn't include objects that weren't changed? That seems like one thing that would be easy to break in future changes.

[Slava]

Yay we merged! Thanks @davidwoody for the good work on this feature.

[davidwoody]

Woo hoo! Thanks @Slava for the great suggestions and work on all the tests!

[stubailo]

Great work everyone!

[twelvearrays]

This is very exciting! Are there any examples available of using optimisticResponse with a client mutation?

This end of this post helped!
#398

[Slava]

@twelvearrays we are still in the process of designing a good API and ironing out the details of what is required to be passed and what is not. Once that's done better docs should come along!

[twelvearrays]

@Slava Thanks! Looking forward to it. Keep up the great work.

[leebenson]

Awesome work. A couple of Qs:

1. What's the usage for optimisticResponse on a mutation that has fragments?

I have a mutation in this format:

mutation destroySession {
  destroySession {
    ...Session
    ...Errors
  }
}

...Session has an id field I want to update.

This is the only format that doesn't generate an error:

const destroySessionMutation = {
  mutation: destroySessionMutationGQL,
  fragments: sessionFragment,
  refetchQueries: [
    'getSession',
  ],
  optimisticResponse: {
    destroySession: {
      id: null, // <--- this is on `Session` - but that's only relevant when a `Session` is returned
    },
  },
};

How would I design optimisticResponse if multiple types returned an id, for example?

2. What's the optimisticResponse way to update a ObservableQuery subscription?

I'm using Apollo alongside MobX, and using observable queries to update global MobX stores.

A typical MobX store function that connects with Apollo looks like this:

getSession = () => {
  if (this.getSessionWatched) {
    return this.getSessionWatched.refetch();
  }

  this.getSessionWatched = this.client().watchQuery({ ...sessionQuery });

  return new Promise(resolve => {
    this.getSessionWatched.subscribe({
      next: res => {
        resolve(res);
        this.data.set('session.id', (res.data.session && res.data.session.id) || null);
      },
    });
  });
}

I expected watched queries would update in the interim whilst returning data, but it doesn't seem to invoke the subscription.

What's the best way to connect the two?

Thanks in advance.

[helfer]

1. The optimistic response should basically be what you expect the server to return if everything works out as expected. That also means you have to predict what fragments will apply. It could be that there's a bug in the logic that checks that the shape of the optimisticResponse fits the query, but then that would probably throw an error on the actual response as well.
   (If I understand correctly, you're saying that using an optimisticResponse that matches the Error fragment doesn't work? If so, that might be a bug.)
2. optimistic updates should affect all queries, and their subscriptions should trigger if the optimistic update affected their data. If that's not the case here, it could be a bug, or it could be that it's not actually mapped to the same place in the store. It would be great to have a minimal reproduction or a failing test case to figure out what exactly is happening.

[leebenson]

Thanks @helfer. I'll try to reproduce with a minimal test, and post the results here.