-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting state on a store that's being listened to causes infinite loop #304
Comments
When I navigate away from the component that has the associated container and then come back it works again for the first try and then fails with an infinite loop on subsequent attempts. |
I was able to find a workaround for now. Hopefully this doesn't break something else in the process. This still seems like a bug to me. 'use strict';
import Marty from 'marty';
// stores
import MessageStore from '../../stores/message-store';
export default function(Component) {
return Marty.createContainer(Component, {
listenTo: MessageStore,
fetch: {
messages() {
if (MessageStore.action && MessageStore.action.type === 'FETCH_ALL_MESSAGES_STARTING') { return; }
return MessageStore.for(this).all(this.props.params.id);
}
}
});
} |
Do you have a stack trace or anything inside the infinite loop, to show what's triggering the behavior? Marty is set up not to re-fetch data that's already in the process of being fetched. Is your |
Yes, Here's the stack trace from Chrome. It's pretty long so I only formatted it until it looked like it started repeating.
|
This is still causing my team a lot of headache. It doesn't seem like anybody else is seeing this issue so it must be us. Is it valid in Marty to use a store's fetch method within a container? e.g. Customer Store get(id) {
return this.fetch({
id: id,
locally() {
let collection = this.state.data.get('collection') || Immutable.Map();
return collection.get(id);
},
remotely() {
return CustomerQueries.get(id);
}
});
} Container fetch: {
customer() {
let customerId = this.context.router.getCurrentParams().id;
return CustomerStore.for(this).get(customerId);
}
} |
Can you confirm which version of Marty you're using? |
0.9.17 |
Shoot. Okay. That's legitimately a bug. The issue is that as long as we dispatch actions synchronously, this line: https://github.com/martyjs/marty-lib/blob/v0.10.6/src/store/storeFetch.js#L83 needs to be hoisted before the The problem is that right now we're already on v0.10.x, which has breaking changes if you're on v0.9.x (although I think the API for isomorphism is much much nicer). |
I guess maybe most other people aren't bothering to explicitly handle the If you want to work around this right now, you should be able to just wrap either this.dispatch(MessageConstants.FETCH_ALL_MESSAGES_STARTING); or _start() {
this._setMeta(false, null, false, true);
} in a |
Ok, I have a workaround but there have been some circumstances where it doesn't work. Maybe Any chance this can be fixed in 0.9 or will I have to switch to 0.10? |
@jhollingworth Do you think it's worth cutting a v0.9.18 to address this? |
Any updates here? Has this been fixed in 0.10? |
Not yet. I can patch it in one or either, but need @jhollingworth to cut an NPM release. |
Any updates on this? |
Just saw the README. Super sorry to see this project go. Thanks for all your hardwork! |
I have a container that's listening to a store that's fetching remote data via a query. The first time I run through the loop it works fine. However, every subsequent attempt results in an infinite loop. Marty seems to be having issues setting state on a store that it's currently fetching data from.
I provided some code below. Whenever the dispatcher hits an action that sets the loading state of the store it immediately resets the loop. It never gets past dispatching that action.
The specific line is:
from within the query.
My store inherits from a custom base store I created to simplify managing done/load/fail states. I've attached this code as well.
I've been working on this all evening with no luck.
Container
Query
Store
Base Store
The text was updated successfully, but these errors were encountered: