DEV Community: WingsDevelopment

Handling Multiple Data Sources in DeFi Frontend Architecture

WingsDevelopment — Tue, 27 Jan 2026 09:54:06 +0000

Since a lot of people showed interest in my last blog post about architecture, I decided to start a blog series to address common questions and dilemmas you might be facing.

Context: Why This Series Exists

If you haven’t seen it yet, this post is a continuation of a previous article I wrote while working on Euler’s frontend architecture:

The Architecture That Fixed Euler’s Frontend Performance

Taking a deeper look at fetch → mapper → UI approach:
The Web2 Mental Model Doesn’t Work in Web3

Introduction

Let’s begin by focusing on architectural problems and the bigger picture.

One of the most common issues in front-end applications is handling data fetching from multiple sources. On the happy path, everything works fine, but the real question is:

What happens when one or more of those sources fail?

In DeFi applications, data usually comes from multiple places:

the blockchain (RPC),
subgraphs,
third-party services (Merkle distributors, reward APIs),
price feeds, and similar APIs.

Not every query has or should have all of these dependencies tightly coupled together.

But let’s look at a simple example that almost every DeFi app needs:

Fetch token balances, display them in a table, and also show the total value in USD.

At first glance, this looks trivial.

In practice, it’s not.

The Core Problem

With a typical hook-based approach, the main issue is that these requests are not synchronous.

There’s no reliable way to know when all balances, symbols, decimals, and prices have been fetched.

And poor UX is only one reason to look for a different approach. There are many others:

Proper caching — reducing RPC call costs
Leveraging wagmi batching
Minimal query cache invalidation
Cleaner code and easier maintenance
Better testability
Increased robustness and fewer bugs

A Mapper-Based Approach

Let’s start with a mapper-based solution.

Here’s an example of a balancesMapper that:

fetches balances,
fetches token prices,
calculates the total USD value.

While fetchers are handling caching under the hood, more on this here.

export async function balancesMapper(params: {
  tokens: Address[]
  account: Address
  options?: BalancesMapperOptions
}): Promise<DisplayBalances> {
  const { tokens, account, options } = params

  const [balances, pricesResult] = await Promise.all([
    // Let wagmi batch these RPC calls
    // If this fails, the whole mapper fails
    Promise.all(
      tokens.map((token) =>
        balanceMapper({ token, account, options })
      )
    ),

    // Different data source (HTTP fetch), so we make this safe
    // If this fails, we can still display balances
    safeCall(() => tokenPricesMapper({ tokens, options })),
  ])

  const totalValueUsd: SafeResult<ViewNumber | undefined> =
    pricesResult.error
      ? { data: undefined, error: pricesResult.error }
      : {
          data: calculateTotalValue(balances, pricesResult.data),
          error: undefined,
        }

  return { balances, totalValueUsd }
}

Here we’re fetching data from two different sources:

the blockchain (balances),
a price API.

From a UI perspective, the goal is to display as much information as possible.

If the price API fails → we can still show balances.
If the RPC call fails → price data becomes useless in this scenario.

So this query should fully fail if the RPC call fails, but partially degrade if the price API does.

Designing a Mapper Starts With the UI

When creating a query mapper, the first question should not be:

“How do I fetch this data?”

It should be:

“What does the UI actually need, and what is it allowed to show if parts of this fail?”

This is the most important responsibility of a mapper.

A mapper is not just a place to combine fetch calls — it’s where you define failure boundaries.

For every mapper, you should explicitly decide:

Which data is required for the UI to function
Which data is optional and can fail without breaking the experience
When partial data is acceptable
When the entire query should be considered failed

In the balances example above, that decision is intentional:

Balances are required

If fetching balances fails, the UI cannot function — the mapper fails.
Prices are optional

If price fetching fails, we still render balances, but we show totalValueUsd as unavailable and expose the error for the UI.

This is the key difference versus hook-heavy composition:

the UI no longer needs to re-implement “what is allowed to compute right now?” on every screen.

Also, remember: this mapper is not an “ultimate solution.” You should still separate concerns as much as possible.

