react-redux-firebase: Bug(Listeners): Component with same listeners does not update correctly.

What is the current behavior?

I have two containers with the same structure.

@connect(({ firebase: { auth, profile } }) => ({
  auth,
  profile
}))
export default class ContainerOneWrapper extends Component {
  render() {
    return (
      <ContainerOneComponent
        router={this.props.router}
        profile={this.props.profile}
        auth={this.props.auth}
      />
    )
  }
}

@connect(({ firebase: { auth } }) => ({
  auth
}))
export default class ContainerTwoWrapper extends Component {
  render() {

    return (
        <ContainerTwoComponent auth={this.props.auth} />
    )
  }
}

They both have the same listeners on them,

ComponentOne

@firebaseConnect(({ auth }) => [
  `/cookbooks/${auth.uid}`,
  `/planners/${auth.uid}`
])
@connect(({ firebase: { data, auth } }) => ({
  userMeals: data.cookbooks && data.cookbooks[auth.uid]
}))

ComponentTwo

@firebaseConnect(({ auth }) => [
  `/cookbooks/${auth.uid}`,
  `/planners/${auth.uid}`
])
@connect(({ firebase: { data, auth } }) => ({
  userMeals: data.cookbooks && data.cookbooks[auth.uid],
  userPlan: data.planners && data.planners[auth.uid]
}))

When I navigate to ComponentOne, it sets the listeners fine,

But then I go to ComponentTwo, and the listeners are UNSET, but the componentTwo listeners are not set.

And then if I go back to ComponentOne:

What is the expected behavior?

When navigating to a different component the listeners should unset and on the new component rendering, set the correct listeners, even if they’re the same? 🤷🏻‍♂️

Which versions of dependencies, and which browser and OS are affected by this issue? Did this work in previous versions or setups?

using "react-redux-firebase": "^2.0.0-rc.2"

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 6
Comments: 23 (11 by maintainers)

Most upvoted comments

Hey @prescottprue thanks for looking into this!

I was no longer receiving updates in that collection, so it’s definitely detatched.

@kylepotts for a part time fixed I just added a watchEvent on componentDidMount. It adds the listeners again for me and works ok. Probs not the best solution…

componentDidMount() {
    this.props.firebase.watchEvent('value', `/cookbooks/${this.props.auth.uid}`)
    this.props.firebase.watchEvent('value', `/planners/${this.props.auth.uid}`)
}

karltaylor on Jan 16, 2018

I am having a similar issue. Using the 2.0 version. Kinda makes using this pointless since nothing updates.

kylepotts on Jan 14, 2018

hi @prescottprue, I’ve compiled a quick example how to replicate this issue. You can have a look at it here.

I think it is caused by a race conditions within react’s lifecycle methods.

firebaseConnect is using willComponentMount and willComponentUnmount set/unset listeners.

This causes following chain of events when using it in combination with the react-router:

ComponentA invokes componentWillMount and creates a listener foo
Route switch
ComponentB componentWillMount kicks in before willUnmount of the previous component. It sees an existing listener and does nothing.
ComponentA invokes componentWillUnmount and cleans up after itself while deleting listeners that belong to a ComponentB as well.

Potential solution: Move watchEvents logic to componentDidMount rather than componentWillMount as per description here. I will give it a test later today to see if it causes any issues with our product.

iamthefox on Apr 3, 2018

right now they are tracked by a count of listeners on that path.

@prescottprue, this is not working properly. ^ I didn’t realize you already had already done this.

santiago-elustondo on Apr 16, 2018

To expand on the example above,

This is how redux inspector looks when firebaseConnect is invoking componentWillMount

screen shot 2018-04-03 at 3 07 58 pm

And this is how it looks if I replace it with componentDidMount.

screen shot 2018-04-03 at 3 07 27 pm

I can’t tell what this could possibly affect, but for me personally it makes more sense to have it in didMount rather than willMount since it does not really bring any performance gains.

iamthefox on Apr 3, 2018

It seems like this issue is fixed for firebaseConnect in v2.1.0.

Thanks to @Tapped to the PR to fix. Going to be looking into better ways to test things like this, and as always, open to PRs if anyone has ideas.

If anyone still experiences these symptoms or something similar after upgrading, please reach out.

prescottprue on Apr 29, 2018

Hi All, I am also running into this issue .

Navigating from page A to page B with both using the same watchpath , destroys the listener on page A and does not restore it on Page B. Navigating directly to page B works fine.

Is this a race condition where destroy for the old component takes place after mounting of the new component?

@prescottprue Is it possible to index listeners by component_identifier + watchpath (instead of just watchpath)? That way one component will not mess with listeners for other components

ShayMatasaro on Apr 8, 2018

I have been looking into passing options to firebaseConnect for not calling UNSET_LISTENER for certain listeners - it has some implications though.

prescottprue on Mar 20, 2018

Just an update adding a different store as seemed to make it work just fine.

kylepotts on Jan 19, 2018