Lưu trữ react-native - Trang 5 trên 9

Dive deep into React Native Reanimated 3 with this complete tutorial. Learn how to build complex, performant animations in production apps, from gestures to shared element transitions.

Tagged debugging, performance, react-native

Alright, let’s talk about animations in React Native. If you’ve been in the game for a while, you’ve probably wrestled with the built-in Animated API. It’s fine for simple stuff, but when things get complex, or when you really need that buttery-smooth, native-like feel, you start hitting its limits. Enter React Native Reanimated 3. This isn’t just an update; it’s a significant leap forward, especially with its revamped architecture that brings more power and predictability to your animations.

This guide is for you if you’re comfortable with React Native basics and are looking to build production-ready apps with animations that impress, not frustrate. We’re going beyond the theoretical and getting our hands dirty with practical examples and real-world insights. Think of this as the tutorial I wish I had when I first started digging into Reanimated.

Why Reanimated 3? The Evolution of Performance

Before Reanimated 3, the big win was offloading animations to the native UI thread. This meant your animations could run independently of the JavaScript thread, preventing dropped frames caused by heavy JS logic. Reanimated 2 took this much further with its Worklets API, allowing you to run JavaScript code directly on the UI thread. Reanimated 3 builds on this solid foundation, refining the API, improving stability, and introducing even more powerful features.

The core problem Reanimated solves is the bridge. React Native’s architecture relies on a bridge to communicate between JavaScript and native code. For animations, this communication can become a bottleneck, especially with frequent updates. Reanimated 3, through its Worklets and gesture handler integration, drastically reduces this overhead, enabling truly native-level animation performance.

Why should you care about this? Because smooth, responsive animations aren’t just eye candy. They’re crucial for user experience. They guide the user, provide feedback, and make your app feel polished and professional. In a competitive app market, good UX is king, and animations play a huge role in that.

Getting Started: Setup and Your First Animated Component

Let’s get this set up. For React Native Reanimated 3, installation is pretty straightforward. You’ll typically use npm or yarn:

npm install react-native-reanimated
# or
yarn add react-native-reanimated

After installation, you need to make sure you follow the specific setup instructions for your React Native version and platform. This usually involves adding a Babel plugin. For most recent projects, it’s as simple as adding this to your babel.config.js:

module.exports = {
presets: ['module:metro-react-native-babel-preset'],
plugins: ['react-native-reanimated/plugin'],
};

Crucially, after modifying your babel.config.js, you need to clear your Metro bundler cache and re-run your app:

npx react-native start --reset-cache
# or for Expo
expo start -c

Now, for our first animated component. Let’s create a simple fading-in square. The core of Reanimated lies in its Animated components. You typically wrap standard React Native components with Reanimated’s versions. For example, instead of View, you’d use Animated.View.

Here’s a basic example:

import React, { useEffect } from 'react';
import { View, StyleSheet } from 'react-native';
import Animated, { useSharedValue, withTiming, Easing } from 'react-native-reanimated';
const AnimatedBox = () => {
const opacity = useSharedValue(0);
useEffect(() => {
opacity.value = withTiming(1, {
duration: 1000,
easing: Easing.ease
});
}, []);
return (
<Animated.View
style={[
styles.box,
{ opacity: opacity } // Animated value is directly used in style
]}
/>
);
};
const styles = StyleSheet.create({
box: {
width: 100,
height: 100,
backgroundColor: 'tomato',
marginTop: 50,
alignSelf: 'center',
},
});
export default AnimatedBox;

Let’s break this down:

useSharedValue(0): This hook creates a shared value. Shared values are the state variables for animations in Reanimated. They can be accessed and modified from both the JS thread and the UI thread.
withTiming(...): This is an animation primitive. It takes a target value and animation configuration (duration, easing) and returns an animation that smoothly interpolates the shared value to the target over time.
useEffect: We trigger the animation when the component mounts.
style={{ opacity: opacity }}: This is the magic. Reanimated knows how to directly use shared values within style objects. When the opacity shared value changes, the UI updates accordingly, and because it’s running on the UI thread, it’s smooth.

This might seem trivial, but it’s the fundamental pattern: shared values for state, animation primitives to drive them, and direct application to styles. This is the bedrock of React Native Reanimated 3 animations.

The Building Blocks: Animated Values and Controllers

Shared values are the heart of Reanimated. You can have multiple shared values for different animation properties. Common types include:

useSharedValue(initialValue): For numbers, booleans, etc.
useDerivedValue(() => ... ): Creates a shared value that is derived from other shared values. This is incredibly powerful for complex relationships between animated properties. For example, if you have a shared value for translationX and another for scale, you can derive a rotation value based on how far it’s been translated.
useAnimatedStyle(() => { ... }): This hook is key for applying animated styles. It returns a style object that Reanimated optimizes. Inside the hook, you can reference shared values, and Reanimated will ensure the component updates efficiently when those values change.

Let’s refine our example using useAnimatedStyle:

import React, { useEffect } from 'react';
import { View, StyleSheet } from 'react-native';
import Animated, { useSharedValue, useAnimatedStyle, withTiming, Easing } from 'react-native-reanimated';
const AnimatedBox = () => {
const opacity = useSharedValue(0);
useEffect(() => {
opacity.value = withTiming(1, {
duration: 1000,
easing: Easing.ease
});
}, []);
const animatedStyle = useAnimatedStyle(() => {
return {
opacity: opacity.value, // Accessing shared value inside the hook
};
});
return (
<Animated.View style={[styles.box, animatedStyle]} />
);
};
const styles = StyleSheet.create({
box: {
width: 100,
height: 100,
backgroundColor: 'tomato',
marginTop: 50,
alignSelf: 'center',
},
});
export default AnimatedBox;

Notice how we moved the style definition into useAnimatedStyle. This is generally preferred as Reanimated can apply more optimizations. The shared value is still driven by withTiming, but now it’s consumed by the animated style object.

Animation Controllers: Interpolation

Sometimes you need to map one animated value to another. For example, mapping a scroll position (0 to 1000) to an opacity (0 to 1). This is where interpolate comes in.

Let’s imagine a scrollable list where a header fades out as you scroll down:

import React from 'react';
import { View, StyleSheet, ScrollView } from 'react-native';
import Animated, { useSharedValue, useAnimatedScrollHandler, useAnimatedStyle, interpolate, Extrapolate } from 'react-native-reanimated';
const SCROLL_THRESHOLD = 100;
const AnimatedHeader = () => {
const scrollY = useSharedValue(0);
const scrollHandler = useAnimatedScrollHandler({
onScroll: (event) => {
scrollY.value = event.contentOffset.y;
},
});
const headerStyle = useAnimatedStyle(() => {
const opacity = interpolate(
scrollY.value,
[0, SCROLL_THRESHOLD],
[1, 0], // Opacity goes from 1 (visible) to 0 (invisible)
Extrapolate.CLAMP
);
return {
opacity: opacity,
};
});
return (
<View style={styles.container}>
<Animated.View style={[styles.header, headerStyle]}>
<Animated.Text>My Cool Header</Animated.View>
</Animated.View>
<Animated.ScrollView
onScroll={scrollHandler}
scrollEventThrottle={16} // Important for iOS!
style={styles.scrollView}
>
{/* Lots of content to make it scrollable */}
{Array.from({ length: 50 }).map((_, i) => (
<View key={i} style={styles.listItem} />
))}
</Animated.ScrollView>
</View>
);
};
const styles = StyleSheet.create({
container: { flex: 1 },
header: {
height: 60,
backgroundColor: 'lightblue',
justifyContent: 'center',
alignItems: 'center',
position: 'absolute',
top: 0,
left: 0,
right: 0,
zIndex: 1,
},
scrollView: { flex: 1, paddingTop: 70 }, // Push content down to avoid overlap
listItem: {
height: 50,
backgroundColor: 'lightgray',
marginVertical: 5,
marginHorizontal: 10,
},
});
export default AnimatedHeader;

Key takeaways here:

useAnimatedScrollHandler: This hook is specifically for handling scroll events. It runs on the UI thread, so it’s very performant.
interpolate: Maps an input range to an output range. Here, scrollY.value (0 to 100) is mapped to opacity (1 to 0).
Extrapolate.CLAMP: This is important. It prevents the interpolated value from going beyond the defined output range. So, if you scroll past 100, opacity stays at 0.
Animated.ScrollView: We use the animated version of ScrollView to hook into scroll events.
scrollEventThrottle={16}: Crucial for iOS to ensure you get enough scroll events.

This pattern of mapping one animated value to another is fundamental for many UI effects. You can interpolate not just opacity but also translate, scale, rotate, color, and more.

Handling Gestures with React Native Gesture Handler and Reanimated

Animations often need to be driven by user interaction, and that’s where react-native-gesture-handler shines. Reanimated 3 integrates seamlessly with it, allowing you to build complex gesture-driven animations that feel incredibly responsive.

Let’s create a draggable square. This is a classic example that showcases the power of this integration.

import React from 'react';
import { View, StyleSheet } from 'react-native';
import { GestureHandlerRootView, PanGestureHandler } from 'react-native-gesture-handler';
import Animated, { useSharedValue, useAnimatedGestureHandler, useAnimatedStyle, interpolate, Extrapolate } from 'react-native-reanimated';
const DraggableBox = () => {
const translateX = useSharedValue(0);
const translateY = useSharedValue(0);
const panGesture = useAnimatedGestureHandler({
onStart: (event, ctx) => {
// Save the starting position
ctx.translateX = translateX.value;
ctx.translateY = translateY.value;
},
onActive: (event, ctx) => {
// Update the position based on gesture movement
translateX.value = ctx.translateX + event.translationX;
translateY.value = ctx.translateY + event.translationY;
},
onEnd: () => {
// Optional: snap back or continue animation on release
},
});
const animatedStyle = useAnimatedStyle(() => {
return {
transform: [
{ translateX: translateX.value },
{ translateY: translateY.value },
],
};
});
return (
<GestureHandlerRootView style={{ flex: 1 }}>
<View style={styles.container}>
<PanGestureHandler onGestureEvent={panGesture}>
<Animated.View style={[styles.box, animatedStyle]} />
</PanGestureHandler>
</View>
</GestureHandlerRootView>
);
};
const styles = StyleSheet.create({
container: { flex: 1, justifyContent: 'center', alignItems: 'center' },
box: {
width: 100,
height: 100,
backgroundColor: 'dodgerblue',
borderRadius: 10,
},
});
export default DraggableBox;

Let’s dissect this:

GestureHandlerRootView: You need this at the root of your gesture-handling components.
PanGestureHandler: This component from react-native-gesture-handler detects pan (drag) gestures.
useAnimatedGestureHandler: This is the Reanimated hook for connecting gesture events to animated values. It has callbacks for onStart, onActive, and onEnd.
ctx (context): This is a persistent object within the gesture handler’s scope. We use it to store the initial position when the gesture starts. This is crucial because event.translationX/Y is the *delta* since the gesture started, not the absolute position.
event.translationX: The distance the finger has moved in the X direction since the gesture began.
animatedStyle: We update the transform style with the shared values for translateX and translateY.

The magic here is that useAnimatedGestureHandler also runs on the UI thread. This means gesture events are processed natively, and the animated values are updated directly on the UI thread, leading to incredibly fluid dragging, even on busy devices. This is a massive win over trying to manage gesture state updates purely on the JS thread.

Common Gesture Scenarios

Pinch to Zoom: Combine PinchGestureHandler with useSharedValue for scale and use interpolate to map pinch distance to scale factor.
Rotation: Use RotationGestureHandler and map its output to a rotate transform.
Swiping: PanGestureHandler is your friend. You can animate the swipe-off with withSpring or withTiming based on the swipe velocity and distance.

Remember to always wrap your gesture-handling components with GestureHandlerRootView, typically at the app’s root or a reasonable parent.

Beyond Basic Animations: Worklets and the Shared UI Thread

This is where Reanimated 3 truly flexes its muscles. Worklets are small JavaScript functions that can be executed on the UI thread. This opens up possibilities for complex logic and computations directly where they matter most for smooth animation.

Let’s revisit our draggable box, but this time, let’s add a rubber-banding effect when you drag it too far:

import React from 'react';
import { View, StyleSheet } from 'react-native';
import { GestureHandlerRootView, PanGestureHandler } from 'react-native-gesture-handler';
import Animated, { useSharedValue, useAnimatedGestureHandler, useAnimatedStyle, interpolate, Extrapolate, runOnJS } from 'react-native-reanimated';
const MAX_DRAG_X = 100;
const MAX_DRAG_Y = 200;
const BORDER_WIDTH = 20; // To visualize the boundary
const DraggableBoxWithBounds = () => {
const translateX = useSharedValue(0);
const translateY = useSharedValue(0);
// A helper function to apply rubber band effect
const rubberBand = (value, extent) => {
'worklet'; // This tells Reanimated this function should run on the UI thread
if (value > extent) {
return extent + Math.sin((value - extent) / 20) * 20;
}
if (value < -extent) {
return -extent + Math.sin((value + extent) / 20) * 20;
}
return value;
};
const panGesture = useAnimatedGestureHandler({
onStart: (event, ctx) => {
ctx.translateX = translateX.value;
ctx.translateY = translateY.value;
},
onActive: (event, ctx) => {
// Apply rubber-banding directly in the gesture handler
translateX.value = rubberBand(ctx.translateX + event.translationX, MAX_DRAG_X);
translateY.value = rubberBand(ctx.translateY + event.translationY, MAX_DRAG_Y);
},
onEnd: (event) => {
// Optional: Animate back to center if outside bounds or with velocity
// For simplicity, we'll just let it stay where it is with the rubber band
},
});
const animatedStyle = useAnimatedStyle(() => {
return {
transform: [
{ translateX: translateX.value },
{ translateY: translateY.value },
],
};
});
return (
<GestureHandlerRootView style={{ flex: 1 }}>
<View style={styles.container}>
<View style={[styles.boundary, { left: -MAX_DRAG_X, top: -MAX_DRAG_Y }]} />
<PanGestureHandler onGestureEvent={panGesture}>
<Animated.View style={[styles.box, animatedStyle]} />
</PanGestureHandler>
<View style={[styles.boundary, { right: -MAX_DRAG_X, top: -MAX_DRAG_Y }]} />
<View style={[styles.boundary, { left: -MAX_DRAG_X, bottom: -MAX_DRAG_Y }]} />
<View style={[styles.boundary, { right: -MAX_DRAG_X, bottom: -MAX_DRAG_Y }]} />
</View>
</GestureHandlerRootView>
);
};
const styles = StyleSheet.create({
container: { flex: 1, justifyContent: 'center', alignItems: 'center', backgroundColor: '#f0f0f0' },
box: {
width: 100,
height: 100,
backgroundColor: 'orangered',
borderRadius: 10,
},
boundary: {
position: 'absolute',
width: MAX_DRAG_X * 2 + 100, // Wide enough to visualize the extent
height: MAX_DRAG_Y * 2 + 100,
borderWidth: BORDER_WIDTH,
borderColor: 'rgba(0,0,0,0.1)',
borderRadius: 5,
}
});
export default DraggableBoxWithBounds;

The key here is the 'worklet'; directive. This tells Reanimated that the rubberBand function is a Worklet. When panGesture is called on the UI thread, Reanimated knows to execute this function on the UI thread as well. This allows for:

Complex Calculations: You can perform complex mathematical operations, physics simulations, or logic directly on the UI thread without blocking the JS thread.
Shared Value Manipulation: Worklets can read and write shared values.
Calling JS Functions (with caution): You can call JavaScript functions from a worklet using runOnJS(), but this will move the execution back to the JS thread, so use it sparingly.

This worklet approach is what enables things like complex physics-based animations, custom gesture interpolations, and custom timing functions that would be too slow or impossible to manage on the JS thread alone.

Advanced Techniques: Layout Animations and Shared Element Transitions

Reanimated 3 also offers powerful tools for animating layout changes and even shared element transitions, which are a hallmark of modern app design.

Layout Animations

When items in a list or grid change position, add, or remove, you often want a smooth animation rather than an abrupt jump. Reanimated provides LayoutAnimations (though often used in conjunction with libraries like react-native-reanimated-motion or directly with LayoutAnimationConfig). The core idea is that Reanimated can track elements and animate their position, scale, and opacity when their layout changes.

A common pattern is to use LayoutAnimationConfig with withSpring or withTiming to animate changes to the layout.

import { LayoutAnimationConfig } from 'react-native-reanimated';
// In your component where you manage the list...
const handleAddItem = () => {
LayoutAnimationConfig.configureNext(LayoutAnimationConfig.presets.spring);
// ... add item to your state
};

While Reanimated has evolved its layout animation capabilities, often you’ll see this integrated via higher-level libraries or specific patterns that hook into Reanimated’s core. The principle remains: track element positions and animate transitions when they shift.

Shared Element Transitions

This is the holy grail for many complex UI flows: animating an element smoothly from one screen to another, as if it’s morphing or moving between the two. Reanimated 3, especially with community libraries built on top of it, makes this much more achievable.

The core mechanism often involves:

Identifying Shared Elements: You need a way to mark elements that are present on both the outgoing and incoming screens and that should animate together.
Capturing Positions: Before the transition, you capture the initial position, size, and potentially other properties of the shared element on the outgoing screen.
Animating on the Incoming Screen: As the new screen appears, you create a temporary “ghost” or overlay of the shared element. This ghost is then animated from the captured starting position to its final position on the new screen. Reanimated’s worklets are crucial here for smooth, on-thread animation.

Libraries like react-native-shared-element have historically tackled this, and with Reanimated 3, the underlying animation engine is much more capable of supporting such intricate transitions. The exact implementation can be complex and often relies on custom hooks or helper components that manage the shared element state and animation lifecycle.

Real-world insight: Shared element transitions are one of the most impressive UI features but also one of the most challenging to implement robustly. They require careful state management, understanding of navigation lifecycles, and often dealing with edge cases like different screen sizes or orientation changes. Don’t underestimate the effort involved.

Debugging and Performance Optimization

Animations are notorious for performance issues. Reanimated 3, by design, is performant, but you can still shoot yourself in the foot.

Debugging Tools

React Native Debugger: You can inspect shared values and animated styles to some extent.
Reanimated’s `isWorklet` and `runOnJS` checks: Use these to ensure your functions are running where you expect them to.
Console Logging on UI Thread: This is tricky. Standard console.log won’t work directly in a worklet. You need runOnJS(console.log), which has performance implications. For serious UI thread debugging, you might consider tools that can trace UI thread execution, though these are less common than JS debugging tools.
Visualizing Bounds/Ranges: As shown in the rubber-band example, drawing temporary UI elements to visualize your animation bounds or important points can be incredibly helpful.

Performance Tips

Prefer UI Thread: Always aim to run your animation logic on the UI thread using worklets and animated components. Avoid moving back to the JS thread unless absolutely necessary.
Minimize Worklet Complexity: While worklets run on the UI thread, very heavy computations can still cause jank. Keep your worklets focused and efficient.
Debounce/Throttle JS-heavy Logic: If you must perform JS-thread operations (e.g., fetching data based on an animation state), use debouncing or throttling to avoid overwhelming the JS thread.
Use `withSpring` Wisely: withSpring is fantastic for natural, bouncy animations, but its internal calculations can be more intensive than withTiming. Profile if you see issues.
`useAnimatedStyle` is Your Friend: Always use this hook for styles that change based on shared values. Reanimated optimizes these updates.
Animated Components: Ensure you are using Animated.View, Animated.Text, etc., not their regular React Native counterparts when applying animated styles.
Check dependencies: Ensure you’re using up-to-date versions of react-native-reanimated and react-native-gesture-handler. Compatibility issues can lead to unexpected behavior.

Debugging Reanimated animations often involves a process of elimination and careful observation. When an animation is janky, ask yourself: is this running on the UI thread? Is the worklet doing too much? Is the gesture handler correctly capturing the start position?

Common Pitfalls and How to Avoid Them