But when you do need to merge data, a mapper is the right place to make explicit decisions about partial failure and full failure.

And don’t be afraid to reuse the same cache with different mappers. If tokenPricesMapper is already caching prices, a prices-only view can reuse it without refetching or duplicating logic.

The `safeCall` Wrapper

To support partial failures, we use a small utility:

export interface SafeResult<T> {
  data: T | undefined
  error: Error | undefined
}

export async function safeCall<T>(
  fn: () => Promise<T>
): Promise<SafeResult<T>> {
  try {
    const data = await fn()
    return { data, error: undefined }
  } catch (error) {
    return { data: undefined, error: error as Error }
  }
}

This prevents errors from being thrown while still exposing them to the caller.

Your UI can now say:

“Here are your balances, but I couldn’t fetch price data because of this error.”

That’s a first-class, explicit state, not an accidental side effect.

Cache Reuse and Separation of Concerns

You might be wondering:

“What if I want to display token prices even if I can’t fetch balances?”

For example:

ETH = $30k
BTC = $90k

That’s the beauty of this approach — we’re already calling tokenPricesMapper, which caches pricing results.

A prices-only screen or widget can reuse the same cached data without duplicating logic or triggering additional requests.

This separation of concerns also gives us clean and predictable cache invalidation, but more on that in a later post.

Comparison: A Hook-Heavy Approach

Now let’s implement the same feature using a more traditional, hook-heavy pattern.

We’ll pretend we have standard hooks that internally call plain fetch functions:

useBalances() → balanceOf
useTokenSymbols() → symbol
useTokenDecimals() → decimals
useTokenPrices() → price API

No mappers involved.

export function useDisplayBalancesWithHooks(
  tokens: Address[] | undefined,
  account: Address | undefined,
  settings: SimulationSettings = {},
): UseDisplayBalancesResult {
  const { simulateLoading, simulatePriceError, simulateRpcError } = settings
  const enabled = Boolean(tokens?.length && account)

  const balancesQuery = useBalances({ tokens, account, enabled, simulateRpcError })
  const symbolsQuery = useTokenSymbols({ tokens, enabled, simulateRpcError })
  const decimalsQuery = useTokenDecimals({ tokens, enabled, simulateRpcError })
  const pricesQuery = useTokenPrices({ tokens, enabled, simulatePriceError })

  const isBalancesLoading =
    simulateLoading ||
    balancesQuery.isLoading ||
    symbolsQuery.isLoading ||
    decimalsQuery.isLoading

  const isBalancesError =
    Boolean(balancesQuery.error) ||
    Boolean(symbolsQuery.error) ||
    Boolean(decimalsQuery.error)

  const isPriceLoading = pricesQuery.isLoading
  const isPriceError = Boolean(pricesQuery.error)
  const priceError = (pricesQuery.error as Error) ?? null

  const balances = useMemo((): DisplayBalance[] => {
    if (!tokens?.length) return []

    return tokens
      .map((token, index) => {
        const rawBalance = balancesQuery.data?.[index]
        const symbol = symbolsQuery.data?.[index]
        const decimals = decimalsQuery.data?.[index]

        if (rawBalance === undefined || !symbol || decimals === undefined) {
          return null
        }

        return {
          address: token,
          rawBalance,
          symbol,
          decimals,
          balanceFormatted: formatBigIntToViewTokenAmount({
            bigIntValue: rawBalance,
            symbol,
            decimals,
          }),
        }
      })
      .filter((b): b is DisplayBalance => b !== null)
  }, [tokens, balancesQuery.data, symbolsQuery.data, decimalsQuery.data])

  const totalValueUsd = useMemo(() => {
    if (isBalancesLoading || isBalancesError || balances.length === 0) {
      return undefined
    }

    if (pricesQuery.isLoading || pricesQuery.isError || !pricesQuery.data) {
      return undefined
    }

    return calculateTotalValue(balances, pricesQuery.data)
  }, [
    isBalancesLoading,
    isBalancesError,
    balances,
    pricesQuery.isLoading,
    pricesQuery.isError,
    pricesQuery.data,
  ])

  return {
    balances,
    totalValueUsd,
    isBalancesLoading,
    isBalancesError,
    isPriceLoading,
    isPriceError,
    priceError,
  }
}

