Closed jvoros closed 7 years ago
Merging #203 into master will decrease coverage by
0.28%
. The diff coverage is84.61%
.
@@ Coverage Diff @@
## master #203 +/- ##
==========================================
- Coverage 55.26% 54.97% -0.29%
==========================================
Files 17 16 -1
Lines 228 231 +3
Branches 53 58 +5
==========================================
+ Hits 126 127 +1
- Misses 102 104 +2
Impacted Files | Coverage Δ | |
---|---|---|
app/components/SearchResults.tsx | 94.73% <100%> (+3.07%) |
:arrow_up: |
app/components/Search.tsx | 88.88% <50%> (-11.12%) |
:arrow_down: |
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 c37caf8...39147cf. Read the comment docs.
Finally got a chance to look at this.
I'm confused what the issue was prior to this? After pulling and trying out this branch, the spinner feels laggy. IMHO, I think as soon as the user begins typing, the spinner should begin spinning, regardless of whether or not the query is actually being ran or not just to give the user a feeling of snappiness.
That's a good suggestion.
Before the spinner was only dependent on whether or not the user was typing in the search box. 500 msec after stopping typing, the spinner went away, regardless of what status the query was in. So it left a big lag on the back end between when the spinner stops and the results populate.
500 msec after stopping typing, the spinner went away, regardless of what status the query was in. So it left a big lag on the back end between when the spinner stops and the results populate.
Aha! Didn't realize that. Yep, that's definitely a problem.
Any way we can keep your changes that fix that, but also instantly start the spinner when a user starts typing?
Made the spinner dependent on the Apollo query, not the search box throttle.