zeekayandHanzo Dev 486cae88c3 feat(market): read the item id from the indexer, and fall back to the chain
The id was recovered only from the chain's own Transfer logs, so the field the
indexer is about to start writing would have landed unused and every screen
would have kept paying for eth_getLogs to learn what it was already being told.

The indexer declares the id in two places on a transfer — token_id on the row
and token_id inside total — and neither is populated yet. Both are read, in
that order, the way the indexer itself falls through column spellings. idFor
asks the row before the log join, so one function answers "which item moved"
for every screen and nothing above it knows which source replied. The log read
is asked only about rows that arrive unnamed and does not run when there are
none, so it retires itself rather than being switched off.

/tokens/{addr}/instances is read for the same reason. It answers 200 and empty
for every collection today, so the collection page still recovers ids from one
page of transfers and says so — "50 of 149 items", not a slice presented as a
collection. When the resource fills, that list is preferred, whole, and carries
each item's own name and image; the item page takes its metadata from the same
record instead of fetching a gateway URI.

Verified against a mocked indexer carrying token_id: the ids render with the
chain RPC blocked entirely.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-29 18:19:03 -07:00
2022-11-29 18:04:37 -05:00
S
Description
Web3 marketplace for real-world assets (RWAs)
20 MiB
Languages
TypeScript 96.2%
CSS 2.5%
JavaScript 1.2%