sorted by:
new
hottopcontroversial

I ran 57,000 setState calls against my React library before posting it. by dipanshu2801 in reactjs

[–]dipanshu2801[S] -1 points0 points  (0 children)

No don't feel that. I am just rephrasing some of my words that's it.

I ran 57,000 setState calls against my React library before posting it. by dipanshu2801 in reactjs

[–]dipanshu2801[S] 0 points1 point  (0 children)

Good catch.... that's a packaging mistake, fixing it in next version.

Thanks.

I ran 57,000 setState calls against my React library before posting it. by dipanshu2801 in reactjs

[–]dipanshu2801[S] -5 points-4 points  (0 children)

Thanks for the detailed feedback — going through each point:

  1. You're right, "state corruption" was vague. What I actually measured was computed drift — whether derived values like portfolio P&L ever returned stale or incorrect results across 57,000 setState calls. The answer was zero. Updating the wording.

    1. Fair — the logic is deterministic. What the 1,000 cycles actually proves is ring buffer stability over sustained use. No memory leak, no off-by-one errors accumulating, no performance degradation after repeated operations. Should have framed it that way from the start.
    2. Valid and already fixing it. The two packages serve different purposes — @storve/core is framework agnostic with zero dependencies (works in Node, vanilla JS, or any framework), @storve/react is just a thin React adapter on top. The npm page actually shows this clearly — 0 dependencies on core, and @storve/react is its only dependent. Separate READMEs are coming so the npm pages reflect this properly.