Skip to content
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

Fix duplicate key issue #61

Closed
jacknoble opened this issue Apr 4, 2015 · 3 comments
Closed

Fix duplicate key issue #61

jacknoble opened this issue Apr 4, 2015 · 3 comments

Comments

@jacknoble
Copy link
Collaborator

Warning: flattenChildren(...): Encountered two children with the same key. Child keys must be unique; when two children share a key, only the first child will be used. See Satish's explanation here #21 .

This is already like the third time we've had to make our code more complicated to accommodate Firebase's weird events. How are people feeling about continuing with it? I don't think it would take that much more work to roll our own backend. We need a document store with a WebSocket connection and an event listener. I still have a slight preference for Elixir or Clojure, but I'd be fine doing it in JS if people are more comfortable with that and don't want to be distracted from learning React.

@satishkunisi
Copy link
Collaborator

I'm open to another backend.

Just to talk this particular problem through, is there a way to handle the Firebase events in the stores vs. in the components? Then components would just get their state from the stores. One idea would be to fire an event on channel's being joined / left that would propagate through to the stores and toggle the relevant Firebase listeners.

@jacknoble
Copy link
Collaborator Author

Yeah. So we should definitely move Actions.listenForNewMessages('bestcohort'); outside of the any components. On reflection it has no business being there (especially since we probably want to keep listening even if the user has another channel open or is on a different page). If it did go in a store I think the best place would be a ChannelsStore that kept track of available channels and which channels a user joined.

Alternatively they could just go in the actions (the JOIN action would start listening and the LEAVE action would remove the listener). That makes the most sense to me since they're not necessarily connected to any one particular store. This discussion is good http://stackoverflow.com/questions/26632415/where-should-ajax-request-be-made-in-flux-app

@jacknoble
Copy link
Collaborator Author

So the immediate issue is having to remove the listener. We could have ChannelMessage.willComponentMount() call a method on MessageStore that could do something like:

listenForNewMessage: function() {
  if (typeof this.listening !== 'underfined' || !this.listening) {
    Actions.listenForNewMessages('bestcohort');
    this.listening = true;
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants