Forem: D. Dhanushka

I Used Redux for API Data… Until React Query Saved Me

D. Dhanushka — Tue, 20 Jan 2026 14:38:51 +0000

It’s 2026.
And please… don’t be a stupid developer like me.

Yes, I said it 😄

For a long time, I used Redux (and sometimes Context) for everything.
University projects? Redux.
Side projects? Redux.
Fetching data from APIs? Yup… Redux again.

Then one day, a senior dev casually asked me:

“Bro… are you still using Redux to manage server state?”

I was like:
“Server… state? Isn’t state just… state?” 🤯

Turns out — nope.
And that question sent me down a rabbit hole that introduced me to React Query (now TanStack Query).

At that time, I was proudly pouring API responses into Redux like Dumbledore saying
“Of course I know what I’m doing.”
(First-year engineer confidence is undefeated.)

This article is my attempt to end the confusion between client state and server state, without turning this into a boring 40-minute read.

🧠 What the heck is Server State?

Server state is data that comes from somewhere outside your app — usually an API.

It’s data that:

Comes from an API
Can be cached
Can become stale
Can be refetched
Can change without you doing anything (thanks other users 👋)

Examples:

Product list
User profile from backend
Orders
Search results
Paginated data

👉 React Query is built specifically to manage this kind of state

🎨 What is Client State then?

Client state lives purely inside your UI.

It’s data that:

Exists only in the browser
Is usually synchronous
Is not shared with other users

Examples:

Dark / light theme
Modal open / close
Selected filters (before calling an API)
UI auth state (not the API call itself)

👉 Redux still shines here

⚔️ Why this matters (and why Redux alone struggles)

Most web frameworks don’t tell you how to fetch and manage async data properly.
So we end up:

Writing useEffect + useState everywhere
Storing API responses in Redux
Manually handling loading, error, caching, refetching… again and again

Traditional state libraries are great for client state,
but server state is a different beast:

It lives remotely
It’s async
It can change without you knowing
It gets stale
It needs caching
It needs background updates
It needs pagination, deduping, memory management…

If you’re not overwhelmed by that list, congrats — you deserve an award 🏆
For the rest of us… this is where TanStack Query comes in.

🚀 Why React Query?

TanStack Query is hands-down one of the best tools for managing server state.

Works out of the box
Almost zero config
Handles the hard stuff for you
Scales as your app grows

Alright, enough theory.
Let’s see why React Query is actually better than the “classic React way”.

✅ Example 1: Fetching Data (useEffect vs useQuery)

❌ Classic React Way

const [data, setData] = useState([]);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

useEffect(() => {
  setLoading(true);
  fetchProducts()
    .then(res => setData(res))
    .catch(err => setError(err))
    .finally(() => setLoading(false));
}, []);

Problems:

Boilerplate everywhere
Manual loading & error handling
No caching
No refetching

✅ React Query Way

const { data, isLoading, isError } = useQuery({
  queryKey: ['products'],
  queryFn: fetchProducts,
});

🎉 Done.

Loading handled
Error handled
Cached
Refetched automatically

✅ Example 2: Caching (the silent killer)

❌ Classic Way

Navigate away → fetch again
Come back → fetch again
Same API call 10 times 🤦‍♂️

You either:

Accept it
Or write your own cache logic (good luck)

✅ React Query Way

useQuery({
  queryKey: ['products'],
  queryFn: fetchProducts,
  staleTime: 5 * 60 * 1000,
});

React Query:

Caches data
Knows when data is stale
Refetches only when needed

You didn’t write any caching code.

✅ Example 3: Mutations & Refetching

❌ Classic Way (Redux / manual)

Call API
Update Redux
Refetch list
Sync UI manually

Lots of moving parts.

✅ React Query Way

const mutation = useMutation(addProduct, {
  onSuccess: () => {
    queryClient.invalidateQueries(['products']);
  },
});

What happens:

API call succeeds
Cached data invalidated
List refetches automatically
UI updates itself

✨ Less code. Fewer bugs. Less stress.

🧩 Final Takeaway

If there’s one thing I wish someone had told me earlier, it’s this:

Not all state is the same.

Server state is messy, asynchronous, shared, and constantly changing.
Client state is local, predictable, and UI-focused.