What’s Actually Happening Here

Most of this hook is not business logic — it’s coordination logic:

Merging multiple async sources
Defining what “loading” means across queries
Deciding which errors are fatal and which are optional
Preventing UI glitches
Aligning data by index across hooks
Figuring out when it’s safe to compute derived values

In other words, a hook-heavy approach forces you to repeatedly answer:

“What is the app allowed to calculate right now?”

And that logic tends to leak into every screen.

Demo

If you prefer seeing these ideas in action instead of just reading about them, I’ve put together a small interactive demo that showcases the patterns discussed in this post.

Live demo:

https://react-clean-code-tutorials.vercel.app/

Repo:

https://github.com/WingsDevelopment/react-clean-code-tutorials

Summary

Fetching from multiple async sources is the real complexity in DeFi front ends.
Hook-heavy solutions push orchestration logic into UI layers.
Mapper-based approaches make data fetching atomic, predictable, and testable.
Partial failures become explicit, not accidental.
Cache reuse and invalidation become easier by design.
UI focuses on rendering, not coordination.

What’s Next?

Planned follow-up posts:

useQueries vs Promise.all: Understanding the Differences
Selectors vs Mappers: Understanding the Trade-offs
Proper Data Mapping: Format Once, Display Many Variations
Perfect Caching Mechanism: Saving Money on RPC Calls without Increasing Development Cost

I’d love input from the community:

What would you like to understand better next?

caching strategies?
error handling?
testability?
performance trade-offs?

Let me know — the next posts will be driven by that.

The Architecture Mistakes That Slowly Kills Large React Projects

WingsDevelopment — Sat, 27 Dec 2025 10:38:01 +0000

Problems:

Too much data on the client
Overuse of useMemo
React Query becomes too complex for on-chain fetching
Unpredictable re-renders
Hard-to-maintain hook logic
Abstractions created too early that can’t evolve with the project

Introduction

Modern DeFi front-ends try to provide maximum transparency:

everything fetched on-chain, everything computed live, everything reactive.

This works beautifully at the beginning.

You have a clean UI, a few contract calls, a couple of hooks, and everything feels manageable.

But as the project grows, so does the data:

more vaults
more markets
more balances
more derived state
more APYs
more user positions

Suddenly your front-end is doing the job of a backend + database, but inside React components.

Small mistakes from the early days, a helper hook here, an abstraction there — start to pile up.

More conditions, more memos, more state.

Before you notice, you're fighting complexity you never intended to create.

This post explains why this happens, why React Query becomes extremely tricky in web3, and how a simple architecture, fetch → mapper → hook — solves these problems permanently.

Too Much Data on the Client

As our datasets grew, we realized not everything needs to be fetched live from the chain.

Some data is expensive to compute, rarely changes, or is aggregated from many sources.

So we shifted specific classes of data to a backend (or subgraph/task worker), then consumed it with the Fetch → Mapper → UI pattern.

But Isn’t This Pattern Less Useful If You Already Have a Backend?

You might argue that the Fetch → Mapper → UI architecture becomes less necessary once you introduce a backend.

But here’s the reality:

Even with a strong backend, you will always have data that must come directly from the chain.

These values are too time-sensitive, user-specific, or transaction-gating to safely offload to a backend.

This creates an unavoidable challenge:

Your front-end must merge two different worlds:

Backend-provided data (cached, aggregated, slow-changing)
On-chain data (live, reactive, per-user)

The Fetch → Mapper → UI pattern is exactly what makes this possible.

The fetchers isolate how and where the data comes from (BE or chain).
The mappers combine, normalize, format, and reconcile those two sources.
The UI receives a single, clean, stable data object — without knowing (or caring) whether it came from RPC, BE, or both.

Overusing `useMemo`

In a traditional app, the backend prepares data for you.

In web3, the blockchain gives you raw, primitive state, you must compute everything yourself.

More data → more derived calculations → more useMemo.

While having only 10 vaults, even if you have 20 memos per vault, its not a big issue, but once number of vaults grow..

10 vaults → 200 memos
500 vaults → 10k memos!

Every re-render triggers:

dependency comparisons
recalculations
diffing
memory usage
race conditions

As data grows, the number of “safe mistakes” drops to zero.

A single unstable dependency crashes performance.

React query is too hard in web3 for on-chain fetching

I have reviewed a lot of projects in DeFi and many of us tried to use useQuery like in web2 application, making a huge mistake.

You might wonder why does it matter for react-query if I am building web2 or web3 application, i am just making RPC calls instead of a HTTP right? Well its not that simple.

In web2 you have database, or BE service, that is calculating, formatting, joining the data and you get 1 hook - 1 query - everything you need.

While in web3 you have only chain, that is much more primitive, and you have to do what would DB do for you in FE, so you end up having situation that looks more like this:

And you might think, its not a big deal,

You start by thinking, “I’ll just add an if in the enabled field so it fetches only when needed.”

Then you add some custom refetch logic to the queryKeys.

Then you calculate combined loading and error states across multiple useQuery hooks.

Maybe you even sprinkle in a little caching or a manual refetch call “just to handle an edge case.”

And before you realize it, you’ve built hooks on top of hooks, hundreds of lines deep — full of branching conditions, complex dependency rules, and no straightforward if, else, or loops. It becomes hard to follow, hard to debug, and even harder to maintain.

Take a look at simple but still confusing hook-heavy approach:

 // 1: Fetch vault
const {
  data: vault,
  isLoading: isVaultLoading,
} = useVault({
  address: vaultAddress,
  query: { refetchOnMount: false },
})

// 2: Fetch Net Asset Value (depends on vault)
const {
  data: netAssetValue,
  isLoading: isNetAssetValueLoading,
} = useNetAssetValue({
  accountAddress: account,
  vaultAddress,
  enabled: Boolean(vault),                 // enabled #1
})

// 3: Fetch APY (also depends on vault)
const {
  data: apy,
  isLoading: isApyLoading,
} = useApy({
  account,
  vaultAddress,
  enabled: Boolean(vault),                 // enabled #2
})

// Global loading state becomes:
const isLoading =
  isVaultLoading ||
  isNetAssetValueLoading ||
  isApyLoading

// todo errors.. and other things..

This also means that for every data point, we now have not only the value itself but an entire bundle of React Query state attached to it - loading, error, status flags, fetch timestamps, and more.

And because most of these hooks depend on each other, the entire composite hook becomes “loading” if any of the underlying queries are loading. In practice, you need all the data anyway, so the multiple useQuery calls end up serving only one purpose: caching.

Which leads to an obvious question:

Why not simply fetch everything together instead?

// example mapper 
// 1. Fetch the vault (required) and await for it!
const vault = await fetchVault(vaultAddress)

// clear failure path, no helper flags in React
if (!vault) throw new Error("Vault not found")

// 2. Fetch dependent values in parallel
const [netAssetValue, apy] = await Promise.all([
  fetchNetAssetValue({ accountAddress: account, vaultAddress, }),
  fetchApy({ account, vaultAddress }),
  // easily add more in a single line!
])

// 3. Return fully composed result
return { vault, netAssetValue, apy }

Much easier to read!

After fetching everything in mapper, you simply wrap the entire operation in a single useQuery. This gives you reactivity, loading and pending states, error handling, and all the other benefits of React Query - without scattering logic across multiple hooks.

Much easier to read, maintain, and reason about, right? In my opinion: absolutely yes.

But the next question is that you might be thinking of is:

“What about caching?”

This is where things get interesting.

React Query also provides a non-hook API through the queryClient.

When I discovered queryClient.fetchQuery for the first time, it completely changed the way I approached data fetching. You can access the same query client you initialized at the root of your project and call .fetchQuery() anywhere - with full support for staleTime, refetchOnWindowFocus, retries, and all other React Query options.

Here’s a simple example of a fetch function that retrieves the owner of a vault and caches it for 30 minutes:

export const getOwnerQueryOptions = (
  vaultAddress: Address,
  chainId: number,
) => ({
    // readContractQueryOptions utils from wagmi
  ...readContractQueryOptions(getWagmiConfig(), {
    abi: eulerEarnAbi,
    address: vaultAddress,
    chainId,
    functionName: "owner",
    args: [],
  }),
    staleTime: 30 * 60 * 1000, // <- cache smallest part of the data
});

export async function fetchOwner(vaultAddress: Address, chainId: number) {
  const result = await getQueryClient().fetchQuery( // <- fetch query from query client
    getOwnerQueryOptions(vaultAddress, chainId),
  );

  return result;
}

This means that whenever you use this fetch function inside a higher-level operation, the call is already cached - no need to define caching logic anywhere else.

With this pattern in place, the large, complicated hook I showed earlier has no reason to call hooks inside hooks anymore. It can simply call plain fetch functions.

Now imagine the requirements change.

For example, before fetching anything, you now need to check whether a vault is verified and throw an error if it isn’t.

In the old hook-based approach, you would need to update every internal hook, add enabled conditions, and touch ~10 different places.

With plain fetch functions, the change becomes trivial - you just write something like:

const isVerified = await fetchIsVerified(debt?.vault);
if (!isVerified) throw new Error(”Vault is not verified”); // <- you can use if! 
// … rest of the code here…

You may also start running into issues when calculating the final state.

Maybe you weren’t handling certain error cases before and now you need to.

Maybe you need to understand exactly when individual queries are refetching.

With the hook-heavy approach, this becomes complicated quickly, and a lot of unexpected behaviors can occur.

Unpredictable re-renders

This problem naturally emerges from the previous issues.

When your data layer becomes too reactive and too tightly coupled to multiple hooks, the UI starts re-rendering in ways that feel random or impossible to control.

The first instinct is always the same:

“Let’s just wrap it in useMemo.”

But useMemo doesn’t eliminate complexity — it adds more:

another dependency array
another equality check
more memory
another place things can go wrong

Instead of stabilizing your UI, you now have yet another reactive layer to manage.

Let’s do some math.

Imagine a hook that internally uses:

7 different useQuery calls → 7 query keys
several formatting or sorting operations wrapped in useMemo → 3–5 more dependency arrays

You’re now maintaining 10+ separate dependency arrays, all of which React must compare on every render, for every feature that uses this hook.

As the app scales:

the number of dependency arrays increases
the number of query keys explodes
one unstable reference triggers a cascade
the UI becomes harder to predict
small mistakes cause large re-render storms

Even if every dependency is “correct,” React still needs to store all these arrays in memory and compare them constantly. Multiply this across dozens of components and the cost becomes significant.

This is why “just add more useMemo” is not a performance strategy — it’s a sign the architecture needs to be simplified.

Fetch - mapper - hook layers for getting the data

Moving away from the way we fetched data helped us get rid of all of this things as well, we introduced 3 layers when fetching data,

fetch functions (which we already covered in fetchOwner example,
mappers layer before useQuery that calls as many fetch function
and at the end useQuery to wrap this mapper and get reactivity for UI

I already partially covered why do we need this, but if you are interested to see diagram and more details about this approach maybe you can check out THIS BLOG.

Creating abstractions in early stage that can’t support project evolution

This is a mistake nearly every team makes at some point, myself included. In the early stages of a project, you often don’t fully understand the real data flows, the real scale, or how features will evolve.

You create abstractions with the best intentions: to be clean, reusable, “future-proof.” But the truth is that early abstractions usually aren’t future-proof at all. They’re built on assumptions that later turn out to be wrong.

Final thoughts

React Query is an amazing library, but web3 is fundamentally different from web2. You can’t treat on-chain RPC calls the same way you treat HTTP endpoints. When you try to, you end up with:

Massive nested hooks
Too many queries
Broken loading/error states
useMemo everywhere
Unpredictable renders
Complex dependency arrays
Hooks that grow to 500–800 lines before anyone notices

By moving fetching out of hooks, simplifying the pipeline, and letting Promise.all do the heavy lifting—while still using React Query for reactivity—you get a far cleaner architecture:

Debuggable
Predictable
Performant
Scalable
Easy to maintain

And most importantly:

Your front-end stops fighting the blockchain - and starts working with it.

The Web2 Mental Model Doesn’t Work in Web3

WingsDevelopment — Sat, 27 Dec 2025 10:31:05 +0000

The Right Way To Fetch On-Chain Data

Goals of this Post

Developer friendliness
Performance improvements
Simpler code maintenance
Smarter caching
Easy, predictable data invalidation

Also the goal here is not to build the perfect, all-encompassing abstraction that works for everyone.

The goal is to create a simple, scalable baseline that any developer can understand, adopt quickly, and extend as their project grows.

React Query completely changed the way many of us think about data and state in React. It’s an incredible library - but in web3, a lot of us (myself included) were unintentionally using it the wrong way.

Let’s explore why.

The Web2 Mental Model Doesn’t Work in Web3

In a typical web2 front-end, you fetch well-prepared data from a backend or database - a single source of truth:

It’s clean. One request → one response → one useQuery.

But in web3, your "backend" is:

multiple contracts
multiple RPC endpoints
multiple formats
sometimes a subgraph
and no server to aggregate or prepare data

So the exact same UI ends up looking more like this:

And this is where things go wrong.

Fetching data from 3 contracts?

You now have:

3 different hooks
3 sets of enabled logic
3 query keys
3 loading/error states
memoized transformations on top
selectors
sorting
re-renders caused by unstable references

It becomes too complex. Too reactive. Too hard to maintain.

A single hook grows to 500+ lines of conditions and nested hooks.

So what do we do?

We go back to what works.

A Simpler Model: Fetch → Mapper → UI

We borrow inspiration from backend architecture — where systems typically have three layers:

Presentation
Services
Infrastructure

For web3 front-ends, the equivalent becomes:

UI → Mappers → Fetchers

This model restores predictability, improves performance, simplifies debugging, and keeps caching under control.

Let’s break it down.

Layer 1 — Fetchers (RPC/Network + Cache)

The fetch layer is responsible for:

Implementing the actual RPC / HTTP call
Caching it using React Query’s non-hook API
Nothing else

This is the key insight:

You do not use hooks in this layer. Get queryClient directly instead of useQueryClient.

You use:

queryClient.fetchQuery()

React Query still handles:

caching
staleTime
retries
background updates
and all other non reactive aspects from fetchQuery

But without introducing reactivity where it doesn’t belong.

Take a look at the example of how to fetch decimals, balance and use mapper to map those values:

export const getTokenDecimalsQuery = (token: Address, chainId: number) => ({
  ...readContractQueryOptions(getWagmiConfig(), {
    abi: erc20Abi,
    address: token,
    chainId,
    functionName: "decimals",
    args: [],
  }),
  staleTime: Infinity,
});

export async function fetchTokenDecimals(token: Address, chainId: number) {
  return getQueryClient().fetchQuery(getTokenDecimalsQuery(token, chainId));
}

^ Here, the fetcher caches the token decimals forever.

export const getTokenBalanceQuery = (
  token: Address,
  chainId: number,
  account: Address,
) => ({
  ...readContractQueryOptions(getWagmiConfig(), {
    abi: erc20Abi,
    address: token,
    chainId,
    functionName: "balanceOf",
    args: [account],
  }),
  staleTime: 1 * 1000, // 1 minute
});

export async function fetchTokenBalance(
  token: Address,
  chainId: number,
  account: Address,
) {
  return getQueryClient().fetchQuery(
    getTokenBalanceQuery(token, chainId, account),
  );
}

^ Here, the fetcher caches the balance for 1 minute.

No matter:

which mapper calls it
how many screens use it
how many components reference it

This RPC call balanceOf only happens once every 1 minute at most. (Or only once in decimals case)

Your UI stays fast, your app stays stable, and caching stays centralized.

Layer 2 — Mappers (Business Logic & Data Shaping)

The mapper layer is where everything comes together.

It:

understands what the UI needs
understands how the chain/API supplies data
calls multiple fetchers
formats and derives values
combines data into a clean, ready-to-use structure
uses plain JS (if/else, map, for, switch, early returns)

Because fetchers are non-hook functions, mappers are also non-hook functions.

So you can use normal control flow without React’s limitations.

This is where complexity shrinks by 10x.

Here is the example

import { formatBigIntToViewNumber, ViewNumber } from "react-display-value"

export async function displayBalanceMapper(params: {
  token: Address;
  chainId: number;
  account: Address;
}): Promise<ViewNumber> {
  const { token, chainId, account } = params;

  // Fetch metadata (forever cache) + balance (1m cache) in parallel
  const [decimals, symbol, rawBalance] = await Promise.all([
    fetchTokenDecimals(token, chainId), // usually hits the cache (only first time doesn't)
    fetchTokenSymbol(token, chainId), // usually hits the cache (only first time doesn't)
    fetchTokenBalance(token, chainId, account), // fresh every minute
  ]);

  return { 
        // format (prepare) your value for view, don't let raw values go any further
      balanceFormatted: formatBigIntToViewNumber(rawBalance, decimals, symbol)
  };
}

Mappers become the business logic brain of your project.

This mapper is simple and clean,
compare it with "hook-heavy" approach, imagine you try to build anything more complex using the traditional “hook-heavy” pattern - with a separate useQuery for every tiny data point - things quickly spiral out of control:

multiple enabled conditions
multiple loading/error states
nested hooks
deeply branching logic
no clean way to return emptyState early
no way to throw error early

Worse, the moment you need to fetch data for anything dynamic - lists of tokens, vaults, markets, positions, etc. — the hook-heavy approach falls apart. Mapping over an array now requires useQueries, which introduces even more reactivity, more conditions, and still doesn’t solve conditional fetching cleanly.

No easy gold old for loop to fetch things!

You need sortable data for table? Not a problem lets just create displayBalancesMapper :

export async function displayBalancesMapper(params: {
  tokens: Address[];
  chainId: number;
  account: Address;
}): Promise<DisplayBalanceRow[]> {
  const { tokens, chainId, account } = params;
  if (!tokens?.length) return []; // simple empty array return

  // Kick off all token rows in parallel; cache handles duplicates efficiently
  const rows = await Promise.all(
    tokens.map((token) =>
      displayBalanceMapper({ token, chainId, account }),
    ),
  );

  // Example: sort descending by normalized amount (for UI tables)
  rows.sort((a, b) => b.sortKey - a.sortKey);

  return rows;
}

Layer 3 — UI (Dumb Components, Smart Data)

Once data reaches the UI layer, everything is simple again.

UI components should:

display formatted data
avoid domain logic
avoid calling fetchers
avoid doing chain calculations
rely entirely on React Query cache and mapper output

The UI and hook should be "dumb":

export function getDisplayBalanceQuery(
  token?: Address,
  chainId?: number,
  account?: Address,
) {
  return {
    queryKey: ["useDisplayBalance", chainId, token, account] as const,
    queryFn: () => displayBalanceMapper({ token: token!, chainId: chainId!, account: account! }),
    enabled: Boolean(token && chainId && account),
    // UI-level “hide mapper” cache to reduce re-renders from formatting
    staleTime: 30_000, // 15s window; tweak 15sec–1min as needed
  };
}

export function useDisplayBalance(
  token?: Address,
  chainId?: number,
  account?: Address,
) {
  return useQuery(getDisplayBalanceQuery(token, chainId, account));
}

And formatting should already be done long before rendering:

import { DisplayTokenValue, DisplayTokenAmount } from "react-display-value"

// handels loading, error states but also renders values perfectly
// example: <span customStyleHere>$</span><span customStyleHere>34.22</span> and more..
<DisplayTokenValue {...rest} {...data?.balanceFormatted} />
// user sees '$42.22' with option to style $ sign separetely

For example, using the number formatting logic from our new library that does heavy lifting and keeping things broad enough so that mapper can satisfy any UI needs:

👉 https://github.com/WingsDevelopment/react-display-value

This removes the need for useMemo entirely.

Every piece of data you render is already:

formatted
normalized
rounded
signed
symbolized
display-ready

Your useQuery in the UI becomes nothing more than a reactive wrapper around a mapper:

useQuery({
  queryKey: ["something", params],
  queryFn: () => mapper(params),
});

No complexity.
No extra fetching.
No nested hooks.

Preventing Unnecessary Re-renders With UI-Level Cache

Here’s another powerful trick:

You can “hide” your mapper inside a useQuery with a short cache window (e.g. 15–60 seconds or more).

This way:

heavy formatting
expensive maps
large number reductions
symbol/sign parsing
and other CPU-heavy mapping logic

…will run once every 15–60 seconds or what ever your need is, even if the component re-renders multiple times.

This turns the mapper into a mini “UI cache layer,” which dramatically reduces re-renders and CPU churn in complex dashboards or tables.

It’s an incredibly simple optimization, but the payoff is huge, especially in data-heavy DeFi applications.

Final Thoughts

React Query is powerful - but web3 and on-chain data fetching changes how we must use it.

The traditional approach (lots of hooks, lots of memos, lots of reactivity) breaks down as soon as your application grows beyond a handful of RPC calls.

By adopting the Fetch → Mapper → UI architecture:

✔ You isolate complexity

✔ You centralize caching

✔ You remove nested hooks

✔ You avoid re-render storms

✔ You keep React Query exactly where it belongs

✔ You get predictable behavior even at scale

✔ You make your codebase far easier to maintain

This approach doesn’t try to solve everything.

It gives you a clean, scalable foundation that any teammate can understand, extend, and trust - the opposite of the fragile hook soup most web3 apps end up with.

In a world where front-ends must behave like backends, this architecture makes the difference between a codebase that collapses under its own weight and a codebase that grows gracefully.

More to come

This article set the baseline. Next, I’ll publish short, focused deep-dives that build on the Fetch → Mapper → UI pattern:

Composing multiple sources of data
Caching strategies beyond - group invalidation, singular invalidation
Recognize data direction - When useMemo is actually the right tool
Error handling & partial data
Testing & observability

DEV Community: WingsDevelopment

Handling Multiple Data Sources in DeFi Frontend Architecture

Context: Why This Series Exists

Introduction

The Core Problem

A Mapper-Based Approach

Designing a Mapper Starts With the UI

The safeCall Wrapper

Cache Reuse and Separation of Concerns

Comparison: A Hook-Heavy Approach

What’s Actually Happening Here

Demo

Summary

What’s Next?

The Architecture Mistakes That Slowly Kills Large React Projects

Introduction

Too Much Data on the Client

Overusing useMemo

React query is too hard in web3 for on-chain fetching

Unpredictable re-renders

Fetch - mapper - hook layers for getting the data

Creating abstractions in early stage that can’t support project evolution

Final thoughts

The Web2 Mental Model Doesn’t Work in Web3

Goals of this Post

The Web2 Mental Model Doesn’t Work in Web3

A Simpler Model: Fetch → Mapper → UI

UI → Mappers → Fetchers

Layer 1 — Fetchers (RPC/Network + Cache)

Layer 2 — Mappers (Business Logic & Data Shaping)

Layer 3 — UI (Dumb Components, Smart Data)

Preventing Unnecessary Re-renders With UI-Level Cache

Final Thoughts

✔ You isolate complexity

✔ You centralize caching

✔ You remove nested hooks

✔ You avoid re-render storms

✔ You keep React Query exactly where it belongs

✔ You get predictable behavior even at scale

✔ You make your codebase far easier to maintain

More to come

The `safeCall` Wrapper

Overusing `useMemo`