props and state passed to observe() are undefined after first state change #25
Comments
I'm having the same issue. |
Where are you calling setState from? |
sample code in todo demo to add pagination var TodoList = React.createClass({
mixins: [ParseReact.Mixin],
getInitialState: function() {
return {skip:0, limit: 3}
},
observe: function(props, state) {
// state is undefined after initial mount
return {
items: (new Parse.Query('TodoItem')).ascending('createdAt').skip(state.skip).limit(state.limit)
};
},
render: function() {
var self = this;
// If a query is outstanding, this.props.queryPending will be true
// We can use this to display a loading indicator
return (
<div className={this.pendingQueries().length ? 'todo_list loading' : 'todo_list'}>
<a onClick={this._refresh} className="refresh">Refresh</a>
{this.data.items.map(function(i) {
// Loop over the objects returned by the items query, rendering them
// with TodoItem components.
return (
<TodoItem key={i.id} item={i} update={self._updateItem} destroy={self._destroyItem} />
);
})}
<a onClick={this._nextPage}>Next</a>
</div>
);
},
_nextPage: function() {
this.setState({skip: this.state.skip + this.state.limit });
},
_refresh: function() {
this.refreshQueries('items');
}
...
}); |
I have to downgrade to 0.1.4 for avoiding this issue. |
Weird, you could always just reference the values directly as observe: function(props, state) {
//do not even use state or props but reference the values directly
return {
items: (new Parse.Query('TodoItem')).ascending('createdAt').skip(this.state.skip).limit(this.state.limit)
};
}, |
@agnosticdev Thanks for your advice. It worked, but |
@agnosticdev this.state gives the values before the setState call
|
@gkrcode Yes, you're right. No wonder it did not give any result in my case. |
@gkrcode yes, this is a good point. |
I have to say, I really appreciate the level of community discussion happening here around such a young library. This particular bug is due to an (embarrassing) oversight, thankfully fixed by #28. My local test suite didn't have a case for changing state after initialization. For those interested, the discussion around the |
@andrewimm actually both strategies would be valid depending on the purpose of 'observables'. React pushes forward strong DOM elements reuse as it's pretty difficult to ask for a componenent unmount. In my case, I have an 'ObjectEditor', which is a highly reusable component that take a parseClassName and objectId as props. From there with type inference, I have a proper a nice CMS. The issue for me is when I switch objects being rendered, (which is just the state of the parent component) that editor doesn't get unmounted, therefore, updating the props to the new objectId is what make sense. I ended up monkey patching the function to suit my needs, not responding to state changes, only props changes. maybe there should be an exposed (not _) function so we can trigger the observe lifecycle outside the common prop update. |
Just released 0.2.1 on npm and ParseCDN. This issue should be resolved now. |
When my component is mounted, the props are available. However, after I perform a setState, both props and state are undefined.
The text was updated successfully, but these errors were encountered: