feat(core): new pattern for firebase instance in thunks/sagas (getFirebase not part of v3 API)

[ljacho]

getFirebase is not returning firebase instance. Getting undefined.

[prescottprue]

@sbtgE What version are you using? How/when are you using getFirebase. It depends on when your instance is initialized.

[ljacho]

@prescottprue trying "3.0.0-alpha.9" and I want to access firebase instance in thunk:

...
import { getFirebase } from 'react-redux-firebase';
import { getFirestore } from 'redux-firestore';
...

export default function configureStore(intState = {}, history) {
  const middlewares = [
    routerMiddleware(history),
    thunk.withExtraArgument({getFirebase, getFirestore}),
    logger
  ];

  const enhancers = [
    applyMiddleware(...middlewares),
  ];

  const store = createStore(
    createReducer(),
    intState,
    compose(...enhancers));

  // Hot reloading
  if (module.hot) {
    // Enable Webpack hot module replacement for reducers
    module.hot.accept('./reducers', () => {
      store.replaceReducer(createReducer());
    });
  }

  return store;
}

actions.js

export function register(newUser) {
  return (dispatch, getState, { getFirebase, getFirestore }) => {
    dispatch({ type: ACTION_LOADING_SET })

    const firebase = getFirebase()
    const firestore = getFirestore()

 ...

[prescottprue]

@sbtgE getFirebase is not part of the v3.0.0 api (mentioned in the v3.0.0 roadmap, but looking to make this more clear). The new API uses the stable React context api and does not have any store enhancers. The way that context is now passed means that the wrapped firebase instance, which was kept on the store (store.firebase), is no longer necessary. That said, there was already is an open question of best pattern within thunks/sagas, so I'll put this ticket next to it.

I have personally been leaving the business logic within handlers (thunks were most often not needed in my cases), or where necessary passed the wrapped method through (i.e. push or update). This is because the wrapped instance can be passed using React's stable context api and pulled with a Provider (ReactReduxFirebaseProvider) and used right within your component's handlers. The goal was to actually get folks to move towards doing that by providing the instance as props in withFirebase and firebaseConnect.

Wondering for your case:

• Are you dispatching other custom actions in your thunk?
• Is there a reason not to call the wrapped method then whatever is in your thunk?
• Is logic within thunks an organizational thing or is there another specific reason for using them?
• Are you on a new enough version of react to be using the context API?

The reason I ask is that the v3 API is by no means stable, so I am trying to understand as many use cases as possible. Especially since there has been a middleware planned for a while that will handle calling async methods (like push/set) through dispatching an action like CALL_FIREBASE (not decided on yet) - your use case may be a good fit to test this pattern out.

[ljacho]

Thank you for the comprehensive answer. First of all, I have to admit, that I am not so experienced in the topic but I will do my best to describe the whole thing. According to my current experience context API is great, but I don't see an easy way to switch from using the store and thunk with a lot of custom actions to using context actually. Imho the best way for this moment would be to support both solutions at least for the next major version - dispatching e.g. CALL_FIREBASE could be helpful. I would like to follow this topic and see what others think about that - still learning - I think that slack/discord channel would help speed up discussion. Appreciate your help @prescottprue.

[prescottprue]

@sbtgE No problem at all, glad to talk out the options. I like the idea of keeping the API similar for this version, but still need to look into how that would be done. As for a chat line, there is the the gitter channel.

[prescottprue]

#607 was another duplicate of this question. Clearly something that will needs to be addressed.

[kelset]

Related to this, I've hit myself this issue and I feel it's also caused by the fact that neither the release tabs nor the docs for v3.0 mention this (it's actually still there) - even the migration guide doesn't mention it.