Feature: ObservableList

[blink1073]

Removes Vector and replaces ObservableVector with ObservableList. More closely matches the Google CollaborativeList API, while removing the values from the change signal to enable cheaper notifications to be emitted from a server-based backend.

  /**
   * The change types which occur on an observable list.
   */
  export
  type ChangeType =
    /**
     * Item(s) were added to the list.
     */
    'add' |

    /**
     * An item was moved within the list.
     */
    'move' |

    /**
     * Item(s) were removed from the list.
     */
    'remove' |

    /**
     * An item was set in the list.
     */
    'set';

  /**
   * The changed args object which is emitted by an observable list.
   */
  export
  interface IChangedArgs {
    /**
     * The type of change undergone by the list.
     */
    type: ChangeType;

    /**
     * The new index associated with the change.
     */
    newIndex: number;

    /**
     * The old index associated with the change.
     */
    oldIndex: number;

    /**
     * The number of items added or removed.
     */
    count: number;
  }

[blink1073]

cc @ian-r-rose, @ellisonbg

[blink1073]

cf #1767.

[ellisonbg]

Does this add the uuid for each change?

[blink1073]

No, I didn't have a clear sense of how we wanted to handle that yet.

[ian-r-rose]

I am a little concerned about the non-atomicity of these change signals (as @ellisonbg suggested the other day). If the underlying list has changed between when the signal is received and when the new entries are queried, then the view will get out of sync with the model.

On the other hand, with the CellList approach to the notebook, we will need some special logic for cell operations anyways. That is, if a new cell is inserted, the information will not hit the cellMap and cellOrder objects at the same time. For a single user this is easy enough to resolve, but will be trickier for multiple users.

[ellisonbg]

True, even if we have uuids that record to version, if we spread a data structure like the cell list over a list+map, the overall operations won't be atomic.

…

On Mon, Mar 20, 2017 at 8:51 AM, Ian Rose ***@***.***> wrote: I am a little concerned about the non-atomicity of these change signals (as @ellisonbg <https://github.com/ellisonbg> suggested the other day). If the underlying list has changed between when the signal is received and when the new entries are queried, then the view will get out of sync with the model. On the other hand, with the CellList approach to the notebook, we will need some special logic for cell operations anyways. That is, if a new cell is inserted, the information will not hit the cellMap and cellOrder objects at the same time. For a single user this is easy enough to resolve, but will be trickier for multiple users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1959 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0OuyMHbkbWKQYXZbjFPYtUOHhCVoks5rnqCagaJpZM4Mhv-_> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

[blink1073]

An alternative is to make the changed signal dumb and treat it as a an atomic value for the consumer. The underlying implementation would provide the undo capability as it sees fit.

[blink1073]

We could treat ObservableList the same as ObservableValue, but the subclass would allow backend implementations to use whichever mechanism they like.

[ian-r-rose]

That would be fine with me, overall. That would make it much harder for the model and view to go out of sync.

[blink1073]

Going to close this in favor of #2039 approach.