callback to let component know when it's receivingData

[bytesandwich]

perhaps here https://github.com/ParsePlatform/ParseReact/blob/master/lib/Mixin.js#L148 before forceUpdate call a method like 'this.willReceiveData' on this component if the method exists.

I'm proposing this because I have a subscribed query that moves a window three objects wide through an ordering of persisted objects. Currently, the query refreshes when I mutate the window's index and the component briefly has nothing to show the user. I'd like to take the query's new result, after the index updates, and rectify the new window contents with the previous, so that to the user it seems like a natural scroll rather than a refresh.

[bytesandwich]

Perhaps even add a method to take the query results and produce the data object? It might make sense for many infinite scroll or pagination scenarios - really any time the query is iteratively revealing some larger thing.

Something along these lines?

    _receiveData: function _receiveData(name, value) {
      var update = true;
      var oldValue = this.data[name];
      if (this.acceptData) {
        update = this.acceptData(name, value);
      } else {
        this.data[name] = value;
      }
      delete this._pendingQueries[name];
      delete this._queryErrors[name];
      if (this.componentDidUpdateData) {
        this.componentDidUpdateData(name, value, oldValue);
      }
      if (update) {
        this.forceUpdate();
      }
    },

[bytesandwich]

I'm finding this really useful. As I have an animation that goes through states as the information is revealed, this let's me handle the update with a delay and a callback, returning false from acceptData to avoid the immediate update.

[yamill]

@jackphel where is this.acceptData coming from? I tried using the above example but was receiving an error.

[brentvatne]

@jackphel - I like that, @andrewimm - what do you think? We have a big need for this and I'm going to be working off of a fork until something like this makes it in :( cc @mattmo

[brentvatne]

@jackphel - additionally it would be nice to provide a similar hook on error

[andrewimm]

Sorry all, I haven't had much time to devote to new features lately. Originally, I was opposed to a hook like this, since it's expanding the scope of the originally-proposed Observe API, and it opens up the potential for infinite loops. That said, I've come back to the concept recently, since I've been preparing a talk for React Rally about the role of Observables in React. If we properly restrict the method (the way setState can't be called in certain locations), we could enable this sort of behavior without providing any footguns for developers. In preparation for this talk later in the month, I'm planning on open sourcing an observability layer for React -- think ParseReact.Mixin and the ES6 ParseComponent, without the Parse-y bits. I'll look to explore more generic implementations of willReceiveData there. The eventual goal is to have the observability aspects of Parse+React depend on this separate, generic implementation (with the hope that some form this API might eventually make it into React core).

@brentvatne I'd love to hear more about your use cases, since you make it seem pretty crucial.

[rubencodes]

Any progress on this?

@andrewimm Just to give you my use case, there are some things I store in state that need to be regenerated every time the results from my query change. I have been trying to make these changes in componentDidUpdate but this has proven very prone to infinite loops and other bugs that are difficult to debug since this runs on prop and state changes. If there were a didUpdate method exclusively for data, or if componentDidUpdate received an oldData param in addition to the ones it currently does, this would be significantly easier and less error-prone. Thanks!

[yamill]

I agree with @rubencodes !