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

Update Listener When Props Change #10

Merged
merged 7 commits into from
Mar 19, 2018
Merged

Update Listener When Props Change #10

merged 7 commits into from
Mar 19, 2018

Conversation

damonbauer
Copy link
Contributor

I ran into #9 and thought I might be able to fix the issue.

I added a componentWillReceiveProps lifecycle method that compares incoming & existing props. If the path prop is different, it's safe to assume we want to fetch new data. So, I unsubscribed the active listener, set state back to the "default state", and set up a new listener for the new path.

@green-arrow @mikekellyio - if this direction makes sense, I can make the same change to FirestoreCollection; I just wanted to make sure this concept made sense before I spent more time on it.

@codecov
Copy link

codecov bot commented Mar 1, 2018

Codecov Report

Merging #10 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff          @@
##           master    #10   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           5      6    +1     
  Lines          58     76   +18     
  Branches        9     14    +5     
=====================================
+ Hits           58     76   +18
Impacted Files Coverage Δ
src/utils/deepEqual.js 100% <100%> (ø)
src/FirestoreDocument.js 100% <100%> (ø) ⬆️
src/FirestoreCollection.js 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78787c9...e7cc85b. Read the comment docs.

Copy link
Owner

@green-arrow green-arrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First off, thank you for taking the time to tackle this problem!

I like the direction of this and would definitely like to see it applied to collection as well.

My one thought on the approach overall would be do we actually want to fully reset to the default state when props change, or do we just want to flip the isLoading flag? Completely resetting means the caller no longer has access to data, so performing any kind of transition directly between states becomes impossible. The caller would have to first transition to an empty loading state until the new data comes in. If we keep data unchanged, that becomes a choice for the caller instead of a necessity.

@damonbauer
Copy link
Contributor Author

@green-arrow That's a good call. I modified componentWillReceiveProps to only set isLoading: true state & extracted the if (this.unsubscribe) { this.unsubscribe() } logic to be reused.

If you're good with this, I'll take a look at doing the same thing for collections.

@green-arrow
Copy link
Owner

@damonbauer - this looks good. Feel free to go ahead and add this to collection.

@damonbauer
Copy link
Contributor Author

damonbauer commented Mar 2, 2018

@green-arrow I'm not super sure how you'd prefer tests to be set up/organized, but I added them. I tried to reduce some of the boilerplate for each of the different prop tests in collection by adding common assertions to a function that describes the assertion.

Note: I added lodash.isequal as a dependency in order to check the filter prop equality, since it does deep equality out of the box.

@damonbauer
Copy link
Contributor Author

@green-arrow Have you had a chance to review this?

Copy link
Owner

@green-arrow green-arrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@damonbauer - Sorry this took so long for me to get to, I've been pretty busy at work and home for the past couple weeks.

Just a couple comments around removing lodash. Everything looks great though!

package.json Outdated
@@ -53,6 +53,7 @@
"enzyme": "^3.3.0",
"enzyme-adapter-react-16": "^1.1.1",
"kcd-scripts": "^0.32.1",
"lodash.isequal": "^4.5.0",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@damonbauer - I'd prefer to keep the dependencies on this project to a minimum. Since this is only used in one spot, let's just replace it and remove the dependency.

}

componentWillReceiveProps(nextProps) {
if (!isEqual(nextProps, this.props)) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@damonbauer - Since we're already testing for each individual prop in the tests, we can just do the same here and remove the dependency on lodash.

@damonbauer
Copy link
Contributor Author

Alright, @green-arrow, I've removed the lodash dependency. I added a small "deep equal" utility that I'm using to compare the filter prop, since it can be a nested array. Let me know what you think!

Copy link
Owner

@green-arrow green-arrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for all the work you put into this!

@green-arrow green-arrow merged commit 48cb1bf into green-arrow:master Mar 19, 2018
@damonbauer damonbauer deleted the feat/update-on-prop-change branch December 1, 2018 11:02
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