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(populate): dispatch for errors during profile population #312

Merged
merged 2 commits into from Oct 29, 2017

Conversation

fej-snikduj
Copy link
Collaborator

Description

This PR adds logic to catch errors during profile parameter population. If a the client does not have access to the data to populate, SET_PROFILE is dispatched with the unpopulated profile. Previously, an uncaught error prevented the profile from being updated.

Check List

If not relevant to pull request, check off as complete

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

Relevant Issues

@codecov
Copy link

codecov bot commented Oct 29, 2017

Codecov Report

❗ No coverage uploaded for pull request base (v2.0.0-beta.14@142b9e7). Click here to learn what that means.
The diff coverage is 50%.

@@               Coverage Diff                @@
##             v2.0.0-beta.14    #312   +/-   ##
================================================
  Coverage                  ?   83.5%           
================================================
  Files                     ?      22           
  Lines                     ?    2104           
  Branches                  ?     324           
================================================
  Hits                      ?    1757           
  Misses                    ?     347           
  Partials                  ?       0

@prescottprue prescottprue changed the base branch from v2.0.0 to v2.0.0-beta.14 October 29, 2017 05:50
@prescottprue prescottprue changed the title Catch populated errors during profile population fix(populate): dispatch for errors during profile population Oct 29, 2017
@prescottprue prescottprue merged commit 2797937 into v2.0.0-beta.14 Oct 29, 2017
@prescottprue prescottprue deleted the v2.0.0-beta.15 branch October 29, 2017 05:52
@prescottprue prescottprue mentioned this pull request Oct 29, 2017
3 tasks
prescottprue added a commit that referenced this pull request Oct 29, 2017
### Description
* fix(typings): Updated type definitions - #311
* fix(populate): dispatch for errors during profile population - #312
* feat(firebaseConnect): `store` is passed as second argument of `firebaseConnect` - #278
* feat(firestoreConnect): `store` is passed as second argument of `firestoreConnect`
* fix(query): `dispatchRemoveAction` is now `false` by default - prevents multiple state updates when calling `remove` if listener associated is attached

### Potentially Breaking
 * `store` being passed as second argument of `firebaseConnect` (and `firestoreConnect`), which means any components using that second argument will break (most commonly used for getting `uid`). To access `uid` or other info from redux state, use `store.getState()` like so:

```js
firebaseConnect(
  (props, store) => {
    const { firebase: { auth } } = store.getState()
    // be careful, listeners are not re-attached when auth state changes unless props change
    return [{ path: `todos/${auth.uid || ''}` }]
  }
)
```

More details are included in [the migration guide](http://docs.react-redux-firebase.com/history/v2.0.0/docs/v2-migration-guide.html).
prescottprue added a commit that referenced this pull request Oct 29, 2017
* fix(typings): Updated type definitions - #311
* fix(populate): dispatch for errors during profile population - #312
* feat(firebaseConnect): `store` is passed as second argument of `firebaseConnect` - #278
* feat(firestoreConnect): `store` is passed as second argument of `firestoreConnect`
* fix(query): `dispatchRemoveAction` is now `false` by default - prevents multiple state updates when calling `remove` if listener associated is attached

 * `store` being passed as second argument of `firebaseConnect` (and `firestoreConnect`), which means any components using that second argument will break (most commonly used for getting `uid`). To access `uid` or other info from redux state, use `store.getState()` like so:

```js
firebaseConnect(
  (props, store) => {
    const { firebase: { auth } } = store.getState()
    // be careful, listeners are not re-attached when auth state changes unless props change
    return [{ path: `todos/${auth.uid || ''}` }]
  }
)
```

More details are included in [the migration guide](http://docs.react-redux-firebase.com/history/v2.0.0/docs/v2-migration-guide.html).
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

Successfully merging this pull request may close these issues.

None yet

2 participants