This issue doesn't imply that version 10 will be released any time soon. I just want a place to list some ideas so I won't forget them.
AutoSizer in favor of react-measure (based on the Resize Observer spec, can be polyfilled). This seems like a more future-friendly way of detecting resize.Table row-level event handler props in favor of an object (eg rowEventHandlers) that gets spread on each row. This will enable more flexible event event handling without requiring rowRenderer to be override while avoiding unsupported props warnings.WindowScroller, InfiniteLoader) out into their own packages to reduce the clutter and bundle size for people wanting _only_ windowing components? (This was suggested to me by a lib user. I haven't put much thought into it. Would probably also need to go hand-in-hand with using something like Lerna.)InfiniteLoader to be less row-centric (see #973)Currently I'm using only Table component (didn't have a chance to use other components) and got lot of custom editable columns like checkboxes, inputs and selects.
To make them reusable i'm using factories like that:
const createCheckboxColumn = props => (
<Column
width={56}
minWidth={56}
label={props.label}
dataKey={props.dataKey}
disableSort={true}
style={{ minWidth: `${56}px` }}
headerClassName={cx(props.headerClassName, classes.checkboxColumn)}
headerRenderer={() => (
<Checkbox
disabled={!props.rowCount}
value={props.allRowsSelected}
onChange={value => props.onAllRowsSelect(value)}
/>
)}
className={cx(props.className, classes.checkboxColumn)}
cellDataGetter={row => row.rowData}
cellRenderer={row => (
<Checkbox
value={props.rowSelected(row)}
onChange={selected => props.onRowSelect({ selected, ...row })}
/>
)}
/>
);
const table = (
<Table {...props}>
{createCheckboxColumn(checkboxProps)}
</Table>
);
Not sure if it's even a good idea in case of perf, but It would be great to have an option to make it work in "react way":
const table = (
<Table {...props}>
<CheckboxColumn {...checkboxProps} />
</Table>
);
You should be noticed react-measure works different than AutoSizer.
AutoSizer measures dimensions outside of container, it helps underlying components, like Grid to calculate visible rows. react-measure measures dimensions inside of container.
Just came across this. Was going to file an issue to see if you wanted to consider a ResizeObserver 馃槅 I'd be willing to help try and push this through. I would suggest using the polyfill direct. It's a pretty small amount of code to get it setup. As far as measuring goes, we can attach the observer to the parent node if we need to.
Cool. Thanks @souporserious. Sounds worth giving it a shot. Could maybe use a that API for CellMeasurer as well although I haven't given that much consideration.
When is "soon" as in the OP mentioned?
I wanted to put in RV in one of my project now and use AutoSizer but read now here that it will be deprecated "soon".
No, @pke. 馃槃 I definitely didn't say that it would be deprecated soon.
This issue doesn't imply that version 10 will be released any time soon.
This is just a placeholder issue for ideas that I don't have time to work on now, and I don't know when I _will_ have time to work on them.
Want to formulate my ideas
Prefer named exports over defaults for better treeshakability.
Prefer named exports over defaults for better treeshakability.
I assume you mean this about default exports of objects that contain many (non-tree-shakeable) keys?
It wouldn't actually make a difference in a case like:
export default SomeReactComponent
// vs
export SomeReactComponent
...right?
Not sure. I rely mostly on @Andarist issues.
I'd love to learn more if the above really does have an impact on tree shaking. I assume it does not.
From what i know there is no difference in named an default exports in terms of tree shakeability. default is just another named export which is treated in a little bit of special manner sometimes.
The problem with default export is that people sometimes use it in slightly wrong manner.
Exhibit A:
const Package = ...
Package.Other = ....
export default Package
Exhibit B
export default {
foo,
bar
}
What I think should not be dane is that a default export should not act as a namespace and should not gather other things that are intended to be reexported from the package.
thanks for clarifying 馃憤
Hi @wuweiweiwu,
Is there any info on version 10 release. I'm asking mainly in regards to this https://github.com/bvaughn/react-virtualized/issues/999#issuecomment-439072525.
@somi92 please follow the https://github.com/bvaughn/react-virtualized/milestone/1 milestone for updates!
Most helpful comment
Just came across this. Was going to file an issue to see if you wanted to consider a ResizeObserver 馃槅 I'd be willing to help try and push this through. I would suggest using the polyfill direct. It's a pretty small amount of code to get it setup. As far as measuring goes, we can attach the observer to the parent node if we need to.