Optimistic updates

[acdlite]

Opening this issue to track discuss whether FSA should address optimistic updates. If it does, I think it should be as an extension of the core spec.

[tappleby]

I dont think the spec should specifically address optimistic updates but being able to express a sequence of actions would allow for someone to implement optimistic updates.

Actions:

[
  { type: 'SAVE_FOO', payload: { fooId: 42, name: 'Foo' }, meta: { id: 'abc1', sequence: 'begin' } },
  { type: 'SAVE_FOO', payload: { fooId: 42, name: 'Foo' }, meta: { id: 'abc1', sequence: 'complete' } },
]

Store or Reducer:

if (action.type == 'SAVE_FOO') {
  switch (action.meta.sequence) {
    case 'begin':
      // Store pending value using action.payload.fooId
      // Possibly keep track of request using action.meta.id
      break;
    case 'complete':
      if (isError(action)) {
        // Remove pending value, store error letting user know what occurred.
      } else {
        // Remove and merge pending value.
      }
      break;
  }
}

A user may want a sequence of more then 2 actions, if we borrow slightly from Observable terminology I could see the following values for sequence: begin|next|complete. An optional sequenceOrder could be useful as well.

Not sure if this causes any issues but for an action creator that performs some client side validation it might be possible for a complete sequence to be fired without having a matching begin.

[acdlite]

I like the sequence idea. Here's how I'd implement it:

{
  type,
  payload,
  meta,
  sequence: {
    type: 'start', // or 'next', or 'return'
    id: 123 // same for every action in the sequence
  }
}

I'm going to try this out in redux-promise and redux-actions to see how well it works.

[clearjs]

@acdlite It might be useful to have some sequentially increasing number for sequence ordering information. E.g., if progress of 67% arrives after 70%, it would be possible to ignore it.

EDIT: that would be more relevant for Rx, or wherever we need sequence.type === 'next', not for optimistic updates.

[tappleby]

@acdlite I like the top level sequence as an object, not a huge fan of return, would prefer end or complete.

@clearjs the sequence order would be useful, I could see it living in meta or sequence. Do you think this is something the spec needs to define?

[clearjs]

@tappleby It depends. Perhaps, after more use cases are addressed this will be clear.

Generally speaking, the concept of sequence implies ordering. My point was to bring this into discussion, not to suggest any specifics.

If I had to make a decision, I'd introduce ordering information and make it a field of sequence.

[cesarandreu]

This sounds like a great idea.

With respect to ordering information, I think picking something and sticking with it would keep people from falling into the bikeshedding trap, so I think it'd be good to include in the sequence field.

Now for a little bikeshedding, why not use done to signal that it finished? Then it would match Iterators. Taking it one step further, why not try to match iterators more closely?

{
  type: 'FOO',
  payload: { foo: true }
  sequence: {
    id: 123,
    done: false,
    value: 'start'
  }
}

[valscion]

I like the idea of matching the spec with Iterators 👍 This would also allow you to specify the sequence.value in any way you choose to. In some cases, the value could be an object with a progress key if the user so chooses, or it could just be a plain scalar value if custom objects seem overkill.

It might be too much to try to fit the form of sequence.value to cover all the possible use cases. That could be left for the application domain to handle so that FSA would only be concerned about the sequence.id and sequence.done values. What do you think?

EDIT: P.S. This issue being open is currently the only thing stopping us from using FSA in our application. Some way of resolving this would help us tremendously so that we wouldn't have to invent our own ways of doing optimistic updates.

[tappleby]

Matching the Iterators spec is an interesting idea. Part of me does like the idea of being able to identify the start of a sequence without having to track previous sequence ids; this isnt possible using just done alone. Perhaps this isnt a common use case?

[tappleby]

@acdlite how do you feel about the following:

{
  type,
  payload,
  meta,
  sequence: {
    type: 'start', // or 'next', or 'done'
    id: 123, // same for every action in the sequence
    value: { progress: 0 } // Optional value 
  }
}

I feel using done instead of return better describes whats happening and is less likely to be confused with the return keyword.

I am still not sure if value is necessary, optional data like this could be stored in meta.

[valscion]

I am still not sure if value is necessary, optional data like this could be stored in meta.

That would actually be reasonable. If at some point FSA wants to change to add a more thought-out sequence.value, it would not conflict with ones before.