newbie question

[jasan-s]

hello, i'm learning react with es6 classes and firebase. came across this lib. I had couple questions, is there a benefit to using re-base push method instead of Firebase push method( in one i see i create a re-base class instance and another a new firebase instance ? second, what flux type architecture does this lib play nice with, ALT , FLUX, Redux? Thanks in advance

[foffer]

Hi @jasan-s.

As you can see here it is the exact same method, the benefit being, that you don't have to create a new Firebase instance as well as your current Rebase.

As to flux pattern, firebase pretty much substitutes the need for Flux
From the website

Flux eschews MVC in favor of a unidirectional data flow. When a user interacts with a React view, the view propagates an action through a central dispatcher, to the various stores that hold the application's data and business logic, which updates all of the views that are affected. This works especially well with React's declarative programming style, which allows the store to send updates without specifying how to transition views between states.

Firebase achieves the same goal by you 'subscribing' to your endpoint and listening for data.

Hope this helps

[jasan-s]

@foffer Thanks. I came across that realization as well that I can get away without using flux. BUt couple of other Developers told me that i would have real hard time developing a production grade React app without flux/redux.

[troublesprouter]

Any further thoughts on the last comment? I'm also new and I'm also getting conflicting advice as to whether Redux (or Flux generally) makes sense with Firebase for a serious, potentially large app for the long term. All thoughts welcome.

[Dooblr]

+1

Why would you not want flux? Firebase stores only data, not UI state. Further, are there any working examples of Rebase+Redux?

[mkozhukharenko]

I think Redux/Flux+Redux make sense if you are planning in a future create you own REST server (instead of Firebase). If will help easily migrate existing code base.

But I'd like to hear an opinion of more experienced developers about this question.

[ghost]

Does re-base work out-of-the-box with redux state management? I want to try jumpsuit (https://github.com/jumpsuit/jumpsuit) and am wondering how friendly re-base will be.

UPDATE:
Assigning the base context to a state action is working in my prototype, but for base.syncState to update firebase the context.setState method needs to be called when the component state's firebase property is updated.

// things/state.js
const state = State('myComponentState', {
  initial: {
    things: [],
  },
  setState: (state, payload) => payload,
})

// things/component.js
componentWillMount () {
  base.bindToState('things', {
    context: {
      setState: payload => state.setState(payload)
    },
    state: 'things',
    asArray: true,
  })
}

[qwales1]

@hyperbrave I was wondering how that would play with syncState. I think also you could run into problems with multiple components using syncState as it will always use the first context.setState passed to it for subsequent calls. How does component.js call the React component's setState in the example?

[ghost]

@qwales1 if you declare the base.syncState context object outside of the component scope so that the component has a reference to it, you can manually call it. I have syncState working that way, but it'd be nice if redux compatibility was abstracted into the rebase library because this feels unwieldy. There's a redux firebase repo that may integrate with jumpsuit more elegantly at (https://github.com/tiberiuc/redux-react-firebase) but I haven't taken a look yet.

One thing I'm juggling, being fairly new to redux/react, is where the rebase functionality should go in a jumpsuit app.

// things/component.js
import state from './state'

const context = {
  setState: state.setState
}

export default Component({

  componentWillMount () {
    base.syncState('things', {
      context: context,
      state: 'things',
      asArray: true,
    })
  },

  addThing (thing) {
    const key = base.push('things', {
      data: thing,
      then (err) {
        if (err)
          return console.err(err)
      }
    })
  },

  removeThing (index) {
    const data = state.getState()
    data.things.splice(index, 1)
    context.setState({
      things: data.things,
    })
  },
})

[qwales1]

@hyperbrave I looked at jumpsuit briefly and it is very cool. I personally would not use re-base with it though. I would just use the firebase SDK directly to implement whatever the recommended way of persisting data and hydrating the stores is with redux. If that is what redux-react-firebase does then that would be perfect.

The value, in my opinion, that re-base provides is connecting firebase to the state of a React component directly. Firebase itself is the store and the components are subscribed to changes through re-base. Then I can trigger changes through push, update, post, or use syncState. So it has that same data down / actions up pattern that redux has. You could even only use re-base in container components so you can reuse them throughout the app and then you would have a pattern that is similar to what jumpsuit is doing.

Jumpsuit State -> Container React Component subscribed to Firebase, provides state changes to child components as props
Jumpsuit Component -> Presentational React Component (only receives props)

[peterlau]

Just like to get my two cents in as another newcomer to the world of non-trivial state/data management in React.

I struggled for weeks integrating firebase into a react native app, trying to wrap my head around slotting react-redux-firebase into a pre-existing cascade of redux middleware (redux-persist, redux-reset, etc) while maintaining control of what data is getting persisted and rehydrated where, and why.

Finally I saw the light at the end of the tunnel when I read this quote by this library's author.

Firebase and Flux really don't work well together... because they're both trying to accomplish roughly the same thing

This library brought back the delight I felt when I first learned to put an SPA together using plain vanilla React props and state, before I got sucked into the necessary evil of global state frameworks. It allows the proper separation of UI state persistence from the business data persistence, and puts nothing between the latter and the UI that exposes it.

I cannot recommend this approach more highly.

[saurav-bhagat]

How can I use exist function in ListenTo function ?