Forgetting the Babel Plugin: This is the most common setup error. If your animations aren’t working or you get weird errors, double-check that react-native-reanimated/plugin is in your babel.config.js and that you’ve cleared caches.
Using Regular Components with Animated Values: Trying to pass a useSharedValue directly to a regular View‘s style won’t work as expected. You need Animated.View (or other Animated.Component).
JS Thread Bottlenecks: Trying to do too much on the JS thread while animations are running. Remember, animations are supposed to be offloaded.
Incorrect Gesture Context Usage: Forgetting to store start positions in ctx for gesture handlers leads to animations that jump or behave erratically.
Confusing `event.translation` with Absolute Position: Gesture events provide delta values. You need to add these deltas to a stored initial position.
Not Wrapping with GestureHandlerRootView: Gestures won’t work without it.
Over-reliance on runOnJS: While useful, excessive use defeats the purpose of UI thread execution.
Not understanding Worklets: Thinking you can use complex JS syntax or browser-specific APIs within a worklet. Worklets are a subset of JS.

My personal mistake early on was trying to manage complex animations by passing shared values back and forth to the JS thread too much. It felt like I was fighting the library. Once I fully embraced the worklet model and understood how to do more computation directly on the UI thread, things clicked into place, and performance improved dramatically.

Conclusion: Level Up Your React Native Animations

React Native Reanimated 3 is a powerful tool that, when understood and applied correctly, can elevate your app’s user experience to new heights. We’ve covered the basics of shared values, animated styles, gesture handling, and the crucial concept of worklets for UI thread execution. We’ve also touched upon advanced features like layout animations and the foundation for shared element transitions.

Mastering Reanimated 3 means understanding the interplay between the JS and UI threads, leveraging shared values effectively, and writing performant, UI-thread-executable code with worklets. It’s a learning curve, for sure, but the payoff in terms of smooth, responsive, and visually appealing animations is immense.

So, go forth, experiment, and build some amazing animations! Don’t be afraid to dive into the official React Native Reanimated documentation. It’s an excellent resource for digging deeper into specific APIs and advanced patterns. Happy animating!

React Native Reanimated 3: Mastering Smooth Animations

Lập Trình

React Native

24 min
1 tháng ago
1
7

Dive deep into React Native Reanimated 3 with this comprehensive tutorial. Learn to build complex, performant animations and overcome common challenges with practical insights from experienced developers.

Tagged debugging, performance, react-native

Introduction: Why React Native Reanimated 3 is a Game-Changer

Alright, fellow React Native devs, let’s talk animations. For a long time, achieving truly fluid, native-feeling animations in React Native felt like trying to herd cats. We had the built-in Animated API, which was… okay. It got the job done for simpler things, but for anything more complex, especially involving gestures or really smooth, per-frame updates, we often hit a wall. Performance would dip, animations would stutter, and we’d end up writing more JavaScript than we were comfortable with, hoping the bridge wouldn’t explode.

Then came Reanimated. And with React Native Reanimated 3, the team has really polished this gem into something truly exceptional. If you’re looking to build slick, performant, and complex animations without sacrificing your sanity, you absolutely need to be looking at Reanimated 3. This isn’t just an incremental update; it’s a foundational shift in how we approach animations in React Native, enabling you to create experiences that feel genuinely native.

In this post, I want to walk you through what makes Reanimated 3 so powerful, share some practical tips and tricks I’ve picked up in the trenches, and hopefully save you some debugging headaches. We’ll go beyond the basic ‘fade in, fade out’ and dive into the real-world stuff you’ll encounter when building production apps. So, grab your favorite IDE and let’s get animating!

The Core Concepts: Shared Values and Worklets

Before we start slinging code, let’s get our heads around the two pillars of Reanimated 3: Shared Values and Worklets. Understanding these is key to unlocking Reanimated’s power.

Shared Values: The Heartbeat of Animation

Think of Shared Values as reactive state that lives on the UI thread. Unlike regular React state that lives in JavaScript, Shared Values are accessible and mutable directly from native code. This is crucial because animations often require hundreds, if not thousands, of updates per second. If every single update had to cross the JavaScript bridge, your animation would choke faster than a poorly optimized image.

In Reanimated 3, you create a Shared Value using useSharedValue:

import { useSharedValue } from "react-native-reanimated";
function MyComponent() {
const opacity = useSharedValue(1);
// ...
}

You can then update this value directly:

opacity.value = 0;

The magic here is that this change is processed on the UI thread, avoiding the bridge bottleneck. This is a fundamental shift from older animation libraries and the primary reason for Reanimated’s superior performance.

Worklets: Code That Runs on the UI Thread

Worklets are JavaScript functions that can be executed on the UI thread. This is where the real power lies. Instead of just *declaring* an animation, you can write imperative code that runs directly where the animation is happening.

You define a worklet using the runOnJS or runOnUI directives (though often implicitly with hooks like useAnimatedStyle). The key is that the code inside a worklet has access to Shared Values and can modify them directly.

Let’s look at an example. Imagine you want to smoothly animate a view’s opacity to 0.5:

