Version 10 breaking changes

[bvaughn]

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.

• Remove 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.
• Remove individual 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.
• Maybe split some of the HOCs (eg 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.)
• Consider refactoring InfiniteLoader to be less row-centric (see #973)

[avocadowastaken]

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>
);

[nkt]

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.

[souporserious]

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.

[bvaughn]

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.

[pke]

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".

[bvaughn]

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.

[TrySound]

Want to formulate my ideas

• prefer resize-observer-polyfill to use chrome 64 feature and remove nonce prop
• find a way to not use findDOMNode maybe via ref callbacks in render props
• make WindowScroller universal for any component
• use WindowScroller in MultiGrid implementation and ScrollSync example
• find different examples of using ScrollSync. Freezing colums is bad case because of lagging and wheel blocking.
• remove scrollToRow, scrollToColumn, scrollToIndex in favor of ref public methods, since representing events/commands as state changing introduces a lot of bugs and inconsistences.
• Finish flow types
• remove proptypes babel plugin which generates untreeshakable commonjs

[TrySound]

• choose the name for SSR serverHeight/serverWidth -> defaultHeight/defaultWidth

[TrySound]

Prefer named exports over defaults for better treeshakability.

[bvaughn]

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?

[TrySound]

Not sure. I rely mostly on @Andarist issues.

[bvaughn]

I'd love to learn more if the above really does have an impact on tree shaking. I assume it does not.

[Andarist]

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.

[bvaughn]

thanks for clarifying 👍

[somi92]

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.

[wuweiweiwu]

@somi92 please follow the https://github.com/bvaughn/react-virtualized/milestone/1 milestone for updates!