-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add async loading, infinite scrolling, sorting, and empty state to Table #445
Conversation
Build successful! 🎉 |
@@ -531,7 +513,8 @@ export class CollectionManager<T extends object, V, W> { | |||
} | |||
}; | |||
|
|||
setTimeout(done, this.transitionDuration); | |||
// Sometimes the animation takes slightly longer than expected. | |||
setTimeout(done, this.transitionDuration + 100); |
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 dislike magic numbers around time, any chance we could Promise.all or something and have animation transactions return promises? or are these specifically css transition times? in which case 100 seems like a lot?
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's a CSS transition. Unfortunately the transitionEnd event isn't reliable either. The actual value of this doesn't matter that much. It's just the time between when the animation finishes and when we actually remove the DOM nodes.
/** The type of item this node represents. */ | ||
type: 'section' | 'item' | 'column' | 'cell' | 'rowheader' | 'placeholder' | 'headerrow', | ||
type: string, |
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.
are the old types getting exposed anywhere?
await act(async () => { | ||
jest.runAllTimers(); |
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.
if we're using jest.runAllTimers inside an act, we shouldn't need the await/async or await waitForNextUpdate
though it's probably a bit hairy because of the promise testing-library/react-hooks-testing-library#241
I'm not sure the best way to handle this :(
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.
given that you control the length of time on the timer, maybe only advance the timer by the expected amount?
runAll is a bit heavy and while useful in integration tests, probably not as useful in hook tests
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 don't quite follow the downside to using runAllTimers here.
Build successful! 🎉 |
This updates the
useAsyncList
hook to@react-stately/data
which manages data for an async list. It supports aborting duplicate network requests, ignoring all but the most recent result, error states, etc. It's implemented as a state machine usinguseReducer
, which helps ensure that we cover all possible state transitions.In addition, it adds the loading spinner and empty state to Table, and supports infinite scrolling and sorting on column headers. There's also some CollectionManager fixes to better detect when animated transactions are needed.