-
-
Notifications
You must be signed in to change notification settings - Fork 796
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
Just-in-time measured content [work in progress] #102
Conversation
Merging master into issues/6 branch
If the resulting ref was null, the old reference wasn't getting reset, and we'd end up re-observing the original node.
Any updates on this ? |
Fix item data not passed to DynamicSizeList itemKey
Fixed a memory leak in `ItemMeasurer`
Fix item data not passed to itemKey
May you inform about approximate date of merging this PR into master branch? |
I've found a behavior we may want to avoid. Basically, I have a virtual list inside a div that will be set to We could make ItemMeasurer customizable as a prop, so I could customize the resize observing logic. |
@natew what is the goal to set |
To prevent resizing the window from triggering paints within the entire parent container that includes that list. I don’t think you can claim it’s expected given you don’t have the use case. Re rendering on display none doesn’t make sense in this case. Further, if you display it again you see a flicker where the list items are all overlapped at top = 0 while it measures and then shows again. So it’s one bug and one extra render. One way to think of it being “expected” is to ask does it behave as similarly to a non-virtual list as possible. A non virtual list wouldn’t re render on display changes. I submitted a PR that let’s you override CellMeasurer. It’s not perfect, the bug still will happen without using a custom one, but it works for this case and maybe others. |
The built-in measuring solution needs to handle hidden/display:none as per the TODO item in the PR description:
I don't think requiring an overridden measurer is an approach I want to take. I'd rather this just work out of the box. I have a rough idea for how we might tackle it. |
Ah missed the todo, my bad. Totally agree that’s a better solution I was
thinking it was intended.
|
@natew I just ran into an issue like yours because my list lives in an It's not an ideal solution, but given that we're writing "in-the-meantime" hacks anyways, I found that using tab visibility to switch from a I know this is just a side project for you @bvaughn ; if you can explain your rough thinking on how you'd like to approach this, I'd be happy to lend a hand with writing up the final solution 👍 |
Hi! any chance 1.9.0-alpha.1 could be published? |
Hallo to fellow react-window users eager for this feature to be released. I ran into an issue with my CI/CD environment not properly building packages installed from git, so my prior workaround doesn't work for production deployment. In order to solve it, I forked and published the contents of this branch @ bc9192b as a scoped package:
In order to prevent myself from forgetting to update when the feature is released, I added a file which runs at buildtime and checks the most recent published version of const npmApi = require('npm-api');
const semver = require('semver');
const process = require('process');
const npm = new npmApi();
const reactWindow = npm.repo('react-window');
reactWindow.package().then((pkgJson) => {
let version = pkgJson.version;
if (semver.satisfies(semver.coerce(version), '>=1.9.0')) {
throw new Error(`react-window ${version} has been released, please uninstall this fork and reinstall react-window.`);
} else {
console.log(`\nMost recent react-window version is ${version}, DynamicList not yet available on npm.`);
console.log('This fork package will inform you when react-window @ 1.9.0 is available. \n')
}
}).catch((err) => {
console.log(`\n${err}\n`);
process.exit(1)
}); Obviously use at your own risk, as this PR isn't complete. Happy hacking! @renzosal @tony-scio @patryksuchowierski @Hellycat @jazevedo620 @satyadeepk Edit: Bringing over the sample code (Autosized list with FunctionComponent items) from my earlier comment so I only have one wall of text on this PR. Note the usage of
|
Initial implementation of a list component supporting just-in-time measured content (relates to issue #6).
Checklist
ResizeObserver
API is not available.findDOMNode
when no DOM element ref is available, but warn about this.