Trying to manage both with the same tool (hello Redux-for-everything 👋) works…
but it also means writing a lot of code that React Query already solved.

So no, React Query doesn’t replace Redux.
It replaces painful server-state logic you shouldn’t be writing in 2026.

If this article made you question where your API data lives —
good. That’s exactly the point.

Now go try React Query.
Your future self (and your codebase) will thank you.

Mastering Prompt Engineering: Patterns for Effective AI Interaction

D. Dhanushka — Fri, 24 Oct 2025 07:08:25 +0000

What is Prompt Engineering?

By 2025, AI tools like ChatGPT have become household names. With the widespread availability of large language models (LLMs), many people assume that interacting with these models is as simple as typing a question. However, there's more to it. Prompt engineering is the skill of crafting the right input, in a way that helps the AI model generate more accurate, relevant, and useful responses. If we don't know how to talk to these models, their responses can become vague or irrelevant. Learning prompt engineering ensures we can tap into the full potential of AI.

LLMs, like ChatGPT, Google’s Gemini, and others, are trained on massive datasets containing text from various sources. These models don’t "understand" the way humans do, but they excel at predicting the most likely next word based on the input provided. The more context and clarity you give in your input (the prompt), the better the model can respond. These models are intelligent but not infallible, meaning the quality of the user input largely determines the quality of the AI's output.

AI tools are now used across a variety of real-world applications, from
content generation (like writing blog posts or creative content) to question answering and data summarization. Whether you’re summarizing lengthy reports or brainstorming creative ideas, mastering how you craft your prompts ensures you get the most relevant information from the AI. In this article, we'll explore how specific prompt patterns can help unlock these tools’ true capabilities and enable more efficient, targeted interactions.

The Importance of Patterns in Prompt Engineering

Prompt patterns are recurring methods or structures that can be used to craft more effective prompts, helping to avoid common issues and improve the quality of AI-generated responses. While there are several recognized approaches, it's important to note that there are no universally identified patterns in prompt engineering—unlike design patterns in software development. As a result, the same pattern may be referred to by different names depending on the source. In this article, we will explore a few key patterns and show how they can be applied to optimize interactions with large language models.

These patterns can enhance workflows by reducing the need for trial-and-error. Instead of guessing how to phrase a prompt for the best result, using established patterns can lead to more accurate and relevant outputs. By applying these methods consistently, you can save time and improve the precision of your AI interactions.

N-Shot Prompting

N-shot prompting is a technique that leverages examples to guide large language models' (LLMs) responses. It includes variations like zero-shot, one-shot, few-shot, and many-shot. This approach helps models understand the desired framework of output and can significantly enhance the response's complexity and relevance depending on the examples provided.

N-shot variations:

Zero-shot prompting: This refers to providing no examples to the model. The model must rely entirely on its pre-trained knowledge to generate a response. This approach is useful when you want to assess how well the model can handle tasks independently without any guidance or prior context.
One-shot prompting: Here, a single example is provided to the model. This is useful when you want to give minimal guidance on the task while still allowing the model to infer from the example.
Few-shot prompting: In this variation, a few examples (typically 2–5) are provided. This helps the model better understand the desired output pattern by generalizing from multiple examples. It strikes a balance between guidance and allowing the model to demonstrate some creativity.
Many-shot prompting: This technique provides numerous examples, giving the model a very clear idea of the expected format and output. This can be useful for complex tasks where precise behavior is essential, though it can reduce flexibility and creativity in responses.

Example: Offering extensive translations of words or phrases before asking the model to translate additional words.

Example prompt and answer from ChatGPT:

Prompt: "Translate the following words into French following the examples: car -> voiture, apple -> pomme. Now, translate dog."
Answer: "The translation for dog is chien."

Drawbacks and considerations:

While N-shot prompting can increase the model's understanding and specificity, it may require more computational resources and time.
There's also a trade-off between the number of examples and the model's creativity. More examples may make the model follow patterns strictly, leaving little room for innovation, while fewer examples may encourage creative but less accurate responses.

Meta Language Creation

Meta language creation involves defining a custom language or notation to communicate with LLMs. It allows users to tailor interactions more precisely by using pre-defined semantics.