Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Added <QuerySelector /> component #3494
Added <QuerySelector /> component #3494
Changes from 3 commits
1a50cab
0d209cb
cd9f1e0
325be9f
a5b0aaf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ranbena Look: you still load search results as a side-effect of changing search term. It's implicit dependency, that's what makes code hard to read and understand:
in opposite to explicit reaction, where you immediately see that if you change search term - it will do some extra stuff:
I intentionally provide examples in Angular because this pattern is really common there, and one of best practices in React for a long time was to avoid such code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this useEffect also allows easy stale/debounce management (the alternative I assume is having dedicated refs), I'd rather keep it and keep moving 🏃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took some time for me to understand how it works, and then I realized that actually it's AngularJS-way to handle data flow: you set a state field, but setter just updates value; and there is watcher (
$scope.$watch
) that does something when that field changes. That's not something I personally expect to see in React code 🤔There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do it rarely when it makes sense. But now considering more since useEffect is so convenient. Will stay away from it if you feel it's an anti-pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think so. That's what makes AngularJS code hard to understand; it's much easier to understand what's going on when you see: "ah, this function updates state variable, but also it loads queries", etc. With such side effects you see: "this function updates state. okay." - and then you see that oh magic! it somehow loads data! whaaat?? And you need to find another place in the code which load query results. And BTW - in AngularJS this mechanism is a bit better because you describe dependency first, and then write handler. With
useEffect
if's really easy to miss dependencies (what I did, actually). Compare:I really think this is anti-pattern; probably one of the things I most liked in React - strict data flows, without implicit dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting observation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Read that code once more and have something to add)
Another con of this approach is harder data flow control. Did you notice that effect that loads search results could be optimized? When search term is
null
- you already have search results (empty list). If you have setter for search term - you can handle it immediately:null
, and search results tonull
;but with
useEffect
it will:null
and updates search results tonull