document thrown errors

[giladgray]

This library seems to throw errors when receiving unexpected inputs, which has the unfortunate side effect of absolutely crashing my app (happened in production even, because I was not aware of some error states). Would love some notes in the docs about when the components will throw errors so I can prepare for them. Or, would love fewer thrown errors: a silent fail on out-of-bounds scrollToRow would be just fine by me, don't need to crash for that.

Here's what I've found so far:

• row/columnCount={0} will crash in render with "Invalid index 0"
• scrollToCell/Row/Index will crash if given out-of-bounds index (< 0, > count). (fwiw, JS itself doesn't crash when you access an array out of bounds, so I find this behavior quite unexpected.)

[bvaughn]

fwiw, JS itself doesn't crash when you access an array out of bounds, so I find this behavior quite unexpected.

JavaScript throws errors in some scenarios, like if you try to access a property of an undefined value (as is the case with an array of out bounds). This library isn't "crashing", it's just throwing an error because something unexpected like happened.

You should add error boundaries (or try/catch statements) to your app to more gracefully recover from unexpected scenarios like this.

row/columnCount={0} will crash in render with "Invalid index 0"

The library can render empty lists or grids (0 rows/columns) without any problems. It just renders an empty div.

It sounds like your application code is doing something additional that's causing the error to be thrown. On the one hand I think I understand where you're coming from but on the other hand, I think it's reasonable for this library to throw an error if scrollToRow is called with -1 for example (or a value higher than the total number of rows). There's nothing meaningful this library can do in that case except log or throw an error, and I chose to be more explicit about it and throw.

I don't mind updating the docs to be more explicit about which methods throw (would you like to post a PR that adds comments about this?). I also don't mind changing the error thrown to be more easily understood (since mentioning the cache is kind of an internal implementation detail).

I don't think I want to go down the road of catching and silencing errors though. I think it's reasonable to defer that to application code.

---

Edit: #880, published as v2.2.3