import Animated, { useSharedValue, useAnimatedStyle, withTiming } from "react-native-reanimated";
import { View, Button } from "react-native";
function AnimatedBox() {
const opacity = useSharedValue(1);
const animatedStyle = useAnimatedStyle(() => {
return {
opacity: opacity.value,
};
});
const animateToHalf = () => {
// This is the worklet part!
opacity.value = withTiming(0.5, { duration: 500 });
};
return (
<>

In this snippet:

useSharedValue(1) creates a Shared Value for opacity, initialized to 1.
useAnimatedStyle is a hook that creates a style object. The function passed to it is a worklet. It runs on the UI thread whenever its dependencies (here, opacity.value) change.
animatedStyle is then applied to our Animated.View.
withTiming is a Reanimated animation utility. When called inside a worklet (like animateToHalf), it schedules an animation to run on the UI thread.
opacity.value = withTiming(...) directly updates the Shared Value, triggering the animation.

This is significantly different from the old Animated.timing, where the animation logic was managed in JavaScript. Here, the entire animation curve is computed and applied on the UI thread. This is the core of Reanimated’s performance advantage.

Your First Reanimated Animation: A Simple Example

Let’s build something tangible to solidify these concepts. We’ll create a simple component that animates its position on the screen when a button is pressed. This will involve both Shared Values and Worklets within useAnimatedStyle.

The Goal

We want a blue square that, when a button is tapped, slides from the left side of the screen to the right and then back again.

The Code

import React from "react";
import { View, Button, StyleSheet, Dimensions } from "react-native";
import Animated, { useSharedValue, useAnimatedStyle, withTiming, Easing, withSequence } from "react-native-reanimated";
const { width } = Dimensions.get("window");
const SQUARE_SIZE = 100;
const OFFSCREEN_RIGHT = width - SQUARE_SIZE;
function MovingSquare() {
const translateX = useSharedValue(0);
const duration = 500;
// This hook defines how the style should react to shared value changes.
// The function inside runs on the UI thread as a worklet.
const animatedStyle = useAnimatedStyle(() => {
return {
transform: [{ translateX: translateX.value }],
};
});
const animateMovement = () => {
// Use withSequence to run animations one after another.
// Each animation uses withTiming for a smooth, timed transition.
translateX.value = withSequence(
withTiming(OFFSCREEN_RIGHT, { duration: duration, easing: Easing.inOut(Easing.quad) }),
withTiming(0, { duration: duration, easing: Easing.inOut(Easing.quad) })
);
};
return (

Explanation

useSharedValue(0): We initialize translateX to 0, meaning the square starts at its default position.
OFFSCREEN_RIGHT: We calculate the maximum horizontal translation needed to move the square off the right edge of the screen.
useAnimatedStyle(() => { ... }): This hook takes a function that returns a style object. This function is a worklet. Whenever translateX.value changes, this worklet will re-run on the UI thread, updating the transform property of our view.
animateMovement(): This function is triggered by the button press.
withSequence(...): This is a powerful Reanimated function that allows you to chain animations. It ensures the first animation completes before the second one starts.
withTiming(...): This is used for smooth, duration-based animations. We specify the target value, duration, and an easing function for a nice feel.

When you tap “Move Square,” animateMovement is called. It then schedules two animations to run sequentially on the UI thread: first, it moves the square to OFFSCREEN_RIGHT, and then it moves it back to 0. Because translateX.value is being updated by these UI-thread animations, useAnimatedStyle picks up the changes instantly, and the square moves smoothly across the screen.

Beyond the Basics: Complex Transitions and Gestures

This is where Reanimated truly shines. While the basic timing animations are great, real-world apps often involve complex sequences, user-driven interactions (gestures), and shared element transitions.

Handling Gestures with `react-native-gesture-handler`

Animations rarely happen in a vacuum. They’re often tied to user input like swiping, pinching, or dragging. react-native-gesture-handler is the de facto standard for this, and Reanimated integrates beautifully with it.

The core idea is to use gesture handlers to update Shared Values. These Shared Values can then drive your animations. You can also directly respond to gesture events on the UI thread using worklets.

import React from "react";
import { View, StyleSheet } from "react-native";
import Animated, { useSharedValue, useAnimatedGestureHandler, useAnimatedStyle, interpolate, Extrapolate } from "react-native-reanimated";
import { PanGestureHandler } from "react-native-gesture-handler";
const CIRCLE_RADIUS = 50;
function DraggableCircle() {
const translateX = useSharedValue(0);
const translateY = useSharedValue(0);
const panGesture = useAnimatedGestureHandler({
onStart: (event, ctx) => {
// Store the initial position in context
ctx.translateX = translateX.value;
ctx.translateY = translateY.value;
},
onActive: (event, ctx) => {
// Update shared values based on gesture translation
translateX.value = ctx.translateX + event.translationX;
translateY.value = ctx.translateY + event.translationY;
},
onEnd: () => {
// Optionally animate to a final resting position
// translateX.value = withSpring(0);
// translateY.value = withSpring(0);
},
});
const animatedStyle = useAnimatedStyle(() => {
return {
transform: [
{ translateX: translateX.value },
{ translateY: translateY.value },
],
};
});
return (





);
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: "center",
alignItems: "center",
},
circle: {
width: CIRCLE_RADIUS * 2,
height: CIRCLE_RADIUS * 2,
borderRadius: CIRCLE_RADIUS,
},
});
export default DraggableCircle;

Explanation

useSharedValue(0): We use two Shared Values, one for translateX and one for translateY.
useAnimatedGestureHandler: This hook allows you to define handlers for gesture events (onStart, onActive, onEnd). The functions inside this hook are worklets and run on the UI thread.
ctx (context): This object is persistent across gesture events within a single gesture. It’s useful for storing initial values (like the position when the drag started) so you can correctly calculate the new position relative to the start.
event.translationX/Y: These properties from the gesture event tell you how much the user has moved their finger since the gesture started.
PanGestureHandler: This component from react-native-gesture-handler wraps our Animated.View and listens for pan gestures. It passes its events to our panGesture handler.
animatedStyle: As before, this worklet maps the translateX and translateY Shared Values to the transform style property.

When you drag the blue circle, the onActive handler is called repeatedly on the UI thread. It updates the translateX and translateY Shared Values based on the finger’s movement. These updates then immediately cause the animatedStyle worklet to re-run, updating the circle’s position, resulting in a perfectly fluid drag. This is the power of UI thread execution.

Animations and Transitions

Reanimated 3 also excels at managing complex animations and transitions, especially when combined with libraries like react-native-screens and react-navigation. The concept of Shared Element Transitions is now much more achievable, allowing elements to animate smoothly between different screens.

While implementing full-blown shared element transitions is beyond a single code block, the underlying principle is the same: you animate Shared Values that represent the position, size, or opacity of elements. Reanimated provides tools like withTransition to animate changes in layout or properties over time, simplifying these complex scenarios.

Performance Pitfalls and How to Avoid Them

Even with Reanimated’s power, it’s not magic. You can still write code that brings your animations to a crawl if you’re not careful. Here are common pitfalls and how to dodge them.

1. Too Many Shared Values or UI Thread Workloads

Every Shared Value and every worklet adds some overhead. If you’re animating dozens of properties independently or running very heavy computations inside worklets, you might still see performance issues.

Lesson Learned: Optimize your worklets. Keep them focused. If a calculation can be done in JavaScript before initiating an animation, do it there. If you find yourself creating a Shared Value for something that doesn’t need to be reactive *on the UI thread*, rethink it.

2. Blocking the UI Thread

This is the cardinal sin. While worklets run on the UI thread, they should be short and sweet. Avoid long-running loops, synchronous network requests, or heavy data processing within a worklet. These will freeze your animation!

What Didn’t Work: In the early days of Reanimated, I once had a complex data transformation that was accidentally called inside a gesture handler’s onActive. The app became completely unresponsive during drag. The fix was to move that heavy computation out of the gesture handler and pre-process the data.

Best Practice: Use runOnJS cautiously. If you *must* call a JavaScript function from a worklet, be aware of the potential bridge overhead. Prefer to keep as much as possible on the UI thread.

3. Over-Animating or Unnecessary Updates

Sometimes, we get carried away and animate everything. If a UI element doesn’t need to animate smoothly, don’t animate it. Also, ensure your useAnimatedStyle dependencies are correct. If a style only needs to update when one specific Shared Value changes, make sure that’s the only dependency it reacts to. Unnecessary re-renders of animated styles can impact performance.

Example: Animating the zIndex of an element on every frame of a gesture. Does it really need to change that rapidly? Probably not. Animate it only when a certain threshold is met.

4. Mixing `useNativeDriver` with Reanimated (The Old Way)

Before Reanimated became so dominant, developers often tried to combine React Native’s built-in Animated.useNativeDriver(true) with other animation libraries or custom logic. This could lead to unpredictable behavior or nullify the benefits of native drivers. Reanimated 3 largely eliminates this concern because it *is* the native driver for your animations.

Lesson Learned: Trust Reanimated. If you’re using Reanimated, you’re already leveraging the UI thread effectively. Don’t try to force old patterns onto it.

5. Memory Leaks

While less common with Reanimated 3 itself, if you’re not careful with how you manage listeners, event handlers, or large data structures within your animated components, you can introduce memory leaks. Ensure that when a component unmounts, any subscriptions or listeners associated with its animations are properly cleaned up.

Debugging Reanimated Animations: A Developer’s Guide

Debugging animations can be notoriously tricky. When your animation isn’t behaving as expected, it’s rarely obvious why. Here are some strategies that have saved me countless hours.

1. The Power of `console.log` (with a Caveat)

You can still use console.log inside your worklets. However, remember that worklets run on the UI thread. Excessive logging can actually *cause* performance issues and mask the real problem. Use it sparingly, especially for debugging values that change rapidly.

Tip: If you need to log a Shared Value, you often need to access its current value: console.log(sharedValue.value).

2. Using `runOnJS` for Debugging

A common pattern for debugging worklets is to wrap your console.log calls in runOnJS. This forces the logging to happen on the JS thread, which is less likely to interfere with the animation’s performance.

import { runOnJS } from "react-native-reanimated";
// Inside a worklet:
const logValue = (val) => {
console.log("Debug value:", val);
};
translateX.value = withTiming(100, { duration: 500 }, () => {
runOnJS(logValue)("Animation finished!");
});

3. Visualizing Shared Values

Sometimes, the best way to debug is to *see* what the Shared Values are doing. You can do this by mapping them to an easily observable style property, like opacity, background color, or scale.

Example: If you’re debugging translateX, you could temporarily add it to the width or scale of a dummy view to see its magnitude visually.

const animatedStyle = useAnimatedStyle(() => {
return {
// ... other styles
transform: [{ translateX: translateX.value }],
backgroundColor: interpolateColor(translateX.value, [0, 100], ['red', 'blue']),
opacity: interpolate(translateX.value, [0, 100], [1, 0.5], Extrapolate.CLAMP),
};
});

4. The React Native Debugger

Don’t forget your standard tools! The React Native Debugger (or Flipper) is invaluable. You can inspect component hierarchies, view network requests, and, most importantly, use its profiler to identify performance bottlenecks. While it might not directly show you UI thread execution details, it can point you to JavaScript-side issues that might be affecting your animations.

5. Simplify and Isolate

If you have a complex animation that’s misbehaving, break it down. Temporarily disable parts of it. Can you isolate the problematic gesture? Is it a specific animation sequence? By simplifying the scenario, you can pinpoint the exact source of the bug.

Personal Anecdote: I once spent an entire afternoon debugging a gesture-driven animation that was randomly jumping. Turned out it was a subtle conflict between two gesture handlers that were both trying to control the same Shared Value in slightly different ways. Isolating the gesture handlers one by one revealed the culprit.

Integrating with Native Drivers (and When Not To)

With Reanimated, the question of “using the native driver” becomes a bit different. Reanimated’s entire architecture is built around running animations and gesture logic directly on the UI thread, effectively bypassing the JS bridge for performance-critical operations. So, in a sense, Reanimated *is* your native driver.

When Reanimated is Your Native Driver

You don’t need to explicitly set useNativeDriver: true when using Reanimated. The library handles this for you by executing animations and gestures on the native UI thread. This is its primary advantage.

When You Might Still Need Native Integration (Rarely)

There are edge cases where you might want to directly leverage native modules or custom native code for specific, highly optimized animations that Reanimated might not cover out-of-the-box. For example, if you’re integrating with complex ARKit/ARCore animations or highly specialized hardware interactions. In such cases:

You would typically use Reanimated’s runOnJS to communicate with your native module.
Or, your native module might trigger events that your JavaScript (and subsequently Reanimated) listens to.

However, for the vast majority of UI animations and gesture-driven interactions, Reanimated 3 provides a robust and performant solution without requiring direct native module development. Focus on mastering its declarative and imperative APIs.

Common Mistakes and Lessons Learned

We all make mistakes. It’s part of the learning process. Here are some common traps I’ve fallen into with React Native Reanimated, and what I learned from them.

1. Misunderstanding Worklet Scope

Mistake: Trying to access non-serializable objects (like React refs, complex class instances, or closure variables that aren’t explicitly passed) directly within a worklet.

Lesson: Worklets run in a separate JavaScript context on the UI thread. They can only access serializable data, Shared Values, and functions explicitly passed to them or defined within their scope (and made serializable). Always ensure that any data or functions you use within a worklet are compatible. Use runOnJS for complex inter-thread communication.

2. Forgetting to Install `react-native-gesture-handler` Correctly

Mistake: This is a big one for newcomers. Gesture Handler requires specific setup in your `App.js` or `index.js`. Forgetting to wrap your root component in GestureHandlerRootView or forgetting the native setup for older React Native versions leads to gestures not working at all, or working inconsistently.

Actionable Takeaway: Always follow the official installation guide for react-native-gesture-handler meticulously. It’s usually the first step after installing Reanimated.

3. Overusing `withSpring`

Mistake: While withSpring is fantastic for achieving bouncy, organic animations, using it for every single transition can make your UI feel unpredictable. Sometimes, a simple withTiming with a well-chosen easing function is more appropriate and provides better control.

Lesson: Understand the difference. withTiming is for predictable, duration-based movement. withSpring is for physics-based, less predictable but often more natural movements. Use the right tool for the job.

4. Not Handling `onEnd` Callback Properly

Mistake: Relying solely on onActive for all updates and not defining an onEnd behavior. This can lead to elements snapping back to their original position abruptly or getting stuck.

Lesson: The onEnd callback in gesture handlers is crucial for defining what happens after the user finishes interacting. This is where you’d typically call withSpring to return an element to a resting state or animate it to a new stable position based on the final gesture state.

5. Ignoring Animation Callbacks

Mistake: Starting an animation and then needing to perform an action *after* it completes, but not using the completion callback.

Lesson: Reanimated animation functions like withTiming and withSpring accept an optional callback function as their last argument. This callback is executed on the UI thread once the animation is finished. Use this for sequencing animations or triggering side effects.

Real-World Use Cases and Advanced Patterns

Reanimated 3 is powering some incredibly sophisticated UIs. Here are a few patterns you’ll see and how they’re often implemented:

1. Custom Scroll Animations

Instead of just reacting to scroll events from a standard ScrollView, you can use Reanimated’s useAnimatedScrollHandler to directly drive animations based on scroll position. This allows for parallax effects, sticky headers that transform, or complex animations tied to scrolling progress.

2. Layout Animations

When items are added or removed from a list, or when their positions change, you often want a smooth animation. While React Native’s built-in LayoutAnimation can be brittle, Reanimated (often in conjunction with libraries like moti or custom implementations) can provide much more control over these layout transitions.

3. Interactive Charts and Graphs

Building performant, touch-interactive charts is a prime candidate for Reanimated. You can animate lines, bars, and tooltips based on touch gestures and scroll events, all while maintaining a smooth, native feel.

4. Complex Transitions (e.g., “Hero” Animations)

While not always a built-in feature, the architecture of Reanimated makes advanced transitions possible. By coordinating Shared Values between screens, you can achieve seamless transitions where an element from one screen smoothly morphs into a corresponding element on another.

5. Custom Navigation Transitions

Beyond the standard screen transitions provided by navigation libraries, you can build entirely custom, highly interactive transitions using Reanimated and Gesture Handler, giving your app a unique visual identity.

Conclusion: Elevating Your React Native Animations

React Native Reanimated 3 is, in my opinion, one of the most significant advancements in the React Native ecosystem for a long time. It addresses the core performance and complexity limitations we faced with older animation solutions.

By understanding Shared Values and Worklets, and by leveraging the power of react-native-gesture-handler, you can build animations that are not only visually stunning but also incredibly performant and responsive. It truly unlocks the ability to create those polished, native-like user experiences that users expect.

Don’t be intimidated by the initial learning curve. Start with simple examples, gradually introduce more complex concepts like gestures and sequences, and always keep performance and debugging in mind. The investment will pay dividends in the quality and feel of your applications.

The official Reanimated documentation is also an excellent resource, especially for diving into specific animation utilities and advanced configurations. Check it out:

React Native Reanimated Official Documentation

So, go forth and animate! Your users (and your app’s performance) will thank you.

🎥 Video: 2 hours to master react native find out how to build a video streaming app in part 1

📺 Xem trên YouTube

React Query for React Native: Mastering Data Fetching and State Management

Lập Trình

React Native

21 min
1 tháng ago
1
7

Unlock efficient and robust data fetching in your React Native apps with React Query (TanStack Query). Discover practical tips, common pitfalls, and best practices for managing server state.

Tagged debugging, performance, react-native

The Data Fetching Conundrum in React Native

Alright, let’s talk React Native. We all love building beautiful, performant apps, but if there’s one area that can consistently trip us up, it’s data fetching and state management. Especially when it comes to server state. Think about it: you’re fetching data from an API, then maybe updating it, and then you need to refetch to show the latest information. Without a solid strategy, this quickly devolves into a mess of useEffect hooks, scattered state variables, and race conditions that would make a seasoned developer sweat. I’ve been there. You’re staring at a screen, the UI is out of sync, and you’re not entirely sure *why* that user list isn’t updating. It’s a classic problem.

Historically, we’ve relied on a few approaches. Simple fetch calls inside useEffect are the most basic. Then came libraries like Redux or Zustand for global state, which are great for client-side state, but often become wrappers for asynchronous data operations, leading to boilerplate and complexity. Context API can help, but it’s not designed for managing server cache. We’ve also seen custom hooks, which can be a good step, but managing caching, background updates, and stale data manually is a monumental task.

The core issue is that server state is fundamentally different from client state. Server state is asynchronous, potentially stale, and needs to be fetched, cached, and synchronized. Trying to force it into the same management paradigm as your toggle buttons or form inputs is like using a screwdriver to hammer a nail – it’s not what it’s built for.

Why React Query (TanStack Query)? A Developer’s Perspective

Enter React Query, now known as TanStack Query. This library has been an absolute game-changer for me and many other developers I’ve worked with. It’s specifically designed to handle the complexities of server state in React applications, and yes, that includes React Native. It’s not just another state management library; it’s a data fetching and caching library that drastically simplifies how you interact with your APIs.

What makes it so good? For starters, it’s built with developer experience in mind. It abstracts away so much of the boilerplate and mental overhead associated with data fetching. Think automatic caching, background refetching, request deduplication, optimistic updates, and much more, all with a surprisingly minimal API. It truly feels like it was built by developers who have wrestled with these problems themselves.

From a practical standpoint, I’ve seen projects that were bogged down by custom data fetching logic suddenly become much more maintainable and performant after integrating React Query. Debugging becomes easier because you have a centralized, predictable way of managing your data. The time saved on writing and debugging manual caching and refetching logic can be reinvested in building actual features.

Getting Started: Your First Queries and Mutations

Let’s get hands-on. The entry point for React Query is the QueryClient and QueryClientProvider. You’ll wrap your app (or a relevant part of it) with this provider:

import { QueryClient, QueryClientProvider } from 'react-query'; import { ReactQueryDevtools } from 'react-query/devtools'; // Optional, but highly recommended const queryClient = new QueryClient(); function App() { return (  {/* Your app components here */}  {/* Devtools are great for debugging */}  ); }

Now, the core of React Query revolves around useQuery for fetching data and useMutation for creating, updating, or deleting data. Let’s look at a simple useQuery example to fetch a list of users:

import { useQuery } from 'react-query'; async function fetchUsers() { const response = await fetch('https://api.example.com/users'); if (!response.ok) { throw new Error('Failed to fetch users'); } return response.json(); } function UserList() { const { data: users, isLoading, isError, error } = useQuery('users', fetchUsers); if (isLoading) { return <Text>Loading users...</Text>; } if (isError) { return <Text>Error: {error.message}</Text>; } return ( <FlatList data={users} keyExtractor={item => item.id.toString()} renderItem={({ item }) => <Text>{item.name}</Text>} /> ); }

This is incredibly concise. Let’s break down what’s happening:

'users': This is your query key. It’s a unique identifier for this specific piece of data. It can be a string or an array. React Query uses this key to cache the data.
fetchUsers: This is the query function. It’s an asynchronous function that fetches your data. React Query will call this function when it needs to fetch the data.
data, isLoading, isError, error: These are the amazing return values from useQuery. You get the fetched data directly, along with boolean flags for the loading and error states, and the error object itself. This eliminates the need for manual state management for these common scenarios.

For mutations (POST, PUT, DELETE requests), you use useMutation:

import { useMutation, useQueryClient } from 'react-query'; async function createUser(userData) { const response = await fetch('https://api.example.com/users', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(userData)}); if (!response.ok) { throw new Error('Failed to create user'); } return response.json(); } function CreateUserForm() { const queryClient = useQueryClient(); // Get access to the QueryClient const mutation = useMutation(createUser, { onSuccess: () => { // Invalidate the 'users' query so it refetches the updated list queryClient.invalidateQueries('users'); // Or you could update the cache directly if you know the new data // queryClient.setQueryData('users', (oldData) => [...oldData, newUser]); }, onError: (error) => { console.error('Error creating user:', error); // Show an error message to the user }}); const handleSubmit = async (values) => { mutation.mutate(values); // Trigger the mutation }; return ( <View> {/* ... form elements ... */} <Button title="Create User" onPress={handleSubmit} disabled={mutation.isLoading} /> {mutation.isLoading && <Text>Creating user...</Text>} {mutation.isError && <Text>Creation failed: {mutation.error.message}</Text>} </View> ); }

Here, useMutation takes your mutation function and an optional configuration object. The onSuccess callback is crucial. When a mutation succeeds, you often want to update your cached data. The most common way is to invalidateQueries, which tells React Query that the data associated with that query key is now stale and needs to be refetched the next time it’s accessed.

The Core Concepts: Queries, Mutations, and Invalidation

Let’s dive a bit deeper into what makes React Query tick:

Queries

As we saw, useQuery is for fetching data. It handles fetching, caching, background updates, and retries automatically. The query key is paramount. It must be stable and uniquely identify your data. React Query uses it to manage the lifecycle of your data:

Caching: Once data is fetched, it’s stored in the cache. If you navigate away from a component that uses a query and then come back, React Query can instantly serve the cached data while refetching in the background if needed.
Background Refetching: By default, React Query refetches data when a component mounts, when the window regains focus, or when the network reconnects. This keeps your UI up-to-date without manual intervention.
Stale-While-Revalidate: This is a powerful pattern. When data is considered stale (e.g., after a certain time or when you explicitly invalidate it), React Query will serve the stale data immediately from the cache while initiating a background fetch for fresh data. Once the fresh data arrives, it updates the UI.

Mutations

useMutation is for any operation that modifies data on the server. You define a mutation function that performs the API call. The key to integrating mutations with your cache is the onSuccess or onSettled callbacks, where you typically use queryClient.invalidateQueries or queryClient.setQueryData to update your cache.

Invalidation

Invalidation is the mechanism by which you tell React Query that its cached data is no longer fresh. When you perform a mutation (like creating a new user), the list of users might have changed. Calling queryClient.invalidateQueries('users') will mark the 'users' query as stale. The next time useQuery('users', fetchUsers) is called, it will trigger a refetch.

You can invalidate specific queries using their keys, or you can invalidate all queries by passing `null` or `undefined` (though be cautious with that!). You can also use patterns with query keys. For example, if you have queries like ['todos', todoId], invalidating 'todos' might not be enough. You might need to invalidate specific ones or use a more generic key like 'todos' if that’s how you’ve structured your keys.

The official TanStack Query documentation is an excellent resource for a deeper dive into query key strategies: Query Keys – TanStack Query Docs.

Handling Loading, Error, and Empty States Gracefully

One of the biggest wins of React Query is how it simplifies handling UI states. Remember those scattered useState variables for loading and error? They’re mostly gone.

The `useQuery` hook returns:

isLoading: True when the query is fetching for the first time.
isFetching: True whenever a fetch is in progress (including background refetches).
isError: True if the query encountered an error.
error: The error object if `isError` is true.
isSuccess: True if the query has successfully fetched data.
data: The fetched data, available only when isSuccess is true.

You can leverage these directly in your components:

function UserDetail({ userId }) { const { data: user, isLoading, isError, error } = useQuery(['users', userId], () => fetchUserById(userId)); if (isLoading) { return <ActivityIndicator size="large" />; } if (isError) { return <Text>Error loading user: {error.message}</Text>; } // Data is available here return ( <View> <Text>{user.name}</Text> <Text>{user.email}</Text> </View> ); }

This makes your UI logic much cleaner. You can display skeleton loaders, error messages, or the actual data based on these states.

What about empty states (e.g., a list is fetched but has no items)? React Query doesn’t directly provide an `isEmpty` flag. This is typically handled in your application logic. If data is an array and data.length === 0, you can render an “No items found” message.

I’ve seen developers try to overcomplicate this. For instance, setting a custom `isDataEmpty` state. But in most cases, checking the length of the `data` array after ensuring `isSuccess` is true is sufficient and cleaner.

Advanced Strategies: Prefetching, Hydration, and Background Updates

React Query shines when you start leveraging its more advanced features.

Prefetching

Prefetching is crucial for improving perceived performance. Imagine a user is on a list screen and is likely to click on an item. You can prefetch the data for that item *before* they click.

// In a List component, when an item is visible or hovered (though hover isn't common in RN) const queryClient = useQueryClient(); const handleItemPress = async (item) => { // Prefetch the data for the detail screen await queryClient.prefetchQuery(['users', item.id], () => fetchUserById(item.id)); // Then navigate to the detail screen navigation.navigate('UserDetail', { userId: item.id }); };

When the `UserDetail` screen mounts, the data will already be in the cache, making the transition instant. This is a massive UX win.

Hydration

Hydration is how you bring server-rendered (SSR) or pre-generated data into the React Query cache on the client. If you’re doing SSR with React Native (less common, but possible) or pre-populating data from a native module, you can use queryClient.setQueryData or queryClient.hydrate.

A more practical RN use case might be loading initial data during app startup. You could fetch essential data upfront and hydrate the cache:

// In your App.js or initial setup const queryClient = new QueryClient(); const initialUserData = await fetchInitialUserData(); // Some async function queryClient.setQueryData('users', initialUserData); // Populate cache directly return ( <QueryClientProvider client={queryClient}> {/* ... */} </QueryClientProvider> );

When your components render, useQuery('users', ...) will find the data in the cache immediately. You might still provide a placeholderData or initialData option to useQuery for smoother transitions.

Background Updates and Refetching Intervals

As mentioned, React Query excels at keeping data fresh. You can control this behavior:

staleTime: How long data is considered “fresh” before it’s marked as stale. Defaults to 0.
refetchInterval: Polls the data at a given interval (e.g., every 30 seconds). Useful for live dashboards or constantly changing data. Be mindful of server load.
refetchIntervalInBackground: If set to true, polling continues even when the app is in the background.

For example, to refetch user data every 60 seconds:

const { data: user } = useQuery(['user', userId], () => fetchUser(userId), { refetchInterval: 60000, // 60 seconds });

I’ve found that `refetchInterval` can be a battery drain if not used judiciously. It’s usually better to rely on automatic refetches (window focus, network reconnect) or explicit invalidations unless real-time updates are absolutely critical.

Common Pitfalls and How to Avoid Them

Even with a great library, developers can still stumble. Here are some common issues I’ve seen:

1. Incorrect Query Keys

Problem: Using unstable query keys (e.g., keys that change on every render, like an object literal directly in the array). This can lead to React Query creating multiple instances of the same query or not caching correctly.

Solution: Always use stable, serializable query keys. Strings, numbers, booleans, and arrays of these are ideal. If you need dynamic keys, ensure they are memoized or derived from stable props/state.

Example of bad: useQuery(['user', { id: userId }]...) where the object is created inline.
Example of good: useQuery(['user', userId]...) or memoize the object.

2. Over-reliance on `refetchInterval`

Problem: Using `refetchInterval` for everything, leading to unnecessary server load and battery consumption.

Solution: Favor automatic refetches (window focus, network reconnect) and explicit invalidations. Only use `refetchInterval` for data that truly needs to be polled frequently.

3. Not Handling Loading/Error States Appropriately

Problem: Directly rendering data that might not be there yet, causing errors. Or not providing clear feedback to the user during loading or error states.

Solution: Always check `isLoading`, `isError`, and `isSuccess` flags before accessing `data`. Provide meaningful UI for these states (spinners, error messages).

4. Complex Data Transformation Inside Query Functions

Problem: Putting complex data transformations or business logic inside your query function. This mixes concerns and can make testing harder.

Solution: Keep query functions focused on fetching data. Perform transformations in your components or dedicated utility functions. React Query provides `select` option in `useQuery` for transformations, which is often a cleaner way to do it.

function UserProfile() { const { data: rawUserData, ...rest } = useQuery(['user', userId], fetchUser, { select: (userData) => ({ ...userData, fullName: `${userData.firstName} ${userData.lastName}`})}); if (rest.isLoading) return <Text>Loading...</Text>; if (rest.isError) return <Text>Error</Text>; return <Text>{rawUserData.fullName}</Text>; }

5. Ignoring Mutation Errors

Problem: A mutation fails, but there’s no feedback to the user, and the UI state doesn’t reflect the failure.

Solution: Implement robust `onError` callbacks in `useMutation` to handle errors, log them, and inform the user. You can also use `isError` and `error` from the mutation result.

6. Forgetting to Invalidate Queries After Mutations

Problem: Performing a mutation (e.g., updating a user) but the UI doesn’t update with the new data because the cache wasn’t refreshed.

Solution: Always invalidate relevant queries after mutations that change data. Or, even better, use optimistic updates for a smoother UX.

Optimizing Performance with React Query

Beyond the built-in caching and refetching, you can optimize further:

select option: As shown above, use the `select` option in `useQuery` to transform or filter data *after* it’s fetched but *before* it’s returned by the hook. This avoids refetching the entire dataset if you only need a subset.
Query Deduping: React Query automatically dedupes identical requests that happen within the same timeframe. If multiple components request the same data with the same key, only one fetch will occur.
placeholderData and initialData: These can be used to provide immediate, albeit potentially stale, data to the UI while the fresh data is being fetched. This makes the UI feel more responsive.
Pagination and Infinite Queries: For lists of data, useInfiniteQuery is a powerful tool for implementing features like “load more” or infinite scrolling, efficiently fetching data in chunks.
Devtools: The React Query Devtools are invaluable for visualizing your cache, understanding query states, and debugging. Don’t skip them!

Integrating with Existing Logic and Libraries

React Query plays nicely with others:

Form Libraries (e.g., Formik, React Hook Form): You’ll often use mutations to submit form data. The `onSuccess` callback is perfect for resetting the form or navigating away.
Navigation Libraries (e.g., React Navigation): As shown in the prefetching example, you can prefetch data before navigating to a new screen to ensure a smooth transition.
Authentication and Authorization: You can include authentication tokens in your fetch requests within your query functions. You might also have a query for the current user that you invalidate upon login/logout.
Custom Hooks: React Query hooks are designed to be composed. You can build your own custom hooks that encapsulate specific queries or mutations for reuse across your app.

The key is to remember that React Query manages *server state*. If you have complex client-side state that doesn’t involve fetching from a server (e.g., UI toggles, form input values before submission), you’ll still want to use tools like `useState`, `useReducer`, Zustand, or Redux for that.

When React Query Might Not Be the Answer

While I’m a huge fan, React Query isn’t a silver bullet. There are scenarios where it might be overkill or not the best fit:

Extremely simple apps: If your app has only one or two static API calls, the overhead of setting up React Query might not be worth it. A few `useEffect` calls might suffice.
Real-time data (WebSockets, Server-Sent Events): React Query’s core strength is fetching data on demand and managing its cache. While you can integrate it with real-time data sources, libraries specifically designed for WebSockets or SSE might be more direct for managing those types of streams.
Local-only state with no server interaction: If your state is purely client-side and never touches a server, then React Query isn’t the tool for the job.
Complex client-side state orchestration: For highly interconnected and complex client-side state, a dedicated client-side state manager might offer more powerful tools for managing those specific relationships.

However, for the vast majority of React Native applications that interact with APIs, React Query significantly simplifies and robustifies the data fetching and server state management aspects.

Conclusion: Elevating Your React Native Data Layer

React Query (TanStack Query) has become an indispensable tool in my React Native development arsenal. It tackles the inherent complexities of server state, allowing us to build more reliable, performant, and maintainable applications. By abstracting away the boilerplate of caching, background updates, and state synchronization, it lets us focus on what truly matters: delivering value to our users.

The initial learning curve is minimal, and the benefits you gain in terms of reduced complexity and improved developer experience are immense. From handling basic loading and error states to implementing advanced prefetching and infinite scrolling, React Query provides a cohesive and powerful solution for your React Native data fetching needs. If you’re still wrestling with custom data fetching logic, I highly encourage you to give React Query a serious look. It might just be the missing piece in your React Native architecture.

🎥 Video: React Query in 100 Seconds

📺 Xem trên YouTube

React Query for React Native: Mastering Data Fetching Beyond the Basics

Lập Trình

React Native

18 min
1 tháng ago
1
5

Go beyond basic data fetching in React Native with React Query (TanStack Query). Learn practical patterns, common pitfalls, and scaling strategies for mid to senior developers.

Tagged debugging, performance, react-native

Alright, fellow React Native adventurers. Let’s talk about something that keeps a lot of us up at night: data fetching. We’ve all been there, right? Juggling `useState`, `useEffect`, maybe some global state managers, trying to keep our app’s data in sync with the backend. It’s often a messy, error-prone dance.

For a long time, the go-to was a combination of `fetch` or Axios within `useEffect` hooks, coupled with some basic loading and error state management. But as apps grow, this approach starts to creak. We start worrying about refetching, stale data, cache invalidation, background updates, and, well, the list goes on. It becomes a significant chunk of our development effort, and frankly, it’s not the most exciting part of building mobile apps.

This is where robust data fetching libraries come in, and lately, React Query for React Native (now officially TanStack Query) has been my absolute go-to. It’s not just another tool; it’s a paradigm shift. It takes a lot of the boilerplate and complexity out of managing server state, allowing us to focus on building great features. If you’re coming from a background of managing these concerns manually, or even using simpler state management tools, strap in, because React Query is going to make your life a whole lot easier.

In this post, I want to dive deep into practical, real-world use cases and common challenges you’ll face when implementing React Query in your React Native projects. We’ll cover what makes it tick, how to wield its powerful features effectively, and importantly, the mistakes I’ve made (so you don’t have to!).

The Core of React Query: What It Is and Why It’s a Game Changer

At its heart, React Query is a data-fetching and state management library. But it’s specifically designed for server state. This is a crucial distinction. Think of data that comes from an API – your user profiles, lists of products, comments, etc. This is “server state,” and it behaves very differently from “client state” (like the visibility of a modal or the text in an input field).

Server state is:

Asynchronous
Potentially stale
Shared across components
Difficult to update

React Query addresses these challenges head-on with a suite of powerful features:

Caching: It automatically caches your fetched data. This means subsequent requests for the same data can be served instantly from cache, improving perceived performance dramatically.
Background Refetching: When you navigate back to a screen or re-focus the app, React Query can automatically refetch your data in the background. This ensures your users are always seeing fresh information without them having to manually pull to refresh.
Stale-While-Revalidate: This is a core caching strategy. When data is considered “stale” (after a configurable amount of time), React Query will immediately show the cached data to the user while it fetches fresh data in the background. Once the new data arrives, it updates the UI. This provides a snappy UX without serving outdated information.
Deduplication: If multiple components on your screen request the same data simultaneously, React Query ensures that only one fetch request is actually made to your API.
Automatic Retries: If a network request fails, React Query can automatically retry it a configurable number of times.

This might sound like a lot, but the beauty is that it handles most of this out of the box. You declare what data you need, and React Query takes care of the rest.

Getting Started: Setting Up and First Fetch

Let’s get our hands dirty. First, install the library:

npm install @tanstack/react-query --save
or
yarn add @tanstack/react-query

Next, you need to wrap your application with the QueryClientProvider. This provides the QueryClient instance to your entire app. It’s typically done at the root of your component tree.

// App.js or your root component
import React from 'react';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { ReactQueryDevtools } from '@tanstack/react-query-devtools';
import YourMainApp from './YourMainApp'; // Your main app component
// Create a client
const queryClient = new QueryClient();
function App() {
return (

{/* The React Query DevTools are helpful during development */}



);
}
export default App;

The ReactQueryDevtools are fantastic for debugging. Seriously, turn them on during development. They’ll show you what queries are active, their status, and how often they’re refetching. Priceless.

Now, let’s make our first fetch. You’ll use the useQuery hook. It takes a query key (a unique identifier for your query) and a query function (which fetches your data).

// YourComponent.js
import React from 'react';
import { View, Text, ActivityIndicator } from 'react-native';
import { useQuery } from '@tanstack/react-query';
// A function that fetches your data
const fetchTodos = async () => {
const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
};
function TodosComponent() {
const { data, isLoading, isError, error } = useQuery({
queryKey: ['todos', 1], // Unique key for this query
queryFn: fetchTodos, // The function that fetches data
});
if (isLoading) {
return (
<View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}\u003e
<ActivityIndicator size="large" /\u003e
<Text>Loading todos...</Text>
</View>
);
}
if (isError) {
return (
<View>
<Text>An error occurred: {error.message}</Text>
</View>
);
}
// Data is available
return (
<View>
<Text>Todo Title: {data.title}</Text>
<Text>Completed: {data.completed ? 'Yes' : 'No'}</Text>
</View>
);
}
export default TodosComponent;

Notice how `useQuery` returns `isLoading`, `isError`, and `error` states directly. This simplifies your component logic significantly. You don’t need separate `useState` hooks for these.

Beyond the Basics: Key Features for Real-World Apps

Okay, fetching a single item is cool, but real apps are more complex. Let’s explore features that are crucial for production apps.

Handling Loading and Error States Gracefully

We saw the basic `isLoading` and `isError` flags. But often, you want more granular control. For example, when you’re refetching data in the background, you don’t want to show a full-screen loader again. React Query provides:

isFetching: True when a fetch is in progress, including background fetches.
isInitialLoading: True only during the very first fetch for a query.

This allows you to implement UI patterns like showing a subtle loading indicator (e.g., a spinner in a list item) for background refetches, rather than blocking the entire screen. You can also use these flags to decide whether to show cached data while a background fetch is happening.

For error handling, besides the `error` object, you can configure:

retry: Number of times to retry on failure.
retryDelay: Function to determine the delay between retries.
throwOnError: If `true`, the error will be thrown by the hook and can be caught by your own `try…catch` blocks or higher-order error boundary components. This is great for centralized error handling.

// Example with throwOnError and custom retry
const { data, isLoading, isError, error, isFetching } = useQuery({
queryKey: ['myData'],
queryFn: fetchData,
retry: 3, // Retry up to 3 times on failure
retryDelay: attemptIndex => Math.min(1000 * 2**attemptIndex, 30000), // Exponential backoff, max 30s
throwOnError: true, // Lets you catch errors if needed
});
// In your component:
if (isLoading) return <Spinner />;
if (isError) return <ErrorDisplay message={error.message} />;
// If you use throwOnError, you might wrap this in a try-catch
try {
// ... render data
} catch (e) {
// Handle error globally if not handled by throwOnError or error boundaries
return <ErrorDisplay message={e.message} />;
}

Optimistic Updates: Making Your App Feel Instant

This is where React Query truly shines for perceived performance. Optimistic updates mean you update the UI before the server has confirmed the change. If the server confirms, great. If it fails, you revert the UI.

Imagine a user toggling a “like” button. Instead of showing a loading state for that action, you immediately change the button’s state (e.g., from “Like” to “Liked”) and increment a counter. If the API call succeeds, you’re done. If it fails, you revert the change.

React Query makes this manageable with onMutate, onSuccess, and onError callbacks within the useMutation hook.

// Assuming a mutation for toggling a todo's completion status
const toggleTodoCompletion = async (id, currentStatus) => {
const response = await fetch(`/api/todos/${id}`, {
method: 'PATCH',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ completed: !currentStatus }),
});
if (!response.ok) {
throw new Error('Failed to toggle completion');
}
return response.json();
};
function TodoItem({ todo }) {
const queryClient = useQueryClient();
const mutation = useMutation({
mutationFn: (id) => toggleTodoCompletion(id, todo.completed), // Pass ID to function
onMutate: async (id) => {
// Cancel any outgoing refetches for this specific todo query
// This is important to prevent race conditions where a background refetch
// might overwrite your optimistic update before it's confirmed.
await queryClient.cancelQueries({ queryKey: ['todos', id] });
// Snapshot the previous value
const previousTodo = queryClient.getQueryData(['todos', id]);
// Optimistically update to the new value
queryClient.setQueryData(['todos', id], {
...todo,
completed: !todo.completed, // Flip the status
});
// Return a context with the snapshot so we can revert if necessary
return { previousTodo };
},
onError: (err, id, context) => {
// If the mutation fails, revert to the snapshot
if (context?.previousTodo) {
queryClient.setQueryData(['todos', id], context.previousTodo);
}
// Show a toast or alert for the user
console.error('Failed to toggle todo:', err.message);
},
onSettled: (data, error, id) => {
// Always refetch after error or success to get the latest data
// This ensures consistency if the optimistic update was wrong
// or if there were other changes on the server.
queryClient.invalidateQueries({ queryKey: ['todos', id] });
},
});
return (
<View>
<Text>{todo.title} - {todo.completed ? 'Completed' : 'Pending'}</Text>
<Button
title={mutation.isPending ? 'Saving...' : 'Toggle Completion'}
onPress={() => mutation.mutate(todo.id)}
disabled={mutation.isPending}
/>
</View>
);
}

The key here is `queryClient.cancelQueries` and `queryClient.setQueryData`. You’re manually manipulating the cache. This is powerful but requires careful thought to avoid bugs.

Mutation Madness: POST, PUT, DELETE Like a Pro

While `useQuery` is for fetching, `useMutation` is for performing side effects like creating, updating, or deleting data. It provides similar states to `useQuery`: `isPending`, `isError`, `error`, `isSuccess`.

Beyond optimistic updates, `useMutation` is great for:

Queuing Mutations: If a user rapidly clicks a button multiple times, you might want to queue these actions or disable the button. `useMutation`’s `isPending` state helps here.
Invalidating Queries: After a successful mutation (e.g., creating a new todo), you want to ensure your list of todos is updated. The `onSettled` or `onSuccess` callbacks are perfect for calling `queryClient.invalidateQueries()`. This tells React Query to refetch any queries that depend on that data, keeping your UI in sync automatically.

// Example: Adding a new todo
const addTodo = async (newTodo) => {
const response = await fetch('/api/todos', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(newTodo),
});
if (!response.ok) {
throw new Error('Failed to add todo');
}
return response.json();
};
function AddTodoForm() {
const queryClient = useQueryClient();
const mutation = useMutation({
mutationFn: addTodo,
onSuccess: () => {
// Invalidate the 'todos' query so the list refreshes
queryClient.invalidateQueries({ queryKey: ['todos'] });
// Maybe also invalidate a 'todosCount' query if you have one
// queryClient.invalidateQueries({ queryKey: ['todosCount'] });
},
onError: (err) => {
console.error('Error adding todo:', err.message);
},
});
const handleSubmit = (newTodoText) => {
mutation.mutate({ text: newTodoText, completed: false });
};
return (
<View>
<TextInput placeholder="New Todo" onSubmitEditing={(e) => handleSubmit(e.nativeEvent.text)} /\u003e
{mutation.isPending && <ActivityIndicator />}
</View>
);
}

The `queryKey` in `invalidateQueries` is crucial. You can invalidate specific queries by their exact key, or use wildcards (e.g., `[‘todos’, undefined]`) or even just the first part of the key (e.g., `[‘todos’]`) to invalidate all queries that start with that prefix.

Pagination and Infinite Scrolling: Scaling Your Data

Fetching large datasets requires careful management. React Query provides excellent tools for pagination and infinite scrolling.

For standard pagination (e.g., page 1, page 2, page 3), you’d typically use a query key that includes the page number:

// Fetching a specific page
const fetchPaginatedTodos = async ({ pageParam }) => {
const page = pageParam || 1; // Default to page 1 if pageParam is undefined
const response = await fetch(`/api/todos?page=${page}`);
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
};
function PaginatedTodos() {
const { data, isLoading, isError, error, isFetchingNextPage, hasNextPage, fetchNextPage } = useInfiniteQuery({
queryKey: ['paginatedTodos'],
queryFn: fetchPaginatedTodos,
initialPageParam: 1, // Start with page 1
getNextPageParam: (lastPage, allPages) => {
// Determine the next page number. This depends on your API response.
// If lastPage.nextCursor exists, use it. Otherwise, return undefined to stop.
return lastPage.nextPage || undefined;
},
});
// ... render data, with a button to call fetchNextPage when hasNextPage is true ...
if (isLoading) return <Loader />;
if (isError) return <ErrorDisplay />;
return (
<View>
{data.pages.map((page, i) => (
<View key={i}>
{page.todos.map(todo => (
<Text key={todo.id}>{todo.title}</Text>
))}
</View>
))}
{isFetchingNextPage ? (
<ActivityIndicator />
) : hasNextPage ? (
<Button title="Load More" onPress={() => fetchNextPage()} /\u003e
) : (
<Text>End of list</Text>
)}
</View>
);
}

The `useInfiniteQuery` hook is specifically designed for this. The `getNextPageParam` function is crucial: it tells React Query how to get the parameter for the *next* page. If it returns `undefined`, React Query knows there are no more pages.

For infinite scrolling, you’d typically integrate `fetchNextPage` with a FlatList‘s onEndReached prop.

Caching Strategies and Refetching: The Sweet Spot

This is where React Query truly simplifies things, but also where you need to understand the knobs to turn.

staleTime: How long data is considered “fresh” before it’s considered “stale.” If `staleTime` is 0 (the default), data is considered stale immediately after being fetched. If it’s 5 minutes, data is fresh for 5 minutes.
gcTime: Garbage Collection Time. How long inactive (unmounted or unused) cached data is kept in memory. Defaults to 5 minutes. If set to 0, data is never garbage collected. This is useful for keeping data around longer if users might navigate back to it.
refetchOnWindowFocus: Automatically refetches when the window/app regains focus. Defaults to `true`.
refetchOnMount: Automatically refetches when a component mounts, if the data is stale. Defaults to `true`.
refetchInterval: Refetches data at a specified interval (e.g., every 30 seconds). Useful for things like live dashboards.

The “sweet spot” is often about configuring `staleTime` and `gcTime` appropriately for your data. For data that changes frequently or is critical to be up-to-date (like a user’s account balance), you might want a low `staleTime` (or even 0) and rely on `refetchOnWindowFocus` or `refetchInterval`.

For data that is more static (like a list of countries), you can set a higher `staleTime` to reduce unnecessary network requests. If a user navigates away and back within that `staleTime`, they’ll get the cached data instantly without a refetch.

You can set these options globally in your QueryClient configuration, or per query/mutation.

// Global configuration
const queryClient = new QueryClient({
defaultOptions: {
queries: {
staleTime: 1000 * 60 * 5, // 5 minutes
gcTime: 1000 * 60 * 60 * 24, // 24 hours
refetchOnWindowFocus: true,
retry: 3,
},
mutations: {
// Options for mutations if needed
},
},
});

Debugging and Performance Tuning

This is where the ReactQueryDevtools become your best friend. They visually show you:

Which queries are active.
Their status (fetching, paused, inactive, error).
How much data they hold.
When they were last updated and how often they refetch.
The query key and options used.

Beyond the devtools:

Logging: Use `console.log` judiciously within your `queryFn` to see when fetches are happening.
Network Inspector: The built-in React Native debugger or tools like Flipper’s Network plugin are essential for inspecting actual API requests and responses.
Performance Profiling: React’s Profiler can help identify rendering bottlenecks caused by component updates due to data changes.

A common performance issue is an excessive number of refetches. This can happen if:

You have many components using the same query key but with slightly different options that React Query doesn’t see as identical.
`refetchOnMount` or `refetchOnWindowFocus` are too aggressive for your use case.
Incorrect `staleTime` leading to frequent refetches when stale data would suffice.

To tune, start by looking at the devtools. If a query refetches more often than you expect, examine its `staleTime` and the `refetchOn…` options. If you have many components triggering refetches, ensure they are using consistent `queryKey`s.

Common Pitfalls and How to Avoid Them

Even with a powerful library, you can still trip up. Here are some common mistakes I’ve seen and made:

Over-reliance on `invalidateQueries` for everything: While powerful, blindly invalidating broad query keys can lead to more refetches than necessary. Be specific when possible. Instead of `queryClient.invalidateQueries([‘users’])` after updating a single user, use `queryClient.invalidateQueries([‘users’, userId])` if that’s how you’ve structured your keys.
Not handling `isInitialLoading` vs. `isFetching`: This can lead to flashing loading spinners when background refetches occur, which is a poor user experience. Differentiate between the first load and subsequent refetches.
Complex `queryFn`s: Keep your query functions focused on fetching data. If they involve complex logic or multiple API calls, consider breaking them down or using dedicated utility functions.
Not using `queryKey` effectively: A well-structured `queryKey` (often an array like `[‘posts’, postId, ‘comments’]`) is crucial for cache invalidation and deduping. If you pass objects to `useQuery`, make sure they are stable references or you’re using a hashing mechanism. Arrays are generally preferred.
Ignoring `gcTime`: While you might want data to stay around for a while, a very high `gcTime` for infrequently accessed data can lead to memory bloat in your app. Monitor memory usage if you suspect this.
Overlapping `staleTime` and `refetchOnMount`: If `staleTime` is set to a long duration, but `refetchOnMount` is `true`, you might still be refetching data more often than intended. Understand how these options interact.
Mutating array/object state directly in `onMutate`: When using `setQueryData` to update cache optimistically, be mindful of immutability. If you mutate an object or array directly, it can cause unexpected side effects or prevent React from detecting changes. Always spread or use immutable update patterns.

When React Query Might Not Be the Answer

React Query is fantastic for server state. But it’s not a silver bullet for all state management.

Complex Client-Side State: If you have deeply nested, highly interactive client-side state that doesn’t involve server communication (e.g., a complex form builder or a drag-and-drop interface), a dedicated client-state manager like Zustand, Jotai, or even React Context might be more appropriate or simpler to integrate.
Very Simple Apps: For extremely small, one-off applications with minimal data fetching, the overhead of setting up and learning React Query might outweigh its benefits. A few `useState`/`useEffect` hooks might suffice.
Real-time Data (WebSockets): While you *can* integrate WebSocket listeners with React Query (by using `refetchInterval` or manually updating cache), dedicated real-time solutions or libraries might offer a more streamlined experience for highly dynamic, real-time data streams.

The key is to understand the problem domain. React Query excels at making data fetching and caching predictable, performant, and less error-prone. Use it where those problems exist.

Conclusion: Elevating Your React Native Data Game

Managing data in React Native applications can be a significant challenge. By leveraging React Query for React Native (TanStack Query), you gain a powerful, opinionated library that significantly simplifies server state management. Its built-in caching, background refetching, optimistic updates, and mutation handling capabilities can drastically improve your app’s performance and your development efficiency.

Remember to explore the official documentation for comprehensive details. The team behind TanStack Query maintains excellent resources, including guides and API references, that are invaluable for deeper dives. [Check out the TanStack Query documentation here](https://tanstack.com/query/latest).

While there’s a learning curve, especially around configuring cache behavior and mutations, the payoff in terms of a more robust and performant application is immense. Start with the basics, progressively introduce more advanced features like optimistic updates and infinite queries, and always, always use the devtools. Your future self, and your users, will thank you for it.

🎥 Video: State Management in React Native | React Universe On Air #19

📺 Xem trên YouTube

Redux Toolkit in React Native: Essential Setup and Real-World Patterns

Lập Trình

React Native

16 min
1 tháng ago
1
10

Master Redux Toolkit in React Native with this practical guide. Learn essential setup, common patterns, and real-world strategies to manage your app’s state effectively.

Tagged debugging, performance, react-native

Alright, let’s talk state management in React Native. If you’ve been around the block, you know the pain. ‘Plain’ Redux? It’s powerful, sure, but the boilerplate can feel like trying to build a spaceship with a toothpick. That’s where Redux Toolkit (RTK) swoops in, like a much-needed superhero. If you’re looking to get your React Native app’s state sorted without losing your mind, you’re in the right place. This isn’t about fluff; it’s about getting practical with Redux Toolkit React Native.

Why Redux Toolkit? Because Redux Itself is a Bit Much.

Before RTK, managing state with Redux in React Native often involved a lot of ceremony. You needed action types, action creators, reducers, and then the whole wiring-up process with `react-redux`. It’s a lot to keep track of, and frankly, easy to mess up. RTK is Redux’s official, opinionated, batteries-included solution designed to simplify all of that. It streamlines common tasks, reduces boilerplate, and helps prevent common bugs.

Think of it this way: Redux gives you a robust engine for state management. Redux Toolkit gives you a fully assembled, high-performance race car with all the safety features built-in. You can jump in and drive, rather than spending hours assembling the chassis, engine, and gearbox.

The core philosophy of RTK is to make Redux easier to use while ensuring you’re following best practices. It bundles the most commonly used Redux add-ons like Redux Thunk (for async logic) and Immer (for immutable state updates) right out of the box, with sensible defaults.

The Core Trio: configureStore, createSlice, createAsyncThunk

When you start with Redux Toolkit in React Native, these three are your bread and butter:

configureStore(): This is your central hub. It’s a super-powered version of the Redux `createStore` function. It automatically sets up the Redux DevTools Extension and includes Redux Thunk middleware by default. You pass it an object where keys are your slice names and values are your reducer functions.
createSlice(): This is where the magic for defining your state slices happens. It takes a name, an initial state, and a `reducer` object. RTK automatically generates action creators for your reducers and handles the immutability for you thanks to Immer. You get reducers and action creators in one neat package.
createAsyncThunk(): For handling asynchronous logic, like fetching data from an API. It abstracts away the common patterns for dispatching actions before, during, and after an async operation (pending, fulfilled, rejected).

Setting Up Your First Redux Toolkit in React Native Project

Let’s get our hands dirty with a basic setup. For a new project, you’d typically install the necessary packages:

npm install redux @reduxjs/toolkit react-redux
or
yarn add redux @reduxjs/toolkit react-redux

Next, you need to create your store and wrap your app with the Provider component from react-redux.

1. Create your store (`src/store.js` or similar):

import { configureStore } from '@reduxjs/toolkit';
export const store = configureStore({
reducer: {
// Your slices will go here
},
});

2. Wrap your app with the Provider (`App.js` or your root component):

import React from 'react';
import { Provider } from 'react-redux';
import { store } from './store'; // Adjust path as needed
import MainAppNavigator from './navigation/MainAppNavigator'; // Your root navigator
function App() {
return (



);
}
export default App;

And that’s it for the basic wiring. Now, you can start defining your state slices.

Slices: Your State’s Building Blocks

Slices are the heart of Redux Toolkit. Each slice typically manages a distinct piece of your application’s state. Let’s say we’re building a simple to-do app.

Create a slice for todos (`src/features/todos/todosSlice.js`):

import { createSlice } from '@reduxjs/toolkit';
const initialState = [
{ id: 1, text: 'Learn React Native', completed: false },
{ id: 2, text: 'Build a cool app', completed: false },
];
const todosSlice = createSlice({
name: 'todos',
initialState,
reducers: {
addTodo(state, action) {
// Immer allows us to write "mutating" logic, RTK makes it immutable
state.push({ id: Date.now(), text: action.payload, completed: false });
},
toggleTodo(state, action) {
const todo = state.find(t => t.id === action.payload);
if (todo) {
todo.completed = !todo.completed;
}
},
removeTodo(state, action) {
return state.filter(todo => todo.id !== action.payload);
},
},
});
export const { addTodo, toggleTodo, removeTodo } = todosSlice.actions;
export default todosSlice.reducer;

Now, integrate this slice into your store:

// src/store.js
import { configureStore } from '@reduxjs/toolkit';
import todosReducer from './features/todos/todosSlice';
export const store = configureStore({
reducer: {
todos: todosReducer,
},
});

Connecting to your React Native components:

You’ll use the `useSelector` and `useDispatch` hooks from react-redux.

// src/features/todos/TodoList.js
import React, { useState } from 'react';
import { View, Text, Button, FlatList, TextInput, TouchableOpacity } from 'react-native';
import { useSelector, useDispatch } from 'react-redux';
import { addTodo, toggleTodo, removeTodo } from './todosSlice';
function TodoList() {
const todos = useSelector((state) => state.todos);
const dispatch = useDispatch();
const [newTodoText, setNewTodoText] = useState('');
const handleAddTodo = () => {
if (newTodoText.trim()) {
dispatch(addTodo(newTodoText.trim()));
setNewTodoText('');
}
};
return (

Why this works (and is great):

Immutability Simplified: You write code that looks like direct mutation (e.g., state.push(...)), but Immer under the hood ensures immutability. This is crucial for Redux to track changes and for React to re-render efficiently.
Co-location: Reducers and action creators for a specific piece of state are defined together, making it easier to understand and maintain.
Auto-generated Actions: No more manually defining action types and creators for simple updates.

Handling Asynchronous Operations with createAsyncThunk

Most real-world apps involve fetching data. This is where createAsyncThunk shines.

Let’s imagine fetching a list of users from an API.

// src/features/users/usersSlice.js
import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';
import axios from 'axios'; // Assuming you use axios
// Define the thunk
export const fetchUsers = createAsyncThunk(
'users/fetchUsers',
async (_, { rejectWithValue }) => {
try {
const response = await axios.get('https://jsonplaceholder.typicode.com/users');
return response.data; // This will be the 'fulfilled' payload
} catch (error) {
// Use rejectWithValue to pass specific error info to the rejected action
return rejectWithValue(error.response.data || 'Something went wrong');
}
}
);
const initialState = {
users: [],
status: 'idle', // 'idle' | 'loading' | 'succeeded' | 'failed'
error: null,
};
const usersSlice = createSlice({
name: 'users',
initialState,
reducers: {},
extraReducers: (builder) => {
builder
.addCase(fetchUsers.pending, (state) => {
state.status = 'loading';
})
.addCase(fetchUsers.fulfilled, (state, action) => {
state.status = 'succeeded';
state.users = action.payload;
})
.addCase(fetchUsers.rejected, (state, action) => {
state.status = 'failed';
state.error = action.payload; // Error payload from rejectWithValue
});
},
});
export default usersSlice.reducer;

Integrate this into your store and dispatch the thunk from your component:

// src/store.js (add usersReducer)
import { configureStore } from '@reduxjs/toolkit';
import todosReducer from './features/todos/todosSlice';
import usersReducer from './features/users/usersSlice'; // Import users reducer
export const store = configureStore({
reducer: {
todos: todosReducer,
users: usersReducer,
},
});
// src/features/users/UserList.js (example component)
import React, { useEffect } from 'react';
import { View, Text, Button, ActivityIndicator } from 'react-native';
import { useSelector, useDispatch } from 'react-redux';
import { fetchUsers } from './usersSlice';
function UserList() {
const dispatch = useDispatch();
const { users, status, error } = useSelector((state) => state.users);
useEffect(() => {
if (status === 'idle') {
dispatch(fetchUsers());
}
}, [status, dispatch]);
if (status === 'loading') {
return (


Loading users...

);
}
if (status === 'failed') {
return (

Error: {error}

Why this is a win:

Standardized Async Logic: You have a consistent way to handle the lifecycle of async operations (pending, fulfilled, rejected).
Automatic State Updates: The `extraReducers` setup automatically updates the state based on the thunk’s status.
Error Handling: rejectWithValue provides a clean way to pass error details to your state.

RTK Query: The Game Changer for API Data

If you’re dealing with a lot of API interactions, you absolutely must look at RTK Query. It’s part of Redux Toolkit but is a separate package, designed to simplify data fetching, caching, and synchronization.

It’s not just about fetching; it’s about making your data layer intelligent. It handles loading states, errors, caching, refetching, and even background updates automatically. For many React Native apps, RTK Query can significantly reduce the amount of custom Redux logic you need to write.

Setting up RTK Query involves defining an API slice using createApi, specifying your base URL, and defining endpoints for your data operations.

Example snippet (conceptual):

// src/services/api.js
import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';
export const api = createApi({
reducerPath: 'api',
baseQuery: fetchBaseQuery({ baseUrl: 'https://api.example.com/' }),
endpoints: (builder) => ({
getProducts: builder.query({
query: () => 'products',
}),
addProduct: builder.mutation({
query: (newProduct) => ({
url: 'products',
method: 'POST',
body: newProduct,
}),
}),
}),
});
export const { useGetProductsQuery, useAddProductMutation } = api;

You’d then add the API reducer to your store and use the generated hooks in your components. This is a massive topic on its own, and I highly recommend diving into the official RTK Query documentation to see its full power.

Structuring Your Redux Toolkit for Scalability

As your app grows, so does its state. Here are some patterns that help keep things organized:

Feature-Based Slicing: As shown in the examples, group related state, reducers, and actions into feature folders (e.g., features/auth, features/products, features/cart). This is much more scalable than having a single folder for all reducers and actions.
Separate API Slice: If you’re using RTK Query, dedicate a file or folder for your API definitions.
Shared Logic: For common reducer logic (like handling pending/fulfilled/rejected states for multiple async operations), you can create reusable reducer functions or use `createEntityAdapter` which is fantastic for managing collections of items.
Selectors: Use `createSelector` from `reselect` (or RTK’s built-in memoization features) to create memoized selectors. This prevents unnecessary re-renders of your components when the part of the state they care about hasn’t actually changed.

Example using `createEntityAdapter` for a list of items:

// src/features/items/itemsSlice.js
import { createSlice, createEntityAdapter, createAsyncThunk } from '@reduxjs/toolkit';
const itemsAdapter = createEntityAdapter({
selectId: (item) => item.id,
sortComparer: (a, b) => a.name.localeCompare(b.name), // Example sorting
});
const initialState = itemsAdapter.getInitialState({
status: 'idle',
error: null,
});
export const fetchItems = createAsyncThunk('items/fetchItems', async () => {
// ... fetch items ...
return response.data;
});
const itemsSlice = createSlice({
name: 'items',
initialState,
reducers: {
// Add, update, delete items using adapter methods
addItem: itemsAdapter.addOne,
updateItem: itemsAdapter.updateOne,
removeItem: itemsAdapter.removeOne,
},
extraReducers: (builder) => {
builder
.addCase(fetchItems.pending, (state) => {
state.status = 'loading';
})
.addCase(fetchItems.fulfilled, (state, action) => {
state.status = 'succeeded';
itemsAdapter.setAll(state, action.payload); // Upsert all items
})
.addCase(fetchItems.rejected, (state, action) => {
state.status = 'failed';
state.error = action.payload;
});
},
});
export const { addItem, updateItem, removeItem } = itemsSlice.actions;
// Export selectors generated by the adapter
export const { selectAll: selectAllItems, selectById: selectItemById } = itemsAdapter.getSelectors(state => state.items);
export default itemsSlice.reducer;

This is incredibly useful for managing normalized state, which is a more advanced but very powerful pattern for large applications.

Common Pitfalls and How to Avoid Them

Even with RTK, you can still run into issues. Here are some I’ve seen:

Over-nesting State: Just because RTK makes it easy to define slices doesn’t mean you should have 50 tiny slices for a small app. Aim for logical groupings. Too many slices can lead to a lot of boilerplate in your store configuration.
Not Using `createAsyncThunk` for API Calls: Manually dispatching pending/fulfilled/rejected actions for every API call is error-prone and verbose. Stick to createAsyncThunk or RTK Query.
Ignoring the `status` field: When using async thunks or RTK Query, always account for the ‘loading’, ‘succeeded’, and ‘failed’ states in your UI. Forgetting this leads to janky UIs or broken user experiences.
Mutating State Outside of Reducers: This is the cardinal sin of Redux. Immer helps, but if you’re not careful about where you dispatch actions and what logic is in your reducers, you can still break immutability. Always ensure only reducers (or RTK Query mutations) modify state.
Forgetting to Add Reducers to `configureStore`: A simple oversight that will leave you wondering why your state isn’t updating. Double-check your store configuration.
`useSelector` Performance: If a component re-renders too often, check your `useSelector` usage. Ensure you’re selecting only the minimal data needed. For complex derivations or large state objects, memoized selectors (via `createSelector`) are essential.

When Redux Toolkit Might Be Overkill (And What to Use Instead)

Let’s be honest, for very simple apps or small components, Redux Toolkit can feel like bringing a sledgehammer to crack a nut. If your state is minimal, local to a few components, and doesn’t need to be shared globally, consider these alternatives:

React’s Built-in State Management: useState and useReducer are perfect for local component state.
React Context API: For sharing state down the component tree without prop drilling, but without the strict predictability and tooling of Redux. Be mindful of performance with Context if updates are very frequent.
Zustand, Jotai, Recoil: These are other excellent global state management libraries that are often simpler and less opinionated than Redux. They might be a better fit if you find Redux’s core concepts (reducers, actions, immutability) to be more overhead than you need.

The key is to choose the right tool for the job. For complex global state, especially with asynchronous operations and a need for predictable state changes, Redux Toolkit is a top-tier choice in React Native.

Conclusion: Embracing Efficient State Management

Redux Toolkit has revolutionized how we approach state management in React applications, and React Native is no exception. By adopting patterns like feature-based slicing, leveraging createAsyncThunk for async logic, and exploring the power of RTK Query, you can build robust, maintainable, and performant mobile applications.

It’s not about blindly following a pattern; it’s about understanding the ‘why’ behind RTK’s design: to make Redux easier, more predictable, and less error-prone. So, go forth, configure your store, create your slices, dispatch your thunks, and manage your React Native app’s state like a pro!

🎥 Video: Full Stack React Django DRF | Chat App | Install MUI and integrate it into the existing project

📺 Xem trên YouTube

Redux Toolkit in React Native: Setup and Essential Patterns for Scalability

Lập Trình

React Native

21 min
1 tháng ago
1
7

Mastering Redux Toolkit in React Native. Learn practical setup, essential patterns, and real-world tips for building scalable and maintainable mobile applications. Avoid common pitfalls.

Tagged debugging, performance, react-native

Introduction: Why Redux Toolkit for React Native?

Alright, fellow React Native developers, let’s talk about state management. If you’ve been in the game for a while, you’ve probably wrestled with Redux in its… let’s call it ‘traditional’ form. You know, the boilerplate, the `actionTypes`, the `actionCreators`, the `reducers` that look like they were written by a committee in the dark. It worked, sure, but it was verbose, error-prone, and frankly, a bit of a drag to maintain, especially in the fast-paced world of mobile development.

Enter Redux Toolkit (RTK). If you haven’t jumped on this train yet, you absolutely should. It’s the official, opinionated, batteries-included toolset for efficient Redux development. And for React Native projects, it’s a game-changer. Why? Because it significantly reduces boilerplate, enforces best practices by default, and makes Redux development much more enjoyable and scalable. We’re talking about fewer bugs, faster development cycles, and a codebase that’s a joy (or at least, less of a pain) to work with.

In this guide, we’re going to dive deep into setting up Redux Toolkit in a React Native project and explore the essential patterns that will make your apps robust and maintainable. We’ll cover the nitty-gritty, the ‘why’ behind the patterns, and some hard-earned lessons from the trenches. Let’s get started.

Setting Up Redux Toolkit in Your React Native Project

The setup is surprisingly straightforward. If you’re starting a new project, you might have the option to include Redux during the project initialization. But for an existing project, it’s just a few packages to install.

First, ensure you have the core Redux and React Redux libraries:

npm install redux react-redux --save
or
yarn add redux react-redux

Then, install Redux Toolkit itself:

npm install @reduxjs/toolkit --save
or
yarn add @reduxjs/toolkit

That’s it for the packages. Now, let’s wire it up.

The Store: Your Single Source of Truth

The heart of any Redux application is the store. Redux Toolkit provides a convenient `configureStore` function that simplifies store setup and includes sensible defaults for common configurations, like automatic `redux-thunk` middleware integration (which we’ll discuss later for async operations).

Let’s create a store file (e.g., src/store.js or app/store.js):

import { configureStore } from '@reduxjs/toolkit';
export const store = configureStore({
reducer: { /* your reducers will go here */ },
});
// Infer the `RootState` and `AppDispatch` types from the store itself
export type RootState = ReturnType;
// Inferred type: {posts: PostsState, comments: CommentsState, users: UsersState}
export type AppDispatch = typeof store.dispatch;

Notice the TypeScript type inference. If you’re using TypeScript (highly recommended for larger projects), this is incredibly useful for ensuring type safety across your app. `RootState` will represent the shape of your entire Redux state, and `AppDispatch` will be the typed version of your dispatch function.

Connecting to Your React Native App

To make the store available to your React components, you need to wrap your root component with the `Provider` from `react-redux`. This is typically done in your `App.js` or `index.js` file.

// App.js
import React from 'react';
import { Provider } from 'react-redux';
import { store } from './src/store'; // Adjust path as needed
import YourRootComponent from './YourRootComponent'; // Your main app component
const App = () => {
return (
<Provider store={store}>
<YourRootComponent />
</Provider>
);
};
export default App;

And in `YourRootComponent` (or wherever your navigation stack starts), you can now access the Redux store using hooks like `useSelector` and `useDispatch`.

Core Concepts: Slices, Reducers, and Actions

This is where Redux Toolkit really shines. It introduces the concept of a slice, which is a collection of Redux reducer logic and actions for a single feature of your application.

Introducing `createSlice`

Instead of manually defining action types, action creators, and reducers, `createSlice` abstracts this away. You define your initial state, your reducers (as functions that modify the state immutably), and `createSlice` automatically generates the corresponding action creators and action types.

Let’s create a slice for a hypothetical user profile feature (e.g., src/features/user/userSlice.js):

import { createSlice, PayloadAction } from '@reduxjs/toolkit';
interface UserState {
name: string | null;
email: string | null;
isLoggedIn: boolean;
}
const initialState: UserState = {
name: null,
email: null,
isLoggedIn: false,
};
export const userSlice = createSlice({
name: 'user',
initialState,
reducers: {
setUserProfile: (state, action: PayloadAction<{ name: string, email: string }>) => {
state.name = action.payload.name;
state.email = action.payload.email;
state.isLoggedIn = true;
},
clearUserProfile: (state) => {
state.name = null;
state.email = null;
state.isLoggedIn = false;
},
// You can even define reducers for actions generated by createAsyncThunk here
},
});
// Action creators are generated for each case reducer function
export const { setUserProfile, clearUserProfile } = userSlice.actions;
export default userSlice.reducer;

Why this is awesome:

Immutability by default: RTK uses Immer under the hood. This means you can write “mutating” logic within your reducers (like `state.name = …`), and Immer will handle the immutable updates correctly. This is a huge win for developer experience and reduces common immutability bugs.
Co-location: All related logic (state, reducers, actions) for a feature is in one place (the slice file). This makes it much easier to find and manage.
Reduced boilerplate: No more separate `actionTypes.js`, `actions.js`, and `reducers.js` files for every little thing.

Integrating Slices into the Store

Now, let’s connect our `userSlice` to the main store. We’ll update our src/store.js:

import { configureStore } from '@reduxjs/toolkit';
import userReducer from './features/user/userSlice'; // Adjust path
export const store = configureStore({
reducer: {
user: userReducer, // 'user' will be the key in your state object
// Add other reducers here as you create them
},
});
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Now, your state will look something like this:

{
user: {
name: "John Doe",
email: "john.doe@example.com",
isLoggedIn: true
}
}

Using State and Actions in Components

In your React Native components, you’ll use the `useSelector` hook to get data from the store and the `useDispatch` hook to dispatch actions.

// src/components/UserProfile.js (Example)
import React from 'react';
import { View, Text, Button } from 'react-native';
import { useSelector, useDispatch } from 'react-redux';
import { RootState, AppDispatch } from '../store'; // Import types
import { clearUserProfile } from '../features/user/userSlice';
const UserProfile = () => {
const dispatch = useDispatch<AppDispatch>();
const user = useSelector((state: RootState) => state.user);
const handleLogout = () => {
dispatch(clearUserProfile());
};
return (
<View>
{user.isLoggedIn ? (
<>
<Text>Welcome, {user.name}!</Text>
<Text>Email: {user.email}</Text>
<Button title="Logout" onPress={handleLogout} />
</\gt>
) : (
<Text>Please log in.</Text>
)}
</View>
);
};
export default UserProfile;

Again, the TypeScript types make this a breeze to work with, preventing typos and ensuring you’re accessing the state correctly.

The Power of `configureStore`

We briefly touched on `configureStore`. Let’s elaborate on why it’s so great and what it does under the hood:

Automatic `redux-thunk` Middleware: By default, `configureStore` includes `redux-thunk`, which is essential for handling asynchronous actions (like API calls). You don’t need to install or configure it separately.
Multiple Reducers: It accepts a `reducer` argument which can be a single root reducer or an object of reducers, allowing you to combine slices easily.
DevTools Extension Support: It automatically sets up Redux DevTools Extension integration, which is invaluable for debugging. Make sure you have the browser extension installed if you’re developing on web, or the standalone app for mobile debugging.
Immer Integration: As mentioned, it integrates Immer for simplified immutable state updates.
Default Middleware: It includes a sensible set of default middleware. You can also provide your own via the `middleware` option if needed.

Using `configureStore` is the recommended way to set up your store with Redux Toolkit. It abstracts away a lot of the complexity and configuration that used to be a barrier to entry for Redux.

Handling Asynchronous Logic with Redux Toolkit (RTK Query)

This is a big one. In any real-world app, you’ll be fetching data from APIs. Traditionally, this involved `redux-thunk` or `redux-saga` and a lot of manual setup for loading states, error handling, and caching.

Redux Toolkit introduces RTK Query, a powerful data fetching and caching solution that lives *within* your Redux store. It dramatically simplifies data fetching, caching, and synchronization for your application.

Setting Up RTK Query

First, install RTK Query:

npm install @reduxjs/toolkit --save
or
yarn add @reduxjs/toolkit

Note: RTK Query is part of `@reduxjs/toolkit`, so no separate install is needed if you already have RTK. You’ll primarily use `createApi`.

`createApi` for API Definitions

You define your API endpoints and how to fetch data using `createApi`. This single function generates React hooks for data fetching, caching, and state updates, as well as Redux actions and reducers.

Let’s create an API definition for fetching posts (e.g., src/features/api/apiSlice.js):

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';
interface Post {
userId: number;
id: number;
title: string;
body: string;
}
// Define a service using a base URL and expected endpoints
export const apiSlice = createApi({
reducerPath: 'api',
baseQuery: fetchBaseQuery({ baseUrl: 'https://jsonplaceholder.typicode.com' }),
endpoints: (builder) => ({
getPosts: builder.query<Post[], void>({
query: () => '/posts',
}),
getPostById: builder.query<Post, number>({
query: (id) => `/posts/${id}`,
}),
// You can define mutations (POST, PUT, DELETE) here too
}),
});
// Export hooks for usage in functional components, which are
// auto-generated based on the defined endpoints
export const { useGetPostsQuery, useGetPostByIdQuery } = apiSlice;

Key concepts here:

`reducerPath`: The key under which the API’s cache will be stored in your Redux state.
`baseQuery`: Configures the base URL and any default headers for your API requests.
`endpoints`: Where you define your queries (`builder.query`) for fetching data and mutations (`builder.mutation`) for modifying data.
Auto-generated hooks: `useGetPostsQuery` is an example of a hook automatically created by RTK Query.

Integrating RTK Query into the Store

RTK Query needs its own reducer registered in your Redux store.

// src/store.js (updated)
import { configureStore } from '@reduxjs/toolkit';
import userReducer from './features/user/userSlice';
import { apiSlice } from './features/api/apiSlice'; // Import apiSlice
export const store = configureStore({
reducer: {
user: userReducer,
[apiSlice.reducerPath]: apiSlice.reducer, // Add RTK Query reducer
},
// Add the api reducer to the store using the apiSlice.reducerPath as the key
middleware: (getDefaultMiddleware) =>
getDefaultMiddleware().concat(apiSlice.middleware), // Add RTK Query middleware
});
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Using RTK Query Hooks in Components

Now, you can use the generated hooks directly in your React Native components. RTK Query handles the loading states (`isLoading`), error states (`isError`), and the fetched data (`data`) automatically.

// src/screens/PostsScreen.js (Example)
import React from 'react';
import { View, Text, FlatList, ActivityIndicator, Button } from 'react-native';
import { useGetPostsQuery } from '../features/api/apiSlice';
const PostsScreen = () => {
const { data: posts, error, isLoading } = useGetPostsQuery();
if (isLoading) {
return (
<View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
<ActivityIndicator size="large" />
</View>
);
}
if (error) {
return (
<View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
<Text>Error loading posts: {JSON.stringify(error)}</Text>
</View>
);
}
return (
<FlatList
data={posts}
keyExtractor={(item) => item.id.toString()}
renderItem={({ item }) => (
<View style={{ padding: 10 }}>
<Text style={{ fontWeight: 'bold' }}>{item.title}</Text>
<Text>{item.body.substring(0, 50)}...
)}
/>
);
};
export default PostsScreen;

This is phenomenal. You get built-in caching, background refetching, and automatic state updates for free. You can also add mutations, invalidation strategies, and more to handle complex data flows without writing tons of repetitive code.

Real-World Patterns and Best Practices

While Redux Toolkit simplifies a lot, adopting good patterns is still key for maintainability and scalability.

Feature-Based Slices

Organize your Redux state and logic by feature, not by type (e.g., not `actions.js`, `reducers.js`). This is what `createSlice` encourages. Have a directory like `src/features/` and within it, create subdirectories for each feature (e.g., `user`, `products`, `cart`). Each feature directory would contain its slice file(s), and potentially its RTK Query API definitions if they are feature-specific.

Centralized API Definition

For RTK Query, it often makes sense to have a dedicated `src/features/api/apiSlice.js` (or similar) where you define all your API endpoints. This keeps your API layer organized. However, for very large applications, you might split this into multiple `createApi` definitions based on resource or service.

Type Safety is Your Friend

If you’re not using TypeScript, seriously consider it. Redux Toolkit works exceptionally well with it. Defining `RootState` and `AppDispatch` types, and using `PayloadAction` in your reducers, catches a huge class of errors at compile time. Even if you’re not using it for your entire app, using it for your Redux logic can be a huge win.

Selectors for Derived Data

Avoid computing derived data directly within your components or even reducers. Use Reselect (which is built into Redux Toolkit) to create memoized selectors. This ensures that expensive calculations are only re-run when the relevant parts of the state change.

Example using `createSelector` (you’ll need to install `reselect` if you’re not using it via RTK’s internal structure, though RTK often provides utilities that wrap it):

// In a selectors.js file for your user feature
import { createSelector } from '@reduxjs/toolkit';
import { RootState } from '../store'; // Assuming store.ts has RootState type
const selectUserState = (state: RootState) => state.user;
export const selectUserName = createSelector(
[selectUserState],
(user) => user.name
);
export const selectIsLoggedIn = createSelector(
[selectUserState],
(user) => user.isLoggedIn
);

Then in your component:

import { useSelector } from 'react-redux';
import { selectUserName, selectIsLoggedIn } from '../features/user/userSelectors';
const UserNameDisplay = () => {
const userName = useSelector(selectUserName);
const isLoggedIn = useSelector(selectIsLoggedIn);
// ... render based on userName and isLoggedIn
};

This keeps your components cleaner and your state logic more efficient.

Handling Forms

For complex forms, consider libraries like Formik or React Hook Form. They integrate well with Redux for managing form state if needed, but often you can manage form state locally within the component or use RTK Query mutations for submission without needing to store the entire form in the Redux store.

Context API vs. Redux Toolkit

It’s a common question: when to use React Context and when to use Redux Toolkit? Generally, use Context for “global” state that rarely changes and is primarily for configuration or theme, or for passing data down the tree without prop drilling for a specific subtree. For application-wide state that changes frequently, involves complex logic, or needs robust debugging and middleware capabilities, Redux Toolkit is usually the better choice.

Common Pitfalls and How to Avoid Them

Even with RTK, you can still run into trouble. Here are some common mistakes:

Mutating State Directly: This is the cardinal sin of Redux. Even though Immer helps, you still need to be mindful. If you’re doing something like `state.items.push(newItem)` without Immer, it’s a direct mutation. While Immer handles it gracefully, understanding *why* it works (by creating a draft and then producing a new immutable state) is crucial. Be explicit when you intend to add, remove, or update items in arrays or objects.
Over-reliance on Redux: Not every piece of state needs to live in Redux. Local component state (`useState`, `useReducer`) or React Context can be more appropriate for component-specific or UI-related state. Putting too much into Redux can make your store bloated and harder to manage.
Complex Reducer Logic: If your reducers start getting very long and complex, it’s a sign that you might need to break down the slice or rethink the state structure.
Forgetting Middleware for Async: If you try to dispatch a function that returns a Promise directly without `redux-thunk` (or RTK Query), it won’t work as expected. `configureStore` includes thunk by default, but it’s good to be aware of it.
Ignoring RTK Query’s Caching: RTK Query is powerful. Make sure you understand how it caches data, how to invalidate it (e.g., after a mutation), and how to leverage its features like polling and optimistic updates. Misunderstanding caching can lead to stale data issues.
Not Typing Your State: (If using TypeScript) Not defining `RootState` correctly or not typing payloads can lead to runtime errors that TypeScript would have caught.

Things That Didn’t Work (Briefly)

Early on, I remember trying to manually manage complex async states (loading, error, success) for API calls within reducers. It involved a lot of duplicated code for setting flags, handling errors, and clearing states. This was a major pain point that RTK Query completely solves. Also, debugging deep immutability issues in plain Redux could be a nightmare; Immer in RTK has made that significantly easier.

When Redux Toolkit Might Be Overkill

Let’s be honest, Redux Toolkit is a powerful tool, and like any powerful tool, it has a learning curve and adds some overhead.

Tiny Apps: For very small applications with minimal shared state, or apps where state is mostly local to components, Redux Toolkit might be overkill. The built-in `useState` and `useContext` might be sufficient.
Simple Data Fetching: If you only have one or two simple API calls that don’t require complex caching or synchronization, `fetch` directly in components with `useState` for loading/error states might be fine.
Team Familiarity: If your team is completely new to Redux and state management concepts, introducing Redux Toolkit *might* be a bigger initial hurdle than simpler solutions. However, given its official status and modern approach, it’s generally the best starting point for new Redux projects.

The key is to assess the complexity and long-term needs of your application. For anything beyond a very simple app, the benefits of Redux Toolkit in terms of maintainability, scalability, and developer experience usually outweigh the initial setup cost.

Conclusion: Embracing Redux Toolkit for Robust Apps

Redux Toolkit has revolutionized how we approach state management in React Native. By reducing boilerplate, enforcing best practices, and providing powerful features like RTK Query, it empowers developers to build more robust, scalable, and maintainable applications.

The transition from “classic” Redux to Redux Toolkit is well worth the effort. The patterns of using slices for feature-based organization, `configureStore` for simplified setup, and RTK Query for efficient data fetching are now considered industry standards for good reason. They lead to cleaner code, fewer bugs, and a more enjoyable development experience.

So, if you’re still on the fence, I highly encourage you to dive in. Start with a small feature, implement a slice, and try out RTK Query for your next API endpoint. You’ll likely find yourself wondering how you ever managed without it. Happy coding!

For more in-depth information, always refer to the official documentation: Modern Redux with Redux Toolkit.

🎥 Video: Full FlutterFlow Tutorial | Part 2

📺 Xem trên YouTube

React Navigation v6: Mastering Mobile App Navigation with Best Practices

Lập Trình

React Native

21 min
2 tháng ago
1
7

Deep dive into React Navigation v6 for experienced developers. Learn essential best practices, common pitfalls, and real-world insights to build robust mobile app navigation with React Native.

Tagged debugging, performance, react-native

Introduction: Navigating the Nuances of React Native Navigation

Alright, fellow React Native developers. Let’s talk about something that’s absolutely fundamental to any mobile app: navigation. Specifically, we’re going to dive deep into React Navigation v6. If you’re past the initial setup and tinkering, you’ve probably already wrestled with how to move users around your app. This isn’t just about chaining screens together; it’s about crafting a user experience that feels intuitive, robust, and, frankly, doesn’t break when you least expect it.

I’ve spent a good chunk of my career building and scaling React Native applications, and navigation has consistently been a source of both elegance and unexpected headaches. The good news is, with React Navigation v6, we have a powerful and mature library at our disposal. But like any tool, understanding its best practices and common gotchas is key to unlocking its full potential. This isn’t your average surface-level tutorial. We’re going to roll up our sleeves, look at real-world scenarios, and discuss why certain patterns work and others, well, might make you want to question your life choices. So, buckle up, and let’s build some solid navigation architecture.

Why React Navigation v6? A Quick Refresher

Before we jump into the nitty-gritty, a quick word on why React Navigation v6 is the go-to. If you’ve been around the React Native block for a while, you might remember older navigation solutions. React Navigation has evolved significantly, and v6 represents a mature, well-tested, and feature-rich library that handles most, if not all, common navigation patterns. It’s built with the React philosophy in mind, leveraging hooks and context effectively. It provides native-like navigation experiences for both iOS and Android, which is crucial for that polished feel users expect. Plus, its extensibility means you’re not locked into a rigid structure.

The Core Stack: Building Your Foundation

Every robust navigation structure starts with a solid foundation. For most apps, this means leveraging the Stack Navigator. It’s your bread and butter for typical hierarchical navigation – think moving from a list to a detail screen, or from a form to a confirmation page.

Let’s set up a basic example. We’ll need to install the necessary packages:

npm install @react-navigation/native @react-navigation/native-stack
# For bare React Native projects
npm install react-native-screens react-native-safe-area-context

Then, in your app’s entry point (e.g., App.js), you’ll typically wrap your app in a NavigationContainer and define your navigator:

// App.js
import * as React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
// Import your screen components
import HomeScreen from './screens/HomeScreen';
import DetailsScreen from './screens/DetailsScreen';
const Stack = createNativeStackNavigator();
function App() {
return (
<NavigationContainer>
<Stack.Navigator initialRouteName="Home">
<Stack.Screen name="Home" component={HomeScreen} options={{ title: 'Welcome' }} />
<Stack.Screen name="Details" component={DetailsScreen} options={{ title: 'Details' }} />
</Stack.Navigator>
</NavigationContainer>
);
}
export default App;

Why this setup?

NavigationContainer: This is the essential component that enables navigation. It manages the navigation tree and state. Everything within it can be navigated.
createNativeStackNavigator: This hook from @react-navigation/native-stack creates a stack navigator that leverages native navigation components for performance. This is usually the preferred choice over the JavaScript-based createStackNavigator for a smoother feel.
<Stack.Screen>: Each screen in your navigator is defined as a Stack.Screen component. The name prop is crucial; it’s how you reference this screen when navigating. The component prop is the actual React component to render for that screen.
options prop: This is where you customize the header for each screen. Titles, buttons, styles – it all goes here.

Best Practice: Keep your navigation setup separate from your core application logic. A dedicated file like Navigation.js or AppNavigator.js is a good idea as your app grows.

Mastering Stack Navigators: Beyond Basic Pushing and Popping

While pushing and popping screens is the primary function, Stack Navigators offer more:

Navigating Programmatically:

From within a screen component, you get access to a navigation prop. You use it to interact with the navigator:

// HomeScreen.js
import React from 'react';
import { View, Button, Text } from 'react-native';
function HomeScreen({ navigation }) {
return (
<View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
<Text>Home Screen</Text>
<Button
title="Go to Details"
onPress={() => navigation.navigate('Details')}
/>
</View>
);
}
export default HomeScreen;

Why navigation.navigate('Details')?

It tells the navigator to find the screen named ‘Details’ and present it.
If ‘Details’ is already in the stack, it will navigate back to that existing instance, bringing it to the front. This is different from pushing a new instance.

Going Back:

// DetailsScreen.js
import React from 'react';
import { View, Button, Text } from 'react-native';
function DetailsScreen({ navigation }) {
return (
<View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
<Text>Details Screen</Text>
<Button title="Go Back" onPress={() => navigation.goBack()} />
<Button
title="Go to Details... again"
onPress={() => navigation.navigate('Details')}
/>
<Button
title="Replace this screen"
onPress={() => navigation.replace('Home')}
/>
</View>
);
}
export default DetailsScreen;

Common Mistake: Overusing navigation.navigate('SomeScreen') when you actually want to push a *new* instance of a screen. If you’re building a multi-step form or a feed where multiple instances of the same screen type are valid, you might need navigation.push('SomeScreen'). This explicitly adds a new screen to the stack, regardless of whether one already exists.

navigation.replace('TargetScreen'): This pops the current screen and replaces it with the target screen. Useful for things like redirecting after login or clearing a flow.

navigation.popToTop(): Pops all screens until you reach the first screen in the stack.

Best Practice: Understand the difference between navigate, push, and replace. Use the most explicit method that achieves your goal to prevent unexpected navigation behavior.

Tab and Drawer Navigators: Enhancing User Experience

While Stack Navigators handle hierarchical flow, Tab and Drawer navigators are for primary navigation or secondary navigation within sections.

Tab Navigators: Great for switching between main sections of your app (e.g., Home, Profile, Settings). You can use createBottomTabNavigator or createMaterialTopTabNavigator.

Drawer Navigators: Typically used for less frequently accessed items or for a more expansive menu (e.g., About, Help, Logout).

You can nest navigators. A common pattern is a Drawer Navigator containing Stack Navigators for each section. This provides top-level navigation via the drawer and then hierarchical navigation within each drawer item.

// Example of nesting a Stack inside a Tab (simplified)
import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
const Tab = createBottomTabNavigator();
const Stack = createNativeStackNavigator();
function HomeStack() {
return (
<Stack.Navigator>
<Stack.Screen name="HomeScreen" component={HomeScreen} />
<Stack.Screen name="Details" component={DetailsScreen} />
</Stack.Navigator>
);
}
function AppNavigator() {
return (
<NavigationContainer>
<Tab.Navigator>
<Tab.Screen name="Home" component={HomeStack} />
<Tab.Screen name="Settings" component={SettingsScreen} />
</Tab.Navigator>
</NavigationContainer>
);
}

Best Practice: Choose the navigator type that best suits the user’s mental model for navigating your app. Don’t force a tab bar where a simple list would suffice, or vice versa.

Passing Data Between Screens: The Right Way

This is a common pain point. You need to send information from Screen A to Screen B. React Navigation provides a few ways:

1. Route Params:

When navigating, you can pass parameters. These are accessible via route.params on the destination screen.

// Navigating from HomeScreen to DetailsScreen with a parameter
navigation.navigate('Details', {
itemId: 86,
otherParam: 'anything you want here',
});

// Accessing params in DetailsScreen
function DetailsScreen({ route, navigation }) {
const { itemId, otherParam } = route.params;
return (
<View>
<Text>Details Screen</Text>
<Text>itemId: {JSON.stringify(itemId)}</Text>
<Text>otherParam: {JSON.stringify(otherParam)}</Text>
{/* ... */}
</View>
);
}

Why this is good: It’s straightforward for passing simple, screen-specific data. It keeps the data directly tied to the navigation event.

Common Mistake: Trying to pass large or complex objects as route params. This can lead to performance issues and make your navigation code harder to manage. If you need to pass a lot of data, consider using a state management solution.

2. State Management (Redux, Zustand, Context API):

For data that needs to be shared across multiple screens or that persists beyond a single navigation event, use a global state management solution. Navigation parameters are generally for data *specific to that navigation event*.

Why this is better for complex data:

Decoupling: Navigation logic remains clean; data fetching and management are separate.
Performance: Avoids re-renders triggered by large object passing through navigation.
Scalability: Easier to manage complex application state.

Best Practice: Use route params for data that defines *which* screen to go to (e.g., an ID) or data that is relevant only for that specific transition. Use a state management solution for shared application data or complex data structures.

Deep Linking: Making Your App Accessible

Deep linking allows users to open specific screens within your app from external sources like web links or notifications. React Navigation v6 has excellent support for this.

Setup:

Configure your app: This involves native configuration on iOS (Info.plist) and Android (AndroidManifest.xml) to register your custom URL scheme (e.g., myapp://).
Handle linking in React Navigation:

// App.js (with linking config)
import * as React from 'react';
import { NavigationContainer } from '@react-navigation/native';
const Stack = createNativeStackNavigator();
const linking = {
prefixes: ['myapp://', 'https://example.com'], // Your custom scheme and domain
config: {
screens: {
Home: '', // 'myapp://'
Details: 'details/:itemId',
Profile: {
path: 'users/:userId/profile',
parse: {
userId: (userId) => userId.toLowerCase(),
},
},
},
},
};
function App() {
return (
<NavigationContainer linking={linking} fallback={<Text>Loading...</Text>}>
<Stack.Navigator>
<Stack.Screen name="Home" component={HomeScreen} />
<Stack.Screen name="Details" component={DetailsScreen} />
<Stack.Screen name="Profile" component={ProfileScreen} />
</Stack.Navigator>
</NavigationContainer>
);
}
export default App;

Why this works: The linking prop tells NavigationContainer how to interpret incoming URLs. The prefixes are the schemes or domains that should trigger your app. The config maps URL paths to your navigator’s screen names and can even parse parameters.

Handling incoming links: When a deep link is triggered, React Navigation will parse it and navigate to the corresponding screen. You can also listen for these events.

For more detailed setup instructions: Check out the official [React Navigation Linking documentation](https://reactnavigation.org/docs/deep-linking/).

Best Practice: Design your URL structure thoughtfully. Make it intuitive and consistent with your app’s hierarchy. Test thoroughly on both platforms.

Handling Modals and Overlays Gracefully

Sometimes, you need a screen that doesn’t behave like a typical stack element – think confirmation dialogs, filter overlays, or full-screen modal views.

React Navigation provides different navigator types for this. The createStackNavigator itself supports modals:

// In your Stack Navigator definition
<Stack.Navigator>
<Stack.Screen name="Home" component={HomeScreen} />
<Stack.Screen
name="MyModal"
component={ModalScreen}
options={{ presentation: 'modal' }}
/>
</Stack.Navigator>

When you navigate to MyModal, it will be presented as a modal (swiping down to dismiss on iOS, typical modal behavior on Android) instead of pushing onto the stack. You navigate to it just like any other screen:

navigation.navigate('MyModal');

Why presentation: 'modal'? This option leverages the native presentation styles for modals, providing a better user experience than trying to simulate a modal with standard stack transitions.

Common Mistake: Trying to build custom modal UI using absolutely positioned views within a regular stack screen. This often leads to inconsistent behavior across platforms and can be a maintenance nightmare. Leverage the built-in modal presentation.

Best Practice: Use presentation: 'modal' for any screen that should appear as a modal overlay. For more complex overlay scenarios (like custom popovers), you might explore libraries or build custom components, but always consider if the built-in options suffice first.

Authentication Flows: A Common Challenge

Managing authentication flows (login, signup, forgot password, logged-in state) is a classic navigation puzzle. You want to ensure users see the right screens based on their auth status.

The Pattern: Conditional Rendering of Navigators

The most robust approach is to have two separate navigator stacks: one for unauthenticated users (Auth Stack) and one for authenticated users (App Stack). You then conditionally render one or the other based on your app’s authentication state.

// AppNavigator.js (simplified)
import React, { useContext } from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
import { AuthContext } from './AuthContext'; // Your context for auth state
import LoginScreen from './screens/LoginScreen';
import SignupScreen from './screens/SignupScreen';
import HomeScreen from './screens/HomeScreen';
import SettingsScreen from './screens/SettingsScreen';
const AuthStack = createNativeStackNavigator();
function AuthNavigator() {
return (
<AuthStack.Navigator screenOptions={{ headerShown: false }}>
<AuthStack.Screen name="Login" component={LoginScreen} />
<AuthStack.Screen name="Signup" component={SignupScreen} />
</AuthStack.Navigator>
);
}
const AppStack = createNativeStackNavigator();
function AppNavigator() {
return (
<AppStack.Navigator>
<AppStack.Screen name="Home" component={HomeScreen} />
<AppStack.Screen name="Settings" component={SettingsScreen} />
</AppStack.Navigator>
);
}
export default function RootNavigator() {
const { user } = useContext(AuthContext);
return (
<NavigationContainer>
{user ? <AppNavigator /> : <AuthNavigator />}
</NavigationContainer>
);
}

Why this is best:

Clear Separation: Auth and app screens are in completely different navigation trees.
Simple Logic: The conditional rendering is dead simple.
Security: Prevents accidental navigation to authenticated-only screens when logged out.

Common Mistake: Trying to show/hide screens within a single navigator based on auth state. This can lead to complex state management within the navigator itself and makes it hard to ensure the user is always in the correct flow. It’s much cleaner to swap out the entire navigator.

Best Practice: Use a global context or state management solution to hold the authentication state. Conditionally render top-level navigators based on this state.

State Management and Navigation: A Delicate Dance

We touched on this with route params, but it bears repeating: navigation state and application state are distinct.

Navigation State: What screen is currently visible? What’s on the stack? What are the current route params?

Application State: User data, fetched lists, form inputs, UI preferences, etc.

React Navigation v6 provides hooks like useIsFocused(), useNavigationState(), and the navigation prop itself to interact with navigation state. Use these for screen-specific logic tied to focus, blur, or navigation actions.

Common Pitfall: Storing complex application data directly in route params or in the navigation state. This couples your app logic too tightly to the navigation structure, making refactoring difficult and potentially causing performance issues.

When to use Global State:

Data that needs to be accessed by many screens.
Data that persists across navigation events and shouldn’t be lost.
Complex data that might be mutated from multiple places.

Best Practice: Keep application state in your chosen state management solution (Redux, Zustand, Context API, etc.). Fetch and update data there. Use navigation parameters only for data that directly influences the navigation action or the specific screen instance.

Performance Considerations: Keeping it Snappy

Navigation can be a performance bottleneck if not handled carefully.

1. Use useNativeDriver for Animations: When creating custom transitions or header animations, always try to use the native driver.

2. Optimize Screen Components: Ensure your screen components themselves are performant. Avoid unnecessary re-renders (React.memo can help). Lazy load components if possible.

3. Avoid Excessive Nesting: Deeply nested navigators can be harder to manage and might introduce overhead. Re-evaluate your navigation structure if it becomes excessively complex.

4. Resetting the Stack: If you have a scenario where you need to clear the stack and go to a specific screen (e.g., after logout), use reset on the navigation object. Be mindful that this can be jarring if not handled with a proper transition.

navigation.reset({
index: 0,
routes: [{ name: 'Home' }],
});

5. Initial Route Name: For performance, ensure your initialRouteName is sensible. If you’re dealing with authentication, the initial route might be determined by your auth state logic.

What didn’t work: In a past project, we had a very complex flow where we were conditionally rendering different screen components within the *same* stack navigator based on user permissions. This became incredibly difficult to debug, led to subtle bugs with state preservation, and was a performance hog. Swapping out the entire navigator for auth flows, and using separate stacks for different user roles, solved this.

Best Practice: Profile your app. Use React DevTools and React Native Debugger to identify performance bottlenecks in your navigation. Prioritize native navigators where possible.

Testing Your Navigation: Don’t Skip This!

Navigation is a core part of your app’s user experience, so testing it thoroughly is non-negotiable.

Unit Testing: While you can unit test individual screen components, testing navigation logic itself in isolation is tricky.

Integration Testing with React Native Testing Library: This is your best bet. You can render your NavigationContainer with mock screens and simulate user interactions to test navigation flows.

// Example (simplified) using React Native Testing Library
import {
render, 
fireEvent,
} from '@testing-library/react-native';
import RootNavigator from '../navigation/RootNavigator'; // Your root navigator
it('navigates to Home screen after login', async () => {
const { getByText, findByText } = render(<RootNavigator />); // Mock AuthContext to return user = true
// Assuming the AppNavigator is rendered when user is true
expect(await findByText('Welcome to Home!')).toBeTruthy(); 
});
it('navigates from Home to Details', async () => {
// Mock AuthContext to return user = true, render AppNavigator
const { getByText } = render(<AppNavigator />); 
fireEvent.press(getByText('Go to Details'));
expect(await findByText('Details Screen')).toBeTruthy();
});

Why this approach? It tests your navigation configuration and how screens transition based on user actions, mimicking real-world usage.

Best Practice: Write integration tests for your critical navigation flows. Ensure that navigating between screens works as expected, parameters are passed correctly, and conditional rendering of navigators (like for auth) functions properly.

Common Pitfalls and How to Avoid Them

Forgetting react-native-screens and react-native-safe-area-context: Essential for performance and layout on native platforms. Always install them.
Directly mutating navigation state: Never try to modify the navigation state directly. Use the provided navigation methods (navigate, push, goBack, reset).
Not handling `navigation.setOptions` correctly: This is used to update header options dynamically. Ensure you’re passing the correct props and that your component is correctly subscribed to these changes.
Over-reliance on global state for navigation params: As mentioned, keep navigation params for navigation-specific data.
Ignoring platform differences: While React Navigation abstracts a lot, subtle differences in behavior (especially with modals and transitions) can occur. Test on both iOS and Android.

What Didn’t Work (and What We Learned)

Early in my React Native journey, I once tried to build a custom tab bar component using absolutely positioned `View`s and managing the active state manually. It seemed like a good idea for ultimate control, but it was a nightmare to maintain, especially when dealing with screen focus events and ensuring native-like performance. It quickly became clear that leveraging the built-in createBottomTabNavigator and customizing its appearance via options was the far more robust and maintainable approach. Lesson learned: don’t reinvent the wheel unless absolutely necessary, and even then, be prepared for the cost.

Conclusion: Your Navigation Superpowers

React Navigation v6 is an incredibly powerful tool for building sophisticated mobile navigation. By understanding the core concepts of stack, tab, and drawer navigators, mastering data passing, implementing deep linking, and handling authentication flows with conditional rendering, you’re well on your way to building highly polished and user-friendly React Native applications.

Remember the key takeaways: keep your navigation structure clean, separate navigation state from application state, leverage native features where possible, and always test your flows. With these best practices in mind, you’ll avoid many common pitfalls and build navigation that is not only functional but also a joy for your users to interact with.

Happy navigating!

🎥 Video: Hướng dẫn sử dụng React Navigation

📺 Xem trên YouTube

React Navigation v6: Mastering Navigation for Robust React Native Apps

Lập Trình

React Native

19 min
2 tháng ago
1
11

Level up your React Native development with this comprehensive guide to React Navigation v6. Discover best practices, common pitfalls, and real-world strategies for building scalable navigation in your apps.

Tagged debugging, performance, react-native

Alright, let’s talk about something that’s fundamental to almost every mobile app out there: navigation. In the React Native world, if you’re building anything beyond a simple splash screen, you’re going to be wrestling with how users move between different parts of your app. And for a long time, and still today for many, React Navigation v6 has been the go-to solution. But mastering it, especially for production-ready apps, involves more than just slapping a few navigators together. It’s about understanding the nuances, avoiding common pitfalls, and adopting patterns that scale.

Introduction: Why Navigation Matters (and Why It’s Hard)

Think about it: a poorly implemented navigation system can make even the most beautifully designed app feel clunky and frustrating. Users expect to move around intuitively, to go back easily, and to know exactly where they are at all times. In React Native, achieving this isn’t always straightforward. You’re dealing with native platform conventions (iOS vs. Android), complex state management, and the ever-present need for performance.

I’ve been there. Early in my React Native journey, I remember cobbling together navigation solutions, only to face a cascade of bugs when trying to pass data, handle deep linking, or simply animate transitions smoothly. The goal of this post is to share the lessons learned from building, debugging, and scaling navigation with React Navigation v6, so you can avoid some of the same headaches.

The Foundation: Understanding React Navigation v6

React Navigation is a community-driven library that provides a navigatable structure for your React Native app. It’s not a single component, but rather a collection of navigators. The latest major version, v6, brought some significant improvements, especially around theming, TypeScript support, and a more robust API. It’s built on the principle of composability, meaning you can nest navigators within each other to create complex navigation flows.

At its core, React Navigation is divided into three main navigator types:

Stack Navigator: Manages screens in a stack, like a browser history. You push new screens onto the stack and pop them off to go back.
Tab Navigator: Manages screens that are accessible from a tab bar (typically at the bottom on iOS, top on Android).
Drawer Navigator: Manages screens accessible from a drawer that slides out from the side of the screen.

The power comes from nesting these. You can have a tab navigator where each tab contains its own stack navigator, for example.

One of the biggest conceptual shifts when moving to v6 (and even v5) was the move towards a more declarative API and the introduction of the NavigationContainer. Everything happens within this container. It manages the overall navigation state and is the root of your app’s navigation tree.


import React from 'react';
import { NavigationContainer } from '@react-navigation/native';
function App() {
return (

{/* Your navigators go here */}

);
}
export default App;

This simple wrapper is crucial. It provides the context necessary for all your navigators and screens to communicate. Without it, nothing works. It’s easy to overlook, but it’s the bedrock of your entire navigation setup.

Stack Navigators: The Workhorse of Mobile Apps

For most mobile apps, the stack navigator is your bread and butter. It’s how you handle typical flows like going from a list of items to a detail view, or from a login screen to the main app. In React Navigation v6, it’s implemented using @react-navigation/stack.

Setting up a basic stack navigator is straightforward:


import * as React from 'react';
import { View, Text, Button } from 'react-native';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
function HomeScreen({ navigation }) {
return (
<View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
<Text>Home Screen</Text>
<Button
title="Go to Details"
onPress={() => navigation.navigate('Details', { itemId: 86, otherParam: 'anything' })}
/>
</View>
);
}
function DetailsScreen({ route, navigation }) {
const { itemId, otherParam } = route.params;
return (
<View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
<Text>Details Screen</Text>
<Text>itemId: {JSON.stringify(itemId)}</Text>
<Text>otherParam: {JSON.stringify(otherParam)}</Text>
<Button title="Go Back" onPress={() => navigation.goBack()} />
<Button
title="Go to Details... again"
onPress={() => {
navigation.navigate('Details', {
itemId: Math.floor(Math.random() * 100),
});
}}
/>
</View>
);
}
const Stack = createNativeStackNavigator();
function App() {
return (
<NavigationContainer>
<Stack.Navigator initialRouteName="Home">
<Stack.Screen name="Home" component={HomeScreen} options={{ title: 'Overview' }} />
<Stack.Screen name="Details" component={DetailsScreen} />
</Stack.Navigator>
</NavigationContainer>
);
}
export default App;

Notice a few things here:

`createNativeStackNavigator`: This is the modern, recommended way to create stack navigators. It leverages native navigation components where possible for a more performant and native-feeling experience.
`navigation.navigate(‘RouteName’)`: This is how you transition to another screen. The first argument is the `name` of the screen you defined in <Stack.Screen />.
`navigation.goBack()`: Navigates back in the stack.
`route.params`: This is how you access parameters passed to the current screen.
Options: The `options` prop on <Stack.Screen /> is super powerful. You can set the screen title, customize headers, add buttons to the header, and much more.

Common Mistakes with Stack Navigators

Over-nesting: While nesting is powerful, creating excessively deep or complex stack structures can lead to performance issues and make debugging a nightmare. Keep your stack structures as flat as possible where it makes sense.
Forgetting `NavigationContainer`: I know I mentioned it earlier, but it’s worth repeating. If your navigators aren’t rendering, this is the first place to check.
Misunderstanding `navigate` vs. `push`: `navigate` will go to the specified route if it exists in the stack, or create it if it doesn’t. `push` always adds a new instance of the screen to the stack, even if it’s already there. For typical list-to-detail flows, `navigate` is usually what you want. For something like a multi-step form where you might want to go back to an earlier step and re-enter data, `push` could be useful, but be mindful of stack depth.
Global header configuration: You can set default options for all screens in a navigator using the `screenOptions` prop on the navigator component itself. This saves a lot of repetition for things like titles, back button styles, etc.

Tab Navigators: Seamlessly Switching Contexts

Tab navigators are essential for apps where users need quick access to distinct sections. Think of a social media app with Home, Search, Notifications, and Profile tabs. React Navigation v6 offers `@react-navigation/bottom-tabs` and `@react-navigation/material-top-tabs`.

The bottom tab navigator is the most common:


import * as React from 'react';
import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';
// Assume HomeScreen and SettingsScreen components are defined
const Tab = createBottomTabNavigator();
function AppTabs() {
return (
<Tab.Navigator>
<Tab.Screen name="Home" component={HomeScreen} />
<Tab.Screen name="Settings" component={SettingsScreen} />
</Tab.Navigator>
);
}

Just like with stack navigators, you can customize the appearance and behavior of your tab bar using `options` on the `Tab.Screen` components or `tabBarOptions` on the `Tab.Navigator`.

Nesting Tab and Stack Navigators: The Real Power

This is where things get really interesting. Most apps will have a structure like this: a main container, a tab navigator, and then within each tab, a stack navigator.


import * as React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';
// Define your screen components (HomeScreen, DetailsScreen, SettingsScreen, ProfileScreen)
const HomeStack = createNativeStackNavigator();
function HomeStackScreen() {
return (
<HomeStack.Navigator>
<HomeStack.Screen name="Home" component={HomeScreen} />
<HomeStack.Screen name="Details" component={DetailsScreen} />
</HomeStack.Navigator>
);
}
const Tab = createBottomTabNavigator();
function MainTabs() {
return (
<Tab.Navigator>
<Tab.Screen name="HomeTab" component={HomeStackScreen} options={{ headerShown: false }}/>
<Tab.Screen name="Settings" component={SettingsScreen} />
<Tab.Screen name="Profile" component={ProfileScreen} />
</Tab.Navigator>
);
}
export default function App() {
return (
<NavigationContainer>
<MainTabs />
</NavigationContainer>
);
}

Key points here:

We define a separate stack navigator (`HomeStackScreen`) for the Home tab.
We render this stack navigator as a component within a `Tab.Screen`.
`options={{ headerShown: false }}` on the `HomeTab` is crucial. You typically don’t want the tab bar’s header to appear when you’re inside a nested stack navigator’s screens (like `DetailsScreen`). The `Stack.Navigator` will manage its own header for its screens.

This pattern is incredibly common and powerful. It allows you to have distinct navigation histories within each tab.

Common Mistakes with Tab Navigators

Header Conflicts: As mentioned, managing headers when nesting is key. If you see duplicate headers or missing headers, check your `headerShown` options at both the tab and stack navigator levels.
State Resetting on Tab Switch: By default, when you switch away from a tab and then back to it, React Navigation often preserves the state of that tab’s navigator. This is usually good, but sometimes you might want to reset the state (e.g., go back to the root screen of that tab). You can achieve this with the `unmountOnBlur` prop on the `Tab.Screen` or by using navigation events to manually reset the stack.
Deep Linking to Tab Screens: Deep linking into a specific screen within a tab’s stack requires careful routing configuration. You’ll need to ensure your navigation state can be correctly reconstructed.

Drawer Navigators: The Classic Side Menu

Drawer navigators provide a slide-out menu, often used for less frequently accessed items or a main navigation menu. They are implemented with @react-navigation/drawer.


import * as React from 'react';
import { createDrawerNavigator } from '@react-navigation/drawer';
// Assume screens are defined
const Drawer = createDrawerNavigator();
function App() {
return (
<NavigationContainer>
<Drawer.Navigator useLegacyImplementation>
<Drawer.Screen name="Home" component={HomeScreen} />
<Drawer.Screen name="Notifications" component={NotificationsScreen} />
</Drawer.Navigator>
</NavigationContainer>
);
}

Note: `useLegacyImplementation` was often required for older versions or specific setups. For new projects, check the latest documentation. In v6, it’s generally recommended to use the default implementation.

Drawers can also be nested, and you can customize their appearance (background, width, etc.) and how they are opened/closed.

Common Mistakes with Drawer Navigators

Accessibility: Ensure your drawer is discoverable and usable. Users should be able to easily open and close it.
Content Overload: Don’t stuff too many options into a drawer. It can become overwhelming. Consider if a tab navigator or a different structure might be more appropriate.
Interaction with other navigators: Drawers can sometimes interfere with gestures or layouts of other navigators, especially if not configured carefully. Always test transitions between different navigator types.

Navigating Programmatically: Beyond Button Clicks

Sometimes, you need to trigger navigation from outside of a direct UI interaction, like after a successful API call, a push notification, or a timer. React Navigation provides ways to do this.

The primary way is by getting access to the `navigation` prop within your screens. However, to navigate from *outside* of a screen component, you need a way to reference the navigation object globally.

The recommended pattern for this in React Navigation v6 is to use a navigationRef:


// NavigationService.js or similar file
import * as React from 'react';
export const navigationRef = React.createRef();
export function navigate(name, params) {
navigationRef.current?.navigate(name, params);
}
// In your App.js or root component:
import { NavigationContainer } from '@react-navigation/native';
import { navigationRef } from './NavigationService';
function App() {
return (
<NavigationContainer ref={navigationRef}>
{/* ... your navigators ... */}
</NavigationContainer>
);
}

Now, from anywhere in your app (where `NavigationService` is imported), you can call `navigate(‘SomeScreen’)`.

Common Mistakes with Programmatic Navigation

Navigation on Unmounted Components: The biggest pitfall is trying to navigate when the `navigationRef.current` is null (i.e., the app is not fully initialized, or the `NavigationContainer` is not rendered). The optional chaining (`?.`) in the `navigate` function is crucial here. Always check if `navigationRef.current` exists before calling methods on it.
Overuse: Relying too heavily on programmatic navigation can lead to tightly coupled code and make it harder to reason about your app’s flow. Try to keep navigation logic within components or screen props where possible.
Deep Linking Logic Errors: When implementing deep linking, you’ll often use this pattern to navigate to specific routes based on incoming URLs. Bugs here can be tricky to track down, often involving incorrect URL parsing or state restoration.

Passing Data Between Screens: The Right Way

This is a classic pain point. How do you send data from Screen A to Screen B? React Navigation makes this pretty clean using `params`.

From Screen A to Screen B: As seen in the `HomeScreen` example, you use `navigation.navigate(‘Details’, { param1: ‘value1’, param2: 123 })`.
Receiving data in Screen B: You access these via `route.params`.
Updating params: You can update parameters for the current screen using `navigation.setParams({ newParam: ‘newValue’ })`. This is useful for things like updating the header title based on screen content.

Common Mistakes with Data Passing

Passing large objects: Avoid passing massive data structures directly as params. This can lead to performance issues, especially with frequent updates or complex state. Instead, consider using a state management solution (like Redux, Zustand, or the Context API) or passing only IDs and fetching the full data on the destination screen.
Mutating params directly: Don’t directly mutate `route.params` in the receiving screen. Use `navigation.setParams` if you need to update them.
Forgetting to handle undefined params: When navigating to a screen that *can* receive parameters, but doesn’t always, ensure you handle the case where `route.params` might be `undefined` or missing specific keys.

Advanced Patterns and Gotchas

Deep Linking

React Navigation has excellent support for deep linking. You configure linking in your `NavigationContainer` to map URLs to your navigation state. This is essential for allowing users to open specific content within your app directly from a URL (e.g., in a web browser or another app).


const linking = {
prefixes: ['https://mychat.com', 'mychat://'],
config: {
screens: {
Home: '',
Profile: 'users/:id',
Chat: {
path: 'chat/:chatId',
// You can also define screens that are part of a nested navigator
screens: {
ChatScreen: '', // The root screen of the Chat navigator
ChatSettings: 'settings',
}
}
}
}
};
// In your App component:
<NavigationContainer linking={linking}>
{/* ... navigators */}
</NavigationContainer>

This requires careful planning of your URL structure and how it maps to your navigation hierarchy. It’s powerful but can be complex to get right, especially with nested navigators.

Authentication Flows

Most apps have an authentication flow (Login -> Main App). React Navigation handles this elegantly using conditional rendering of navigators.


// Assuming isLoggedIn is a state variable or from context
function AppNavigator() {
const { isLoggedIn } = useAuth(); // Your auth hook
return (
<NavigationContainer>
{isLoggedIn ?  : }
</NavigationContainer>
);
}
function AuthStack() {
return (
<Stack.Navigator>
<Stack.Screen name="Login" component={LoginScreen} />
<Stack.Screen name="SignUp" component={SignUpScreen} />
</Stack.Navigator>
);
}
// MainTabs is your previously defined Tab Navigator

This is a common and effective pattern. When the `isLoggedIn` state changes, the navigator rendered inside `NavigationContainer` swaps out, effectively moving the user between authentication and the main app.

Theming

React Navigation v6 has improved theming support, allowing you to define colors, fonts, and other styles that adapt to your app’s theme. You pass a `theme` object to `NavigationContainer`.


import { DefaultTheme, NavigationContainer } from '@react-navigation/native';
const customTheme = {
...DefaultTheme,
colors: {
...DefaultTheme.colors,
primary: 'tomato',
background: 'white',
card: 'white',
text: 'black',
border: 'lightgrey',
},
};
function App() {
return (
<NavigationContainer theme={customTheme}>
{/* ... navigators ... */}
</NavigationContainer>
);
}

This is a cleaner way to manage consistent styling across your navigation components compared to passing style props everywhere.

Performance Considerations

Navigation can be a performance bottleneck if not managed carefully.

Screen Optimizations: Ensure your screen components are optimized. Avoid heavy computations or large data fetches on every render. Use `React.memo` or `useCallback` where appropriate.
Large Lists: If you have large lists on a screen, use `FlatList` or `SectionList` effectively. Their virtualization helps render only visible items.
Navigation State Serialization: When the app goes to the background, React Navigation needs to serialize the current navigation state to save it. Complex navigation trees can make this slower. Keep your navigation structure as flat and clean as possible.
Animation Performance: Native stack navigators use native animations which are generally performant. However, complex custom animations or heavy components within animated screens can still cause jank. Profile your animations if you notice stuttering.
Memory Leaks: Be mindful of event listeners or subscriptions in your screens that aren’t cleaned up when the screen is unmounted. This is a common source of memory leaks and performance degradation over time. The `useEffect` hook’s cleanup function is your best friend here.

Testing Your Navigation

Testing navigation can be tricky. You’re essentially testing how components render and transition based on state changes.

The React Navigation team provides excellent testing utilities within their documentation. A common approach involves:

Mocking the `NavigationContainer` and its behavior.
Using tools like React Native Testing Library to simulate user interactions (button presses, swipes).
Asserting that the correct screens are rendered after interactions.

You can find a good starting point in the official React Navigation testing documentation: https://reactnavigation.org/docs/testing/.

Testing programmatic navigation and deep linking can be more involved, often requiring more sophisticated mocking of the navigation service or the underlying platform APIs.

Conclusion: Building Confident Navigation

Mastering React Navigation v6 is a journey. It’s about understanding the building blocks – Stack, Tab, and Drawer navigators – and how to compose them effectively. More importantly, it’s about anticipating common issues like header management, data passing, and performance bottlenecks.

By adopting best practices like using native stack navigators, keeping your navigation structure clean, managing state thoughtfully, and implementing robust testing, you can build React Native apps with navigation that feels smooth, intuitive, and scales as your application grows. Don’t be afraid to experiment, but always keep the user experience and maintainability of your codebase in mind.

Happy navigating!

🎥 Video: React Navigation Router Setup with Authentication Flow | Drawer Navigation | React Native Typescript

📺 Xem trên YouTube

React Native CLI Setup with TypeScript and Absolute Paths: A Practical Guide

Lập Trình

React Native

19 min
2 tháng ago
1
108

Master React Native CLI setup with TypeScript and absolute paths in 2026. Learn best practices, avoid common pitfalls, and build robust, scalable mobile apps.

Tagged debugging, performance, react-native

React Native CLI Setup with TypeScript and Absolute Paths (2026): Taming Your Project Structure

Lập Trình

React Native

14 min
2 tháng ago
1
4

Master your React Native CLI setup in 2026! Learn to integrate TypeScript and absolute paths efficiently, avoiding common pitfalls for a scalable project structure. Practical advice for mid-senior developers.

Tagged debugging, performance, react-native

Why We’re Still Talking About Project Structure

Alright, let’s be honest. In 2026, we’re still having the same heart-to-hearts about project structure in React Native as we did five years ago. Why? Because as projects grow, the simple ../.. in your import statements starts to feel less like a charming quirk and more like a gnawing irritation. It’s not just about aesthetics; a well-organized project is a joy to work on, easier to debug, and significantly less prone to those mind-bending import errors that suck hours out of your day. This is especially true when you’re dealing with the robustness that TypeScript brings to the table. Today, we’re diving deep into setting up a **React Native CLI setup** that embraces TypeScript and leverages absolute paths for a cleaner, more maintainable codebase. We’ll cover the setup, the common gotchas, and what’s truly worked in real-world scenarios.

The Genesis: A Fresh React Native CLI Project (2026 Edition)

Forget Expo for a moment. When you need that granular control, the React Native CLI is your battleground. Let’s start with the foundation. The command to get a new project going is straightforward:

npx react-native init MyAwesomeApp

This gives you the bare-bones React Native structure. It’s functional, but it’s not opinionated about how you organize your components, services, or utilities. We’ll change that.

Sprinkling in TypeScript: The ‘Why’ and ‘How’

If you’re not already using TypeScript in your React Native projects, you’re leaving a lot of potential on the table. The benefits are massive:

Early Error Detection: Catching type-related bugs during development, not in production.
Improved Readability and Maintainability: Explicit types act as documentation.
Better Tooling: Enhanced autocompletion, refactoring, and code navigation in your IDE.
Robustness for Large Teams: Enforces contracts between different parts of the application.

Adding TypeScript to an existing React Native CLI project is also pretty painless:

cd MyAwesomeApp
npx @react-native-community/cli-init --template typescript

This command installs the necessary TypeScript dependencies and sets up a basic tsconfig.json file. You’ll immediately notice the .tsx extensions and the new tsconfig.json in your project root. Now, our project is ready to embrace type safety.

The Absolute Path Revelation: Bidding Farewell to Relative Hell

This is where the real magic happens for project structure. Imagine this:

// Before absolute paths
import MyComponent from '../../../../components/common/MyComponent';
import apiService from '../../../../services/apiService';

Every time you move a file, you have to meticulously re-check and update all the relative imports that point to it. It’s a recipe for disaster. Absolute paths, on the other hand, treat your project’s source directory as the root.

So, instead, you’d have:

// With absolute paths
import MyComponent from 'components/common/MyComponent';
import apiService from 'services/apiService';

This makes imports:

Shorter and Cleaner: Easier to read.
More Resilient to File Movement: Moving a file within its own directory doesn’t break imports.
More Semantic: Imports clearly state the ‘module’ they’re coming from (e.g., ‘components’, ‘utils’).

Configuring TypeScript (`tsconfig.json`) for Absolute Paths

The first step to enabling absolute paths is configuring tsconfig.json. We need to tell TypeScript where our source code lives so it can resolve these module paths correctly.

Open your tsconfig.json file. You’ll want to modify or add the following properties:

1. `baseUrl`

This tells the TypeScript compiler where to look for non-relative module references. Usually, this will be your src directory.

2. `paths`

This is the core of our absolute path setup. It’s a mapping from module names (or patterns) to locations relative to baseUrl.

Here’s a common configuration:

{
"compilerOptions": {
"target": "esnext",
"module": "commonjs",
"lib": ["es2017", "esnext.asynciterators"],
"allowJs": true,
"jsx": "react-native",
"noEmit": true,
"strict": false,
"experimentalDecorators": true,
"moduleResolution": "node",
"baseUrl": ".",
"paths": {
"@/*": ["src/*"],
"@components/*": ["src/components/*"],
"@utils/*": ["src/utils/*"],
"@services/*": ["src/services/*"],
"@hooks/*": ["src/hooks/*"],
"@assets/*": ["src/assets/*"]
},
"allowSyntheticDefaultImports": true,
"esModuleInterop": true,
"skipLibCheck": true, // This is important for React Native dependencies
"resolveJsonModule": true
},
"exclude": [
"node_modules",
"babel.config.js",
"metro.config.js",
"jest/setup.js",
"*.test.js",
"*.spec.js"
]
}

Explanation:

"baseUrl": ".": This tells TypeScript to resolve modules relative to the project root. We’ll later tell Metro to also use this.
"paths": { ... }: This is where we define our aliases. For example, "@/*": ["src/*"] means any import starting with @/ will be looked for inside the src directory. You can define as many specific aliases as you need (e.g., @components/*, @utils/*). This is a pattern I’ve found incredibly useful.
"skipLibCheck": true: Essential for React Native projects, as many native modules might have declaration files that cause type checking issues.

After this change, you should be able to start using these aliases in your TypeScript files. For example:

import MyButton from '@components/common/MyButton';
import { apiClient } from '@services/apiClient';

Your IDE should now resolve these paths correctly, and TypeScript will understand them. However, there’s a crucial second step.

Taming the Metro Bundler: Aliases for Everything!

This is where many developers get stuck. TypeScript knows about your absolute paths, but the Metro bundler (React Native’s JavaScript bundler) doesn’t. If you try to import using your new aliases without configuring Metro, you’ll get errors like Unable to resolve module '...'. We need to tell Metro about these aliases too.

This is done via the metro.config.js file in your project root.

The `metro.config.js` Dance

The Metro configuration file is where you can customize how Metro bundles your code. We’ll use the resolver.alias option to mirror our TypeScript paths.

Here’s how you’d update your metro.config.js:

const { getDefaultConfig } = require('metro-config');
module.exports = (async () => {
const {
resolver: {
sourceExts,
assetExts,
},
} = await getDefaultConfig();
return {
transformer: {
babelTransformerPath: require.resolve('react-native-svg-transformer'),
getTransformOptions: async () => ({
transform: {
experimentalImportSupport: false,
inlineRequires: true,
},
}),
},
resolver: {
// Add SVGs to assetExts
assetExts: assetExts.filter((ext) => ext !== 'svg'),
// Add the SVG transformer to sourceExts
sourceExts: [...sourceExts.filter((ext) => ext !== 'svg'), 'svg'],
// --- Our Absolute Path Aliases ---
alias: {
'@': require('path').resolve(__dirname, 'src'),
'@components': require('path').resolve(__dirname, 'src/components'),
'@utils': require('path').resolve(__dirname, 'src/utils'),
'@services': require('path').resolve(__dirname, 'src/services'),
'@hooks': require('path').resolve(__dirname, 'src/hooks'),
'@assets': require('path').resolve(__dirname, 'src/assets')
}
},
};
})();

Explanation:

We’re getting the default Metro configuration first.
The key part is the resolver.alias object. It maps your alias (e.g., '@') to the actual file system path. require('path').resolve(__dirname, 'src') resolves to the absolute path of your src directory.
I’ve also included common patterns for handling SVGs with react-native-svg-transformer, which is a frequent requirement in React Native projects.

Important Note: Sometimes, you might need to clear the Metro bundler cache after making changes to metro.config.js. You can do this with:

npx react-native start --reset-cache

Or, more commonly, by deleting the cache folder manually (usually in /tmp/metro-* on Linux/macOS) and then restarting the packager.

Putting it All Together: A Practical Example

Let’s say you have the following project structure:

MyAwesomeApp/
├── src/
│ ├── components/
│ │ └── Button.tsx
│ ├── services/
│ │ └── api.ts
│ └── App.tsx
├── index.js
├── App.tsx (the entry point defined in index.js)
├── tsconfig.json
└── metro.config.js

In your App.tsx (or any other file), you can now import like this:

// src/App.tsx
import React from 'react';
import { View, Text } from 'react-native';
import Button from '@components/Button'; // Absolute path import!
import { fetchData } from '@services/api'; // Absolute path import!
const App = () => {
const [data, setData] = React.useState(null);
React.useEffect(() => {
const getData = async () => {
const result = await fetchData();
setData(result);
};
getData();
}, []);
return (

Welcome to My Awesome App!

And your src/services/api.ts might look like:

// src/services/api.ts
export const fetchData = async () => {
// Replace with your actual API call
return new Promise(resolve => setTimeout(() => resolve({ message: "Hello from API!" }), 1000));
};

This setup provides a clean, organized, and maintainable way to manage your project’s modules.

Common Pitfalls and How We Dodged Them

Even with the best intentions, you can run into trouble. Here are some common issues:

Forgetting to Configure Metro: This is the most frequent mistake. TypeScript sees the paths, but Metro doesn’t. Always remember to update metro.config.js.
Incorrect Path in `metro.config.js`: Double-check that require('path').resolve(__dirname, 'your/src/folder') points to the correct directory where your aliased modules reside. A typo here will cause silent failures or errors.
Cache Issues: Metro is notorious for its caching. If changes don’t seem to be picked up, the first step should be --reset-cache.
Conflicting Aliases: If you have overlapping aliases (e.g., @/* and @src/* both pointing to src), Metro might get confused. Keep your aliases distinct and logical.
Not Using a `src` Directory: While not strictly required for absolute paths, using a src directory is a de facto standard and makes configuring baseUrl and your aliases much cleaner. If you don’t use src, your baseUrl and paths would likely be '.' and ['./components/*'] etc., which is a bit less organized.
IDE Syncing: Sometimes, your IDE (VS Code, WebStorm) might not pick up the `metro.config.js` changes immediately for linting or intellisense. Restarting the IDE or forcing a re-index can help.

What Didn’t Quite Work (or Took Too Long)

Early on, I experimented with trying to make tsconfig.json the single source of truth for paths and hoping Metro would magically pick it up. Spoiler: it doesn’t. The explicit configuration in metro.config.js is non-negotiable. I also spent a bit too much time trying to achieve this without a dedicated `src` folder, which only made the `paths` configuration in `tsconfig.json` more verbose and harder to manage. Embracing the `src` directory alongside absolute paths is a winning combination.

Another approach that seemed promising but often led to complexity was trying to dynamically generate paths from `tsconfig.json` into `metro.config.js`. While possible, it added a layer of indirection that was harder to debug when things went wrong. Keeping them manually aligned, though slightly redundant, proved more robust.

Beyond the Basics: Scaling with Monorepos and Advanced Configs

For larger applications or teams building multiple related packages, you might eventually look into monorepos using tools like Nx or Yarn Workspaces / pnpm Workspaces. In a monorepo setup, your metro.config.js becomes more sophisticated. You’ll need to configure Metro to properly resolve modules across different packages within your monorepo. This often involves:

Using react-native-monorepo-helper or similar tools to inject workspace package locations into Metro’s resolver.
Potentially customizing watchFolders and resolver.nodeModulesPaths in metro.config.js to include your other packages.

While this is beyond the scope of a basic setup, understanding how to configure Metro for absolute paths is a fundamental step towards managing complex monorepo structures.

Actionable Takeaways for Your Next React Native Project

To recap, here’s your checklist for a robust React Native CLI setup with TypeScript and absolute paths:

Initialize your project with TypeScript: Use npx react-native init YourAppName --template typescript (or update an existing one).
Configure tsconfig.json: Set up baseUrl (typically .) and define your paths aliases (e.g., '@/*': ['src/*'], '@components/*': ['src/components/*']). Ensure you have a src directory for better organization.
Configure metro.config.js: Crucially, add your aliases to the resolver.alias property, mapping them to their absolute file system paths (e.g., '@': require('path').resolve(__dirname, 'src')).
Reset Cache When Necessary: If things don’t work, run your start command with --reset-cache.
Organize with a `src` Directory: It simplifies configuration and improves project clarity.
Test Thoroughly: After setup, run your app on both iOS and Android simulators/devices to catch any bundler or import issues.

By investing a little time in this setup early on, you’ll save yourself a mountain of debugging headaches down the line. Happy coding!

🎥 Video: Cài đặt môi trường và tạo dự án bằng React Native CLI

📺 Xem trên YouTube

Phá Kén

Thẻ: react-native

React Native Reanimated 3: Mastering Complex Animations for Production Apps

React Native Reanimated 3: Mastering Smooth Animations

React Query for React Native: Mastering Data Fetching and State Management

React Query for React Native: Mastering Data Fetching Beyond the Basics

Redux Toolkit in React Native: Essential Setup and Real-World Patterns

Redux Toolkit in React Native: Setup and Essential Patterns for Scalability

React Navigation v6: Mastering Mobile App Navigation with Best Practices

React Navigation v6: Mastering Navigation for Robust React Native Apps

React Native CLI Setup with TypeScript and Absolute Paths: A Practical Guide

React Native CLI Setup with TypeScript and Absolute Paths (2026): Taming Your Project Structure