Stop the OrdersList refetch loop and the disabledClassName DOM leak

[acasazza]

What was happening

On a page rendering <OrderList>, the browser fired a request to orders (or order_subscriptions) roughly once a second, indefinitely. There is no timer involved — the rate simply equals the API round-trip time, because the effect that fetches retriggers itself.

Two independent routes closed the cycle, and both had to be cut.

1. The context rebuilt its callbacks on every fetch

useCustomerProviderValue memoized the whole context value with state among its dependencies, and spread ...state into it. So:

1. OrderList calls getCustomerOrders → GET /orders
2. the response does setState({...prev, orders}) → new state object
3. the memo re-runs → getCustomerOrders gets a new identity
4. OrderList has that callback in its effect deps → the effect runs again → back to 1

Fixed by splitting the value in two: a stable actions memo keyed only on what the callbacks actually close over (accessToken, customerId, interceptors, order, pageSize, withoutIncludes), and a thin outer memo that joins state and actions. The single callback that read state.addresses directly (createCustomerAddress) now reads it through a ref.

The callbacks still change identity when accessToken or customerId change, so a fetch still reruns when the token arrives. That property is why the callbacks were left in OrderList's dependency array rather than removed from it.

2. defaultSdkSorting was a fresh object on every render

const defaultSdkSorting = sortBy.length && sortBy[0] != null ? { ... } : undefined

A bare object literal, so a new identity on every render — enough to refire the effect even if the callbacks were stable. Now memoized on the primitives it derives from.

Where it came from

36a721d9 (v5.0.0-beta.0~11) widened the dependency array:

-  }, [pageIndex, currentPageSize, sorting, id != null])
+  }, [pageIndex, currentPageSize, sorting, getCustomerOrders, type, id, getCustomerSubscriptions, defaultSdkSorting])

4.29.7 is not affected.

Also in here: disabledClassName reaching the DOM

React does not recognize the `disabledClassName` prop on a DOM element.

Address declared disabledClassName in Props but did not destructure it, so it survived into the rest spread that lands on a <div>. It came loose in 1c85518b, the addresses-domain refactor, which also dropped the disabled branch — so in v5 the prop had no effect at all beyond polluting the DOM. It is now pulled out of the spread; the children-as-function form still receives it through parentProps, and the JSDoc says so.

4.29.7 is not affected here either.

Tests

specs/orders/order-list.refetch-loop.spec.tsx mounts <OrderList> inside the real Customer provider, with columns and sortBy passed as inline literals the way a consumer actually passes them.

Both new tests were checked against the unfixed source, so they are not vacuous:

	without the fix	with the fix
getCustomerOrders calls	32	1
disabledClassName on the DOM	attribute present	absent

Full suite: 1087 tests across 93 files, green.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for commercelayer-react-components ready!

Name	Link
🔨 Latest commit	c25c8ee
🔍 Latest deploy log	https://app.netlify.com/projects/commercelayer-react-components/deploys/6aaa6a8208dcbc0008f1aa8a
😎 Deploy Preview	https://deploy-preview-845--commercelayer-react-components.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[pkg-pr-new]

npm i https://pkg.pr.new/@commercelayer/core-components@845

npm i https://pkg.pr.new/@commercelayer/react-components@845

npm i https://pkg.pr.new/@commercelayer/react-hooks-components@845

commit: c25c8ee