Fix issue with reserved prop names inside firebaseConnect

[theashguy]

Description

Prior to this commit firebaseConnect used the prop 'firebase' to receive the firebase app reference. This meant that if another prop called firebase (for instance, from the default reducer configuration) was supplied to a firebaseConnect wrapped component it would clobber the variable. This would result in either unexpected data in the store, or alternatively the inability for developers to nest firebaseConnect wrapped components.

An example case by @iamthefox has been uploaded here:
https://github.com/iamthefox/react-redux-firebase/blob/next-nested-issues/examples/complete/nested-issue/src/Home.js#L30

This commit renames the internal reference, and also checks to see if reserved words are passed through and throws an error with a useful message that can help developers debug if they accidentally provide one of these reserved props.

Note: This same issue could exist for firestore as well, however I don't have any examples to test with.

Check List

If not relevant to pull request, check off as complete

• [ x ] All tests passing
• [ x ] Docs updated with any changes or examples if applicable
• [ x ] Added tests to ensure new feature(s) work properly

Relevant Issues

Raised in gitter, example provided in description.

[theashguy]

Hrmm. Just got off a plane, will look at cleaning this up tomorrow 👍

[codecov]

Codecov Report

Merging #613 into next will increase coverage by 0.2%.
The diff coverage is 33.33%.

@@           Coverage Diff            @@
##            next     #613     +/-   ##
========================================
+ Coverage   78.4%   78.61%   +0.2%     
========================================
  Files         26       26             
  Lines        917      926      +9     
  Branches     165      166      +1     
========================================
+ Hits         719      728      +9     
  Misses       198      198

[theashguy]

Fixed @prescottprue, have a look and let me know if you want anything changed and / or a different approach entirely. Tried to make it resilient to this class of errors in the future.

Unfortunately we can't test for what the developer is going to pass into a connected component in build (in fact in some cases the developer might not even know off the top of their head), but we can prevent clashes during execution and raise a helpful error, plus make the internals obscure enough that they wont get hit.

[prescottprue]

Really awesome to see the fix and such a comprehensive PR/explanation around it, thanks! I'll merge after testing it a bit

[prescottprue]

Just a small typo

[prescottprue]

Great work on this @theashguy and @iamthefox , and thanks a ton for contribution. It is awesome to see the full feature, the tests, and sticking with the PR to solve merge conflicts.

[prescottprue]

This is causing some issues with the usage of the firebase prop downstream (see #582). I do like the idea of handling the case of this prop being passed and throwing, but I think renaming or disabling the firebase prop will have to be an option, at least for now.

Going to keep in the throwing for passed reserved prop names, but add back the firebase & dispatch props.

Really it is better to pass sections of the state from the reducer instead of the whole state anyway. That said, I do think there needs to be better naming conventions.