Frontend Minting and Integration Flashcards

When a frontend reads an NFT's tokenURI that starts with 'ipfs://', what must it do to fetch the metadata over HTTP?

Answer: Resolve it through an IPFS gateway URL

Browsers can't fetch ipfs:// directly, so the URI is rewritten to a gateway like https://ipfs.io/ipfs/.

An NFT's metadata JSON contains an 'image' field. According to common standards, what should the frontend render it as?

Answer: A URL pointing to the image asset (often IPFS or HTTP)

The ERC-721 metadata 'image' field is a URI the frontend loads to display the artwork.

Why might a frontend cache fetched NFT metadata rather than re-requesting it on every render?

Answer: Metadata is typically immutable on IPFS, so caching reduces gateway load and latency

Pinned IPFS metadata rarely changes, so caching avoids repeated slow gateway requests.

What is a robust pattern for handling an NFT image that fails to load from one IPFS gateway?

Answer: Fall back to an alternative gateway via the onError handler

Using onError to try a backup gateway makes image display resilient to a single gateway outage.

When displaying a collection, why is calling 'balanceOf' then 'tokenOfOwnerByIndex' only possible if the contract implements a certain extension?

Answer: It requires the ERC-721Enumerable extension

tokenOfOwnerByIndex is part of ERC-721Enumerable, which not all NFT contracts implement.

What does the 'attributes' array in standard NFT metadata typically power on a frontend?

Answer: Display of traits and rarity properties

The attributes array holds trait_type/value pairs that frontends render as the NFT's properties.

If a tokenURI returns base64-encoded JSON inline (on-chain metadata), what must the frontend do before parsing it?

Answer: Decode the base64 data URI to get the JSON string

On-chain metadata is delivered as a data:application/json;base64 URI that must be decoded before JSON.parse.