We have the following React Component Hierarchy on a particular page.
<Page>
....
<GoogleMap> .... </GoogleMap>
....
<BoxList>
<Box>(lazy loaded 'n' at a time as you scroll and hit bottom, upto 400)
......(Some other box info that needs to be updated incrementally)
<ItemList>
<Item> (Upto 20 per Box/ItemList)
......(Some item Info that needs to be updated incrementally)
</Item>
<Item>...</Item>
....
</ItemList>
</Box>
<Box>....</Box>
....
</BoxList>
</Page>
On page load and as the user scrolls down, the top most component(Page) fetches the json for the next 'n' ( say, 10 ) Boxes and the data is passed all the way down to the (Box > ItemList > Item) as props and they get rendered.
We also receive small, incremental updates via pusher which need to be applied on to Box and Item components as they arrive. Since we were not sure how to go about this the React way, we are doing it the following way for Items.
a) Item components don't have any state as React docs recommend moving state into the immediate shared parent/ancestor component.
b) getInitialState() in ItemList simply clones this.props to generate its initial state. this.props is never used in the render function, it relies solely on this.state to render.
c) componentDidMount() in ItemList sets up listeners for Pusher updates and the handlers simply perform a setState({ data: data.merge(incremental_update)}) which trigger a re-render and new data is then passed down to Item as new props and are re-rendered.
Since there are a lot of ItemLists on the page ( upto 400 ) and since this.props is never really used by ItemList to render, what would be a better way to achieve this ? This app uses almost double the memory(100 MBs+ when all boxes are loaded) when compared to our original mutate-the-dom-with-jquery implementation(~50 MBs when all boxes are loaded) and becomes unusable on thin clients.
A related question that was the pre-cursor to this question.
