Why does my app produce hydration errors when rendering VirtualizedList?

[DavidRieman]

I'm having trouble setting up any kind of responsive virtualized list that just works. I'd run into a number of issues, but this one has multiple side effects that are super baffling. I'm putting my code through the react-native-web examples (just replacing the flatlist/index.js) and the results are the same whether on 17.5, 17.7, or even with my VirtualizedList upgrades branch in play.

The initial rendered items after a page refresh seem to be rendering as if the window width is zero. Console logging seemed to suggest that we're only rendering items with the intended width, but that's clearly not true. (I've now confirmed that Chrome's console log somehow misses the console.log entries that do attempt to get logged during first renders. Weird. But putting code like if (!width) explode(); does explode as expected.)

Then I see weird generic "Warning: prop style did not match" error that doesn't have enough detail to be clear why it exists or what the real problem is.

As soon as you do anything to cause another render, like drag the window a pixel wider, everything renders great.

Here's the code I'm using for this:

import React, { useMemo } from 'react';
import Example from '../../shared/example';
import { Text, useWindowDimensions, View, VirtualizedList} from 'react-native-web';

const bigListData = Array(200).fill(0).map((element, index) => index);
function getItemCount(data) { return data.length; }
function getItem(data, index) { return data[index]; }
function keyExtractor(item) { const key = `item-${item}`; return key; }

function createListConfig(width) {
  const rowHeight = 100;
  const viewHeight = rowHeight - 10;
  const itemWidth = Math.max(width / 2, 22);
  console.log(width, itemWidth);
  const evenStyle = {
    backgroundColor: 'red',
    height: viewHeight,
    width: itemWidth,
    marginLeft: '5%',
    marginBottom: 10
  };
  const oddStyle = {
    backgroundColor: 'green',
    height: viewHeight,
    width: itemWidth,
    marginLeft: '5%',
    marginBottom: 10
  };
  const renderer = ({ item }) => {
    const key = `i_${item}`;
    return <View key={key} style={item % 2 ? oddStyle : evenStyle}>
      <Text>{key}, viewHeight: {viewHeight}, offset: {rowHeight * item}</Text>
    </View>;
  };

  return { renderer };
}

function ResponsiveList() {
  const { width } = useWindowDimensions();

  const config = useMemo(() => createListConfig(width), [width]);

  return <VirtualizedList
    data={bigListData}
    getItem={getItem}
    getItemCount={getItemCount}
    initialNumToRender={4}
    key='rwl-v-list'
    keyExtractor={keyExtractor}
    renderItem={config.renderer} />;
}

export default function FlatListPage() {
  return (
    <Example title="FlatList">
      <ResponsiveList />
    </Example>
  );
}

To repro, we can:

• Paste that code over one of the examples pages.
• yarn examples.
• Visit that page in localhost:3000 (in Chrome?)
• Open the Dev Tools panel.
• Refresh the page.

It was weird that first console.log calls get missed by Chrome Dev Tools, but seems unlikely to be a react-native-web problem. (Maybe a weird Chrome optimization.) So let's skip that.

It seems weird that useWindowDimensions is wrong on first read, but I can live with that - in this case I'd have to not render the List at all if width is 0. That may be get resolved during splash screens and the like for most real apps, but not the end of the world if (people in the know get to) apply an "if width <= 0, early out with blank view" work-around.

But why doesn't the VirtualizedList re-render those first 4 items when the renderer function changed? Is that a clue to the prop style did not match output - does some system notice that two renderings of an item in the list produced differing styles? Are responsive UI not technically supported while virtualizing? Perhaps this is exposing a timing bug? Maybe bad things will happen if you happen to catch any virtualizing list right between the initial items render and the second pass with a renderer-prop change... but the app refresh scenario is just the easiest way to repro the timing consistently?

[necolas]

You can't expect the width to be accurately known on the server, nor does it look like the width is needed, as the items should horizontally expand to fill the scroll container

[DavidRieman]

What do you mean by "known on the server"? The useWindowDimensions React Hook is fully client-side logic, isn't it?

[necolas]

The warning you're talking about is a server/client HTML rendering mismatch