Lưu trữ debugging - Trang 2 trên 7

Dive deep into React Native Gesture Handler with this practical guide for mid-to-senior developers. Learn best practices, common pitfalls, and how to build complex gesture interactions.

Tagged debugging, performance, react-native

Why React Native Gesture Handler is Essential

Alright, let’s talk about something that trips up a lot of folks when they’re building more interactive React Native apps: gestures. You know, those slick, intuitive ways users expect to interact with their phones – swiping, pinching, dragging, rotating. If you’ve ever tried to build anything more than a basic tap, you’ve probably bumped into the limitations of React Native’s built-in `PanResponder` or the general jankiness that comes from trying to manage touch events purely in JavaScript. That’s where React Native Gesture Handler comes in, and frankly, it’s become an indispensable tool in my React Native arsenal. If you’re aiming for polished, native-feeling UIs, understanding this library is non-negotiable.

Why the big fuss? Well, the core problem is that JavaScript runs on a separate thread from the native UI thread. When you’re trying to capture and react to rapid touch events, sending that data back and forth between threads can introduce latency. This leads to dropped frames, stuttering animations, and a generally laggy, un-native feel. React Native Gesture Handler, on the other hand, is built using native code. This means gesture recognition happens directly on the native side, with minimal JavaScript involvement until the gesture is recognized or needs to be communicated. This architecture is a game-changer for performance and responsiveness.

Before Gesture Handler, I remember spending hours trying to wrangle `PanResponder` for something as simple as a draggable item that also needed to scroll horizontally. It felt like I was fighting the framework itself. Gesture Handler simplifies all of this by providing a declarative API that lets you define gesture behaviors and then attach them to your views. It’s more predictable, more performant, and frankly, a lot less painful.

Getting Started: The Basics You Need to Know

Let’s not reinvent the wheel. The official documentation is excellent for the initial setup. If you haven’t already, you’ll need to install it:

npm install react-native-gesture-handler
# or
yarn add react-native-gesture-handler

And for newer React Native versions (0.60+), autolinking should handle most of the native setup. However, if you’re on an older version or having issues, you might need to manually link it. Crucially, for iOS, you need to wrap your app’s entry point with `GestureHandlerRootView`. This is essential for the library to function correctly:

// App.js or index.js
import { GestureHandlerRootView } from 'react-native-gesture-handler';
function App() {
return (

{/* Your app content here */}

);
}
export default App;

Now, let’s look at the fundamental building blocks: the gesture recognizers themselves. The most common ones you’ll use are:

`TapGestureHandler`: For single taps, double taps, or taps with specific finger counts.
`PanGestureHandler: For dragging or sliding gestures. This is the workhorse for many UI interactions.
`PinchGestureHandler: For pinch-to-zoom.
`RotationGestureHandler: For rotating elements.
`LongPressGestureHandler: For holding down on an element.

You’ll typically use these by importing them and then wrapping the view you want to attach the gesture to. For example, a simple draggable square:

import React from 'react';
import { View, StyleSheet } from 'react-native';
import { PanGestureHandler } from 'react-native-gesture-handler';
const DraggableBox = () => {
const onPanEvent = (event) => {
// Here you'd typically update state to move the box
console.log('Dragging:', event.nativeEvent.translationX, event.nativeEvent.translationY);
};
return (

<View style={styles.box}>
{/* Content inside the draggable box */}
</View>

);
};
const styles = StyleSheet.create({
box: {
width: 100,
height: 100,
backgroundColor: 'tomato',
position: 'absolute',
top: 50,
left: 50,
},
});
export default DraggableBox;

The `onGestureEvent` prop is where the magic happens. It receives an event object with details about the gesture’s state. For `PanGestureHandler`, key properties include `translationX`, `translationY`, `velocityX`, and `velocityY`. These are cumulative values based on the gesture’s start. You’ll often use these to update your component’s position, usually via `Animated` values or state management.

Building Complex Gestures: Beyond Simple Swipes

This is where the real power of React Native Gesture Handler shines. Most apps aren’t just one simple gesture. They’re often a combination, or gestures that have specific conditions.

Consider a common UI pattern: a swipe-to-reveal action on a list item. You want to swipe left to reveal action buttons, but you *don’t* want the scrollable list to start scrolling if the user is trying to swipe the item. This is a classic example of gesture conflict.

Gesture Handler’s strength here is its declarative configuration and its ability to define dependencies and behaviors between different gesture handlers. You can use the `simultaneousHandlers` and `exclusiveHandlers` props to control how multiple gesture handlers interact. For our swipe-to-reveal scenario, we’d have a `PanGestureHandler` on the list item and the `ScrollView`’s native pan handler.

You’d typically want the list item’s `PanGestureHandler` to be simultaneous with the `ScrollView`’s scroll gesture initially. However, if the user starts to drag the item horizontally (indicating a desire to reveal actions), you want that gesture to become exclusive, preventing the scroll view from interfering. Conversely, if the user drags vertically, the `ScrollView` should take over exclusively.

Here’s a simplified conceptual example. In a real app, you’d manage the item’s translation using `Animated` values tied to the `PanGestureHandler`’s `onGestureEvent` and `onHandlerStateChange`.

import React, { useRef } from 'react';
import {
View,
StyleSheet,
Text,
Animated,
ScrollView,
} from 'react-native';
import {
PanGestureHandler,
State,
ScrollView as GestureHandlerScrollView,
} from 'react-native-gesture-handler';
const ITEM_WIDTH = 200;
const SWIPE_THRESHOLD = 50;
const SwipeableListItem = ({ item }) => {
const translateX = useRef(new Animated.Value(0)).current;
const swipeState = useRef(State.UNDETERMINED).current;
const menuOpened = useRef(false).current;
const onSwipeGestureEvent = Animated.event([
{ nativeEvent: { translationX: translateX } },
], {
useNativeDriver: true,
});
const onSwipeStateChange = (event) => {
if (event.nativeEvent.oldState === State.ACTIVE) {
const { translationX } = event.nativeEvent;
swipeState.setValue(event.nativeEvent.state);
if (menuOpened && translationX < -SWIPE_THRESHOLD) {
// Close menu
Animated.timing(translateX, {
toValue: 0,
duration: 300,
useNativeDriver: true,
}).start();
menuOpened.current = false;
} else if (!menuOpened && translationX > SWIPE_THRESHOLD) {
// Open menu
Animated.timing(translateX, {
toValue: -ITEM_WIDTH,
duration: 300,
useNativeDriver: true,
}).start();
menuOpened.current = true;
} else {
// Snap back to current position
Animated.timing(translateX, {
toValue: menuOpened.current ? -ITEM_WIDTH : 0,
duration: 300,
useNativeDriver: true,
}).start();
}
}
swipeState.setValue(event.nativeEvent.state);
};
return (
<>
<View style={styles.menuBackground}>
<Text style={styles.menuButton}>Delete</Text>
</View>
<PanGestureHandler
onGestureEvent={onSwipeGestureEvent}
onHandlerStateChange={onSwipeStateChange}
activeOffsetX={[-10, 10]} // Start swipe only on horizontal movement
failOffsetY={[-5, 5]} // Fail if vertical movement is too significant
minDeltaX={SWIPE_THRESHOLD}
>
<Animated.View
style={[
styles.row,
{
transform: [{ translateX }],
},
]}
>
<View style={styles.contentContainer}>
<Text>{item.name}</Text>
</View>
</Animated.View>
</PanGestureHandler>
</
);
};
const App = () => {
const data = [{ id: 1, name: 'Item 1' }, { id: 2, name: 'Item 2' }];
// Note: In a real scenario, you'd need to properly manage
// simultaneous and exclusive handlers between the ScrollView
// and the list items for true conflict resolution.
// This example focuses on the item's swipe logic.
return (
<GestureHandlerRootView style={{ flex: 1 }}>
<ScrollView contentContainerStyle={styles.container}>
{data.map(item => (
<SwipeableListItem key={item.id} item={item} />
))}
</ScrollView>
</GestureHandlerRootView>
);
};
const styles = StyleSheet.create({
container: {
paddingTop: 50,
},
row: {
flexDirection: 'row',
backgroundColor: '#fff',
padding: 20,
borderBottomWidth: 1,
borderBottomColor: '#eee',
},
contentContainer: {
width: ITEM_WIDTH,
justifyContent: 'center',
},
menuBackground: {
position: 'absolute',
right: 0,
height: '100%',
width: ITEM_WIDTH,
backgroundColor: 'red',
justifyContent: 'center',
alignItems: 'center',
},
menuButton: {
color: 'white',
fontWeight: 'bold',
},
});
export default App;

The key here is understanding the `State` enum (`State.UNDETERMINED`, `State.BEGAN`, `State.ACTIVE`, `State.END`, `State.CANCELLED`, `State.FAILED`). You often use the `onHandlerStateChange` to know when a gesture has started, is in progress, or has ended, which is crucial for triggering animations or state updates.

Handling Conflicts and Interdependencies

This is where things can get tricky, but also very powerful. Imagine a map where you can pinch to zoom, but also pan around. Or a complex custom control with multiple interactive elements. Gesture Handler provides two primary props for managing these relationships:

`simultaneousHandlers`: Allows multiple gesture handlers to recognize simultaneously. This is useful when you want different gestures to be active at the same time. For instance, a `PinchGestureHandler` and a `PanGestureHandler` on the same view might both need to fire if the user is doing a complex two-finger drag-and-pinch.
`exclusiveHandlers: Ensures that only one gesture handler can be active at a time. If a gesture recognized by an `exclusiveHandler` starts, other handlers registered with it will be cancelled. This is perfect for the swipe-to-reveal list item scenario we touched on earlier, or for scenarios where you want a specific gesture to take precedence over others.

The typical pattern for a scrollable view with interactive items is to make the item’s `PanGestureHandler` simultaneous with the `ScrollView`’s internal gesture handling when the item is at its default position. However, as soon as the user starts dragging the item horizontally beyond a certain threshold, you want that item’s `PanGestureHandler` to become exclusive, canceling any scrolling motion from the `ScrollView`. You achieve this by passing references to the handlers using `useRef`.

// In your parent scrollable component:
const scrollViewRef = useRef(null);
const itemGestureRef = useRef(null);
// ... in the Item component render:


{/* ... item content ... */}


// ... in the ScrollView component render:

{/* ... list items ... */}

You’ll then need logic within the `onHandlerStateChange` of the item’s `PanGestureHandler` to conditionally set the `exclusive` flag or to manage the `simultaneousHandlers` prop dynamically if the gesture starts moving in a way that should prevent others. This can get complex, and often involves a central state management or a dedicated component to orchestrate these interactions. The key is to carefully define the rules of engagement for your gestures.

Integrating with Animations: Making it Smooth

Gesture Handler is designed to work seamlessly with React Native’s `Animated` API. This is critical for performance. Instead of updating JavaScript state on every frame of a gesture, you can drive `Animated` values directly from the native gesture events.

The `Animated.event` utility is your best friend here. It allows you to map native event properties directly to `Animated` values. As mentioned in the drag example, this means the `translateX` value in our `DraggableBox` can be updated by the gesture event without the event ever needing to fully cross the bridge to JavaScript until the gesture ends or its state changes significantly.

const translateX = useRef(new Animated.Value(0)).current;
const onPanEvent = Animated.event([
{ nativeEvent: { translationX: translateX } },
], {
useNativeDriver: true, // !!! Important for performance !!!
});
// ... in the JSX:

<Animated.View style={{ transform: [{ translateX }] }}>
{/* content */}
</Animated.View>

When the gesture ends (`event.nativeEvent.state === State.END` in `onHandlerStateChange`), you can then use the final `translationX` and `velocityX` to trigger animations that snap the element to a new position, or to initiate other actions. This combination of native gesture recognition and native driver animations is what gives React Native apps their smooth, fluid feel.

One common mistake is forgetting to set `useNativeDriver: true` in `Animated.event`. If you don’t, animations will be processed on the JS thread, negating much of the performance benefit. Also, be mindful of what properties you animate. `transform` properties (`translateX`, `scale`, `rotate`) and `opacity` are generally well-supported by the native driver. Other properties might not be, leading to JS-driven animations.

For more advanced scenarios, like physics-based animations or complex sequences, you might look into libraries like Reanimated 2 (or 3), which offer an even more powerful and declarative way to handle animations and gestures, often by defining shared values and worklets that run directly on the UI thread.

Performance Considerations for Production Apps

We’ve touched on this, but it bears repeating: performance is king. When using React Native Gesture Handler, especially in list views or complex interactive screens, keep these in mind:

`useNativeDriver: true`: I cannot stress this enough. Always use the native driver for animations driven by gestures.
Minimize JS Updates During Gesture: Only update JavaScript state when absolutely necessary. Let `Animated.event` do the heavy lifting for driving UI properties. Use `onHandlerStateChange` to react to gesture completion, not `onGestureEvent` for state updates.
Avoid Deeply Nested Handlers: While Gesture Handler is performant, excessively deep nesting of handlers can still add overhead. Keep your gesture setup as flat and logical as possible.
Optimize Re-renders: If your gesture logic triggers re-renders, ensure those re-renders are efficient. Use `React.memo` or `useCallback` where appropriate, especially if your gesture handler component is re-rendering frequently.
`react-native-reanimated` Integration: For truly demanding applications, consider integrating with `react-native-reanimated`. Reanimated v2 and later provide an even more powerful UI-thread-centric approach. Gesture Handler works beautifully with Reanimated, allowing you to define gesture-driven animations and logic that run entirely on the UI thread, offering unparalleled performance. This is often the go-to for complex drag-and-drop interfaces, fluid transitions, and highly interactive custom components.
Throttling and Debouncing (Use Sparingly): While Gesture Handler is inherently performant, if you *do* find yourself needing to update JS state frequently based on gesture events, consider throttling or debouncing those updates. However, this should be a last resort after optimizing with `Animated.event` and the native driver.

I once worked on an app with a highly interactive dashboard where users could drag and reorder numerous widgets. Initially, we tried to manage everything with JS state updates on drag. It was unusable. By switching to Gesture Handler with `Animated.event` and `useNativeDriver`, and later integrating Reanimated for more complex interactions, we turned a laggy mess into a super-smooth experience. The key was offloading as much work as possible to the native thread.

Common Pitfalls and How to Avoid Them

Even with a great library, you can still stumble. Here are some common gotchas:

Forgetting `GestureHandlerRootView`: This is the #1 culprit for “why isn’t Gesture Handler working?” errors. Make sure it wraps your entire app or at least the root of your navigation.
Incorrect `simultaneousHandlers` / `exclusiveHandlers` Setup: This leads to gestures not triggering, or worse, interfering with each other in unexpected ways. Always trace the intended flow of your gestures. Think about which handler should win in different scenarios.
Not Using `useNativeDriver` for Animations: Again, this is a massive performance killer. If your animations aren’t smooth, this is the first thing to check.
Confusing `translationX` with absolute position: `translationX` and `translationY` are cumulative deltas from the start of the gesture. You usually need to combine this with the element’s initial position (or an `Animated.Value` that tracks its position) to get the current absolute position.
Ignoring `onHandlerStateChange`: Many developers focus only on `onGestureEvent`. However, `onHandlerStateChange` is crucial for knowing when a gesture has begun, ended, or been cancelled, which is often when you need to finalize animations or reset states.
State Updates on Every `onGestureEvent` Frame: This is a performance killer. Let `Animated.event` manage the UI updates during the gesture itself.
Overlapping Gesture Handlers Without Clear Rules: If you have multiple handlers on the same element or nested elements, and they can potentially recognize the same gesture, you *must* define their relationships using `simultaneousHandlers` and `exclusiveHandlers` to avoid unpredictable behavior.
`PanResponder` Conflicts: If you’re migrating from or mixing with `PanResponder`, you’ll likely run into issues. Gesture Handler is designed to replace `PanResponder` for most complex gesture needs.

I once spent half a day debugging a weird flickering animation. It turned out I was accidentally calling a state update on every `onGestureEvent` frame *and* trying to animate the same property with `Animated.event`. The two were fighting, causing the flicker. Once I removed the state update from `onGestureEvent` and relied solely on `Animated.event` for driving the transform during the gesture, it was fixed.

Lessons Learned: What Didn’t Work (and Why)

When I first started with React Native Gesture Handler, I tried to treat it like a more powerful `PanResponder`. I’d implement a lot of the state management and gesture completion logic directly in JavaScript, on every `onGestureEvent` tick. This was a mistake. The library is built to delegate gesture recognition to the native side. Trying to pull all the data into JS on every frame kills performance. The correct approach is to:

Use `Animated.event` with `useNativeDriver: true` to directly map gesture event properties (like `translationX`) to `Animated.Value`s that drive your UI elements.
Use `onHandlerStateChange` to detect the end of a gesture (or significant state changes) and then perform any necessary JavaScript-side logic (e.g., updating app state, triggering navigation, finalizing animations).

Another thing I learned the hard way: over-complicating gesture dependencies. Sometimes, you can get lost in the `simultaneousHandlers` and `exclusiveHandlers` tree. My initial instinct was to wire up *everything*. Instead, focus on the immediate conflicts. For a common list scenario, you only need to define the relationship between the item’s gesture handler and the parent scrollable view’s gesture handler. If you have nested gesture handlers within an item, you’ll need to define those relationships too, but it’s best to tackle them one level at a time.

Finally, for anything that feels like it’s pushing the boundaries of performance or requires truly complex, multi-stage animations tied to gestures, don’t shy away from `react-native-reanimated`. It’s not always necessary, but when it is, it’s the right tool. Trying to force Reanimated-level complexity into just Gesture Handler (without Reanimated) often leads to a lot of boilerplate and less-than-ideal performance.

Advanced Techniques and Further Exploration

Once you’re comfortable with the basics, there’s a lot more you can do:

Custom Gesture Combinations: You can compose existing gesture handlers to create entirely new ones. For example, requiring a swipe *after* a long press.
Gesture Trails/Paths: Drawing a line behind a draggable element as it moves.
Complex Drag-and-Drop: Building intuitive drag-and-drop interfaces for reordering items in lists or grids.
Integration with Navigation Libraries: Creating custom screen transitions or modal presentations driven by gestures.
Using Libraries like `react-native-gesture-handler-scroll`: These libraries build on top of Gesture Handler to provide more advanced scrollable components with built-in swipe-to-reveal or drag-and-drop capabilities.

For a deep dive into advanced patterns and best practices, especially concerning performance and integration with `react-native-reanimated`, the official Reanimated documentation is a fantastic resource. It often showcases how to leverage Gesture Handler in conjunction with Reanimated’s UI-thread worklets for incredibly powerful and performant interactions:

https://docs.swmansion.com/react-native-reanimated/

Exploring open-source projects that use Gesture Handler extensively can also be incredibly insightful. Look at popular UI libraries or complex apps on GitHub to see how experienced developers tackle challenging gesture interactions.

Conclusion: Mastering React Native Gestures

React Native Gesture Handler is more than just a library; it’s a fundamental piece of tooling for building truly interactive and performant mobile applications. By moving gesture recognition to the native side and integrating tightly with the `Animated` API (and `react-native-reanimated`), it solves many of the performance bottlenecks that plague touch-based interactions in cross-platform development.

Mastering it involves understanding not just the basic gesture types, but also how to manage their interdependencies, leverage native-driven animations, and optimize for production. While there’s a learning curve, especially around gesture conflicts and advanced animations, the payoff in terms of user experience is immense. So, embrace the native power, keep an eye on performance, and start building those smooth, intuitive interactions your users will love.

React Native Form Handling: Mastering Forms with Formik and Yup

Lập Trình

React Native

22 min
2 tuần ago
1
11

Unlock efficient React Native form handling with Formik and Yup. Dive into real-world patterns, debugging tips, and best practices for building robust forms.

Tagged debugging, performance, react-native

Alright, let’s talk about something that, if you’ve been doing any serious React Native development, you’ve probably wrestled with: form handling. It sounds simple, right? You’ve got some input fields, a submit button, and maybe a bit of validation. Easy peasy. But anyone who’s built even a moderately complex form in React Native knows it can quickly turn into a tangled mess of state updates, input props, and error messages scattered like digital confetti.

This isn’t just about making things look pretty; it’s about user experience. Clunky, error-prone forms lead to frustrated users, abandoned sign-ups, and support tickets. As developers, we want to build robust, intuitive forms that just *work*. So, when you’re deep in the trenches of React Native form handling, you’re looking for tools that simplify the process, enforce good practices, and save you from reinventing the wheel. That’s where Formik and Yup come in. I’ve spent a significant chunk of my career building and scaling React Native apps, and I can tell you, these two libraries have been absolute game-changers for form development. Let’s dive into why and how.

Introduction: Why Form Handling is a Big Deal in Mobile Apps

Think about it: what are mobile apps often used for? Filling out information. Registration forms, login screens, checkout processes, feedback forms, profile updates – the list is endless. A poorly implemented form is like a locked door to your app’s functionality. Users expect forms to be straightforward, forgiving of minor mistakes, and clear about what went wrong if they do mess up. This means handling user input reliably, validating that input against business rules, and providing helpful feedback. Without a solid strategy, you’re in for a world of pain.

The Default Approach: Why It Quickly Becomes a Headache

Let’s say you decide to go vanilla React Native. You’d likely use your component’s local state to manage each input’s value. For a simple text input, it might look something like this:

import React, { useState } from 'react'; import { View, TextInput, Text, Button } from 'react-native'; function SimpleForm() { const [name, setName] = useState(''); const [email, setEmail] = useState(''); const [errors, setErrors] = useState({}); const validateForm = () => { const formErrors = {}; if (!name) formErrors.name = 'Name is required'; if (!email) formErrors.email = 'Email is required'; // More complex validation... setErrors(formErrors); return Object.keys(formErrors).length === 0; }; const handleSubmit = () => { if (validateForm()) { // Submit form logic console.log('Form submitted:', { name, email }); } }; return (   {errors.name && <Text style={{ color: 'red' }}>{errors.name}</Text>}  {errors.email && <Text style={{ color: 'red' }}>{errors.email}</Text>}

This works for a form with two fields. But what happens when you add more fields? A password, confirm password, address, phone number, checkboxes, radio buttons, select dropdowns? Your component state balloons. The onChangeText handlers multiply. The validation logic becomes a monstrous function that’s hard to read, hard to maintain, and even harder to test. You end up managing dozens of state variables, each with its own setter, and a giant validation function that’s tightly coupled to your component’s UI. Debugging becomes a nightmare of tracing state changes and finding typos in prop names. This is where you start thinking, “There has to be a better way.”

Introducing Formik: Your New Best Friend for React Native Forms

Formik is a library that helps you manage forms in React (and React Native) with significantly less boilerplate. It handles form state, input values, submission, and validation lifecycle for you, abstracting away a lot of the manual work. The core idea is that Formik provides a component or a hook that wraps your form and gives you access to essential props and functions to control the form’s behavior.

When I first encountered Formik, it felt like a breath of fresh air. It’s designed with developer experience in mind, and its philosophy aligns well with React’s declarative nature.

Basic Formik Setup: Getting Started

Let’s refactor the previous example using Formik. You’ll need to install it:

npm install formik # or yarn add formik

Formik offers a couple of ways to use it: a component-based API and a hook-based API (useFormik). The hook is generally preferred for functional components as it’s more concise.

Here’s how that same simple form looks with useFormik:

import React from 'react'; import { View, TextInput, Text, Button } from 'react-native'; import { useFormik } from 'formik'; function FormikSimpleForm() { const formik = useFormik({ initialValues: { name: '', email: ''}, onSubmit: (values) => { console.log('Form submitted:', values); // Submit form logic here }, // Validation will go here soon! }); return ( <View> <TextInput placeholder="Name" onChangeText={formik.handleChange('name')} onBlur={formik.handleBlur('name')} value={formik.values.name} /> {formik.touched.name && formik.errors.name && ( <Text style={{ color: 'red' }}>{formik.errors.name}</Text> )} <TextInput placeholder="Email" onChangeText={formik.handleChange('email')} onBlur={formik.handleBlur('email')} value={formik.values.email} keyboardType="email-address" /> {formik.touched.email && formik.errors.email && ( <Text style={{ color: 'red' }}>{formik.errors.email}</Text> )} <Button title="Submit" onPress={formik.handleSubmit} /> </View> ); } export default FormikSimpleForm;

Notice the immediate improvements:

initialValues: We define the initial state of our form fields in one place.
handleChange: This is a magic function that automatically updates the correct form field in Formik’s state. You just pass the field name.
handleBlur: Formik tracks when a field has been “touched” (blurred), which is crucial for displaying errors only after the user has interacted with a field.
values: All form values are accessible under formik.values.
handleSubmit: This function is called when the button with onPress={formik.handleSubmit} is pressed. It automatically handles preventing default form submission (if this were a web form) and calls your onSubmit handler with the current form values.

This is already much cleaner. We’ve reduced the number of state variables and handlers significantly. The form state and logic are centralized within the useFormik hook.

Handling State and Input Changes: The Formik Way

Formik’s handleChange is a lifesaver. Instead of writing onChangeText={value => setName(value)} for every input, you just do onChangeText={formik.handleChange('fieldName')}. Formik figures out which field you’re updating. Similarly, onBlur={formik.handleBlur('fieldName')} takes care of tracking which fields have been focused and then unfocused.

This pattern keeps your component code lean. All the intricate state management is delegated to Formik. You still access the current values via formik.values.fieldName, and you trigger updates via formik.handleChange('fieldName').

Integrating Yup: Bringing Powerful Validation to Your Forms

So, we have form state management sorted. Now, let’s talk about validation. This is where the real magic happens when you pair Formik with Yup. Yup is a JavaScript schema builder for value parsing and validation. It lets you define the shape of your data and then validate against that shape.

First, install Yup:

npm install yup # or yarn add yup

Now, let’s create a Yup schema for our form. Typically, you’d do this outside your component or at the top level:

import * as yup from 'yup'; const validationSchema = yup.object().shape({ name: yup.string().required('Name is required'), email: yup.string().email('Invalid email format').required('Email is required')});

This schema is incredibly expressive. We’re saying our form should have a name which must be a string and is required. The email must also be a string, have a valid email format, and be required.

Now, let’s integrate this into our Formik setup:

import React from 'react'; import { View, TextInput, Text, Button } from 'react-native'; import { useFormik } from 'formik'; import * as yup from 'yup'; // Import Yup // Define validation schema const validationSchema = yup.object().shape({ name: yup.string().required('Name is required'), email: yup.string().email('Invalid email format').required('Email is required')}); function FormikYupForm() { const formik = useFormik({ initialValues: { name: '', email: ''}, validationSchema: validationSchema, // Assign the schema here onSubmit: (values) => { console.log('Form submitted:', values); // Submit form logic here }}); return ( <View> <TextInput placeholder="Name" onChangeText={formik.handleChange('name')} onBlur={formik.handleBlur('name')} value={formik.values.name} /> {formik.touched.name && formik.errors.name && ( <Text style={{ color: 'red' }}>{formik.errors.name}</Text> )} <TextInput placeholder="Email" onChangeText={formik.handleChange('email')} onBlur={formik.handleBlur('email')} value={formik.values.email} keyboardType="email-address" /> {formik.touched.email && formik.errors.email && ( <Text style={{ color: 'red' }}>{formik.errors.email}</Text> )} <Button title="Submit" onPress={formik.handleSubmit} disabled={formik.isSubmitting} /> </View> ); } export default FormikYupForm;

See what happened? We simply passed our validationSchema to Formik. Now, Formik automatically validates the form whenever the values change (or on blur, depending on configuration). The validation errors are accessible via formik.errors, and we can check if a field has been touched using formik.touched. This combination is incredibly powerful. It separates your validation logic from your UI and business logic, making your code much more maintainable.

A common mistake is forgetting to add onBlur={formik.handleBlur('fieldName')}. If you only rely on onChangeText for validation, errors might appear as the user types, which can be annoying. Using onBlur ensures errors are only shown after the user has finished interacting with a field, giving them a chance to correct themselves without constant red text.

Common Yup Validation Scenarios and How to Implement Them

Yup has a rich API for defining validation rules. Here are some common ones you’ll encounter:

Required fields: yup.string().required('This field is mandatory')
Minimum/Maximum length: yup.string().min(5, 'Too short').max(20, 'Too long')
Specific formats: yup.string().url('Invalid URL'), yup.string().matches(/^[0-9]+$/, 'Must be a number')
Numbers: yup.number().min(1, 'Must be at least 1').required('Quantity is required')
Dates: yup.date().nullable().max(new Date(), 'Cannot be in the future')
Booleans: yup.boolean().oneOf([true], 'Must accept terms')
Enums (specific values): yup.string().oneOf(['apple', 'banana'], 'Invalid fruit')

Custom Validation

Sometimes, you need more complex validation that Yup doesn’t directly support. You can use the test method:

const passwordValidation = yup.string() .min(8, 'Password is too short') .test('has-special-char', 'Password must contain at least one special character', (value) => { return /[!@#$%^&*()_+\-=\[\]{};':"\\|,.<>\/?]+/.test(value); });

This adds a custom test to ensure the password contains at least one special character.

Validating Form Submission

Formik’s onSubmit handler is perfect for the final submission. However, you might want to disable the submit button while the form is being validated or submitted to prevent double submissions. Formik provides formik.isSubmitting for this:

<Button title="Submit" onPress={formik.handleSubmit} disabled={formik.isSubmitting} // Disable button while submitting />

By default, isSubmitting becomes true when handleSubmit is called and false when the onSubmit callback finishes or if an error occurs during validation. You can also manually control this by setting `formik.setSubmitting(true/false)` within your onSubmit function if you have asynchronous operations (like API calls) that don’t directly tie into Formik’s lifecycle.

Advanced Formik Techniques: Beyond the Basics

Once you’re comfortable with the basics, Formik and Yup offer a lot more flexibility for tackling complex forms.

Conditional Rendering and Dynamic Forms

You’ll often have fields that only appear based on the value of another field. For example, if a user selects “Other” as a payment method, you might show a custom payment input. Yup handles conditional validation beautifully with its when function:

const validationSchema = yup.object().shape({ paymentMethod: yup.string().required('Select a payment method'), creditCardNumber: yup.string().when('paymentMethod', { is: 'credit_card', // Only validate if paymentMethod is 'credit_card' then: yup.string().required('Credit card number is required').min(16, 'Invalid card number'), otherwise: yup.string(), // No validation if not credit card }), // ... other fields });

This means the creditCardNumber field is only required and validated if the user picks ‘credit_card’ as their payment method. This keeps your validation logic clean and tied directly to the schema.

Handling Arrays and Nested Objects

Forms with lists of items (e.g., adding multiple phone numbers, multiple items in a cart) or deeply nested structures are common. Formik excels here.

Consider a form where a user can add multiple skills:

import React from 'react'; import { View, TextInput, Text, Button, FlatList, TouchableOpacity } from 'react-native'; import { useFormik } from 'formik'; import * as yup from 'yup'; // Schema for a single skill const skillSchema = yup.object().shape({ name: yup.string().required('Skill name is required')}); // Schema for the whole form, including an array of skills const validationSchema = yup.object().shape({ skills: yup.array().of(skillSchema).min(1, 'Please add at least one skill')}); function DynamicArrayForm() { const formik = useFormik({ initialValues: { skills: [{ name: '' }], // Start with one empty skill }, validationSchema: validationSchema, onSubmit: (values) => { console.log('Form submitted:', values); }}); const addSkill = () => { formik.setValues({ ...formik.values, skills: [...formik.values.skills, { name: '' }]}); }; const removeSkill = (index) => { const newSkills = formik.values.skills.filter((_, i) => i !== index); formik.setValues({ ...formik.values, skills: newSkills }); }; const renderSkill = ({ item, index }) => ( <View style={{ flexDirection: 'row', alignItems: 'center', marginBottom: 10 }}> <TextInput placeholder={`Skill ${index + 1} Name`} onChangeText={formik.handleChange(`skills[${index}].name`)} // Notice the array notation! onBlur={formik.handleBlur(`skills[${index}].name`)} value={formik.values.skills[index].name} style={{ flex: 1, marginRight: 10 }} /> {formik.values.skills.length > 1 && ( <TouchableOpacity onPress={() => removeSkill(index)}> <Text style={{ color: 'red' }}>Remove</Text> </TouchableOpacity> )} {formik.touched.skills && formik.errors.skills && formik.errors.skills[index] && ( <Text style={{ color: 'red', marginLeft: 10 }}>{formik.errors.skills[index].name}</Text> )} </View> ); return ( <View> <FlatList data={formik.values.skills} renderItem={renderSkill} keyExtractor={(item, index) => index.toString()} /> <Button title="Add Skill" onPress={addSkill} /> {formik.touched.skills && formik.errors.skills && typeof formik.errors.skills === 'string' && ( <Text style={{ color: 'red', marginTop: 10 }}>{formik.errors.skills}</Text> )} <Button title="Submit" onPress={formik.handleSubmit} disabled={formik.isSubmitting} /> </View> ); } export default DynamicArrayForm;

Key takeaways from this example:

initialValues: We start with an array of objects.
validationSchema.array().of(skillSchema): This tells Yup that skills is an array, and each item in that array should conform to the skillSchema.
formik.handleChange('skills[${index}].name'): This is how you access and update fields within arrays using Formik. The bracket notation is critical.
formik.setValues(): When adding or removing items from an array, you typically want to use setValues to replace the entire array state, as it’s more predictable than trying to merge changes in deeply nested structures.
Error handling for arrays can be tricky. You might get an error for the array itself (e.g., “Please add at least one skill”) or for individual items within the array. The example shows how to check for both.

This pattern scales incredibly well for more complex nested structures as well. You just follow the same `field.subField[index].nestedField` notation.

Custom Input Components and Formik

In React Native, you’ll often create reusable custom input components (e.g., a custom date picker, a slider). To make them work with Formik, they need to accept props that mimic the standard TextInput props: value, onChange, and onBlur. Usually, you’ll create a wrapper component that passes these down.

// Example of a custom Input component function CustomInput({ label, value, onChange, onBlur, ...restProps }) { return ( <View> <Text>{label}</Text> {/* Imagine this is a more complex UI element */} <TextInput value={value} onChangeText={onChange} onBlur={onBlur} {...restProps} /> </View> ); } // Using it with Formik function FormWithCustomInputs() { const formik = useFormik({ // ... initialValues, validationSchema, onSubmit }); return ( <View> <CustomInput label="Username" value={formik.values.username} onChangeText={formik.handleChange('username')} onBlur={formik.handleBlur('username')} /> {/* ... render errors */} {/* ... other fields */} </View> ); }

The key is that your custom component’s onChangeText prop (or whatever its specific change handler is named) must accept a value and pass it up. You then pass formik.handleChange('fieldName') to it. Similarly, it should expose an onBlur prop, to which you pass formik.handleBlur('fieldName').

Debugging Common Form Issues

Even with powerful tools like Formik and Yup, you’ll hit snags. Here are a few common ones and how to tackle them:

Form doesn’t submit:
- Check if formik.handleSubmit is correctly attached to your submit button’s onPress.
- Ensure your onSubmit function isn’t throwing an unhandled error.
- If the button is disabled, check formik.isSubmitting or if there are validation errors preventing submission.
Validation errors not showing/showing incorrectly:
- Make sure onBlur={formik.handleBlur('fieldName')} is set on the input. Errors typically only show after a field is blurred and has errors.
- Verify that formik.touched.fieldName is true before displaying the error for that field.
- Double-check your Yup schema syntax. A small typo can break the entire schema.
- Ensure the field names in your schema exactly match the field names you pass to formik.handleChange and formik.handleBlur.
Input values not updating:
- Confirm that value={formik.values.fieldName} is correctly set on the input.
- Ensure onChangeText={formik.handleChange('fieldName')} is used.
- If using custom components, make sure they correctly pass their value up via props that Formik understands (usually value and a change handler that takes the new value).
Issues with arrays/nested objects:
- The most common pitfall here is incorrect indexing in handleChange and handleBlur. Use string interpolation: formik.handleChange(`skills[${index}].name`).
- When modifying arrays (add/remove), use formik.setValues or formik.setFieldValue to update the state correctly. Trying to directly mutate formik.values.skills often leads to unexpected behavior.

The Formik DevTools are a lifesaver for debugging complex forms. They can be integrated into your app and provide a live view of your form’s state, values, touched status, and errors, which is invaluable for understanding what’s happening under the hood.

Performance Considerations: Keeping Your Forms Snappy

For most forms, Formik and Yup are performant enough. However, in very large, complex forms with hundreds of fields or rapidly updating values, you might encounter performance issues. Here are a few strategies:

Debouncing/Throttling: If you have expensive validation logic that runs on every keystroke, consider debouncing or throttling the validation function. You can do this manually or use libraries like lodash. Formik has a validateOnMount and validateOnChange option that can be toggled, but for fine-grained control, external methods are better.
Memoization: For custom input components, ensure they are properly memoized using React.memo if they receive many props or have complex rendering logic. This prevents unnecessary re-renders.
Field-level validation: By default, Formik can re-validate the entire form on every change. You can optimize this by configuring Formik to validate only specific fields or when the component is blurred. This is controlled by options like validateOnChange and validateOnBlur in the `useFormik` hook.
Splitting Forms: For extremely complex forms, consider breaking them into smaller, multi-step forms. Each step can have its own Formik instance, simplifying state management and improving performance.

Generally, focus on making your Formik and Yup setup correct first. Only optimize when you have a measurable performance problem.

When Formik and Yup Might NOT Be the Best Fit

While I’m a huge fan, they aren’t a silver bullet for every scenario. Consider these:

Extremely simple forms: If you have a one-field form with no validation, using Formik might be overkill. The setup cost outweighs the benefit.
Forms with deeply complex, non-standard logic: While Formik is flexible, if your form logic is highly unconventional and doesn’t map well to schema-based validation or field-based state management, you might find yourself fighting the library.
Very low-level control needed: If you need to manage every single aspect of form state and rendering at the most granular level without any abstraction, a custom solution might be necessary.

However, for the vast majority of typical mobile app forms, the combination of Formik and Yup provides a robust, maintainable, and developer-friendly solution. You can find more information and examples in the [official Formik documentation](https://formik.org/docs/overview).

Conclusion: Building Better Forms with Confidence

Mastering React Native form handling with Formik and Yup is an investment that pays dividends. You move away from the painful boilerplate of manual state management and validation, adopting a more declarative, maintainable, and robust approach. By leveraging Formik for state and submission logic, and Yup for powerful, schema-based validation, you can build complex forms with confidence, reduce bugs, and significantly improve your development workflow.

It’s about writing less code, fewer bugs, and building forms that users actually enjoy interacting with. So, the next time you’re staring down a form requirement, remember these tools. They’ve saved me countless hours and a good deal of sanity, and I’m confident they can do the same for you.

🎥 Video: React Formik Tutorial with Yup (React Form Validation)

📺 Xem trên YouTube

React Native Form Handling: Mastering Forms with Formik and Yup

Lập Trình

React Native

14 min
2 tuần ago
1
16

Level up your React Native form handling. This deep dive covers practical strategies, common pitfalls, and best practices for using Formik and Yup effectively in your mobile apps.

Tagged debugging, performance, react-native

Alright, let’s talk about something that trips up even experienced React Native developers more often than we’d like to admit: React Native form handling. If you’ve ever found yourself drowning in a sea of state variables for a simple login screen, or wrestling with conditional rendering for error messages, you know the pain. Building forms in React Native can quickly turn into a complex, state-management-heavy beast if you don’t have a solid strategy. Today, we’re going to tackle this head-on, focusing on two powerful libraries that can turn your form-building nightmares into a smooth, predictable experience: Formik and Yup.

Why Form Handling is a Silent Killer (and How to Avoid It)

Forms are the gateway to user interaction. They’re how users sign up, log in, submit data, and ultimately, use your app. When forms are clunky, buggy, or just plain difficult to use, users get frustrated. This can lead to higher bounce rates, lower conversion rates, and a general feeling of ‘meh’ about your application. And from a developer’s perspective, poorly managed forms can become a maintenance black hole. Every input field, every validation rule, every error message adds a layer of complexity that’s easy to get wrong.

The core of the problem often lies in how we manage the state of our form fields and the intricate dance of validation that needs to happen before we can confidently send that data off to our backend.

The Core Problem: State Management Hell

Before Formik and Yup, a typical React Native form might look something like this in your head:

function MyForm() {
const [email, setEmail] = useState('');
const [password, setPassword] = useState('');
const [emailError, setEmailError] = useState('');
const [passwordError, setPasswordError] = useState('');
const [isLoading, setIsLoading] = useState(false);
const validateEmail = (value) => {
if (!value) return 'Email is required';
if (!isValidEmail(value)) return 'Invalid email format';
return '';
};
const validatePassword = (value) => {
if (!value) return 'Password is required';
if (value.length < 6) return 'Password must be at least 6 characters';
return '';
};
const handleSubmit = async () => {
const emailErr = validateEmail(email);
const passwordErr = validatePassword(password);
if (emailErr || passwordErr) {
setEmailError(emailErr);
setPasswordError(passwordErr);
return;
}
setIsLoading(true);
try {
// ... submit to API
alert('Success!');
} catch (error) {
// ... handle API errors
alert('An error occurred');
} finally {
setIsLoading(false);
}
};
return (


{emailError ? {emailError} : null}

{passwordError ? {passwordError} : null}

See the problem? Every field needs its own state, its own validation function, and its own error display logic. As your forms grow, this becomes incredibly verbose and error-prone. You start duplicating logic, forgetting to update a state variable, or missing a check. It’s a recipe for bugs.

Introducing Formik: Your New Best Friend

This is where Formik swoops in. Formik is a popular React library that helps you build forms in React and React Native with less boilerplate and better state management. It abstracts away the tedious parts of form handling, allowing you to focus on your UI and business logic.

Formik manages your form’s state (values, errors, touched status, submission status) and provides a handy set of props to connect your form elements to this state. It also gives you functions to handle input changes, validate fields, and submit the form.

Basic Formik Setup: Getting Started

First things first, let’s install Formik:

npm install formik
# or
yarn add formik

Now, let’s refactor our login form using Formik. The core of Formik is the component or the useFormik() hook. For functional components, the hook is generally cleaner.

Handling Input Changes and State

Formik provides the handleChange and handleBlur functions, which are designed to work directly with React Native’s TextInput component. The values object in Formik’s state holds the current values of your form fields.

The useFormik() hook takes an initialValues object and an onSubmit function.

import React from 'react';
import { View, TextInput, Button, Text } from 'react-native';
import { useFormik } from 'formik';
const LoginForm = () => {
const formik = useFormik({
initialValues: {
email: '',
password: '',
},
onSubmit: values => {
console.log('Form submitted:', values);
// This will be replaced by actual submission logic later
},
});
return (


{/* Error display will go here */}

{/* Error display will go here */}

Notice how we pass formik.handleChange('fieldName') directly to onChangeText. Formik automatically picks up the value and updates the corresponding field in its state.

Form Submission: The Grand Finale

Formik also gives us handleSubmit. When you call this function (usually via a Button’s onPress), Formik:

Prevents the default form submission behavior (which isn’t a thing in React Native apps, but it’s good practice).
Calls your onSubmit function (if validation passes).
Manages the isSubmitting state for you.

This is already a huge improvement. We’ve moved from managing individual state variables to having a centralized form state managed by Formik.

Enter Yup: Bringing Sanity to Validation

Okay, so we can manage our form state. But what about validation? We could write custom validation functions as we saw in the initial example, but that quickly becomes unmanageable for anything beyond the simplest forms. This is where Yup comes in.

Yup is a schema builder for value parsing and validation. It integrates seamlessly with Formik to define your form’s validation rules in a clear, declarative way.

Let’s install Yup:

npm install yup
# or
yarn add yup

Defining Your Schema

With Yup, you define a schema that represents the structure and constraints of your form data. It’s like creating a blueprint for your form.

import * as yup from 'yup';
const loginValidationSchema = yup.object().shape({
email: yup.string()
.email('Please enter a valid email')
.required('Email is required'),
password: yup.string()
.min(6, 'Password must be at least 6 characters')
.required('Password is required'),
});

This schema defines two fields, email and password. It specifies that email must be a string, a valid email format, and is required. password must be a string, at least 6 characters long, and is also required. Much cleaner, right?

Integrating Yup with Formik

To connect Yup to Formik, you simply pass your Yup schema to the validationSchema property of the useFormik() hook.

import React from 'react';
import { View, TextInput, Button, Text } from 'react-native';
import { useFormik } from 'formik';
import * as yup from 'yup';
const loginValidationSchema = yup.object().shape({
email: yup.string()
.email('Please enter a valid email')
.required('Email is required'),
password: yup.string()
.min(6, 'Password must be at least 6 characters')
.required('Password is required'),
});
const LoginForm = () => {
const formik = useFormik({
initialValues: {
email: '',
password: '',
},
validationSchema: loginValidationSchema,
onSubmit: values => {
console.log('Form submitted:', values);
// Actual submission logic goes here
},
});
return (


{formik.errors.email && formik.touched.email && (
{formik.errors.email}
)}

{formik.errors.password && formik.touched.password && (
{formik.errors.password}
)}

Now, Formik automatically uses your Yup schema for validation. When you call formik.handleSubmit, Formik will first run the validation. If there are errors, it populates formik.errors with the messages defined in your Yup schema. It also sets formik.touched properties, which is useful for showing errors only after a field has been interacted with.

We’ve added conditional rendering for errors: {formik.errors.email && formik.touched.email && (...)}. This pattern ensures that error messages only appear after the user has interacted with the field (touched) and there’s an actual error (errors.email).

Common Validation Scenarios and How to Tackle Them

Yup is incredibly versatile. Let’s look at some common scenarios:

Required Fields Made Easy

As seen above, the .required('Your error message') method is straightforward.

Email, Password, and Numeric Inputs

yup.string().email('Invalid email')
yup.string().min(x, 'Too short')
yup.number().positive('Must be positive').integer('Must be an integer')
yup.string().matches(/regex/, 'Invalid format')

Custom Validation: When Yup Isn’t Enough

Sometimes, you need validation logic that’s specific to your app, like checking if a username is already taken. Yup allows you to define custom validation methods.

You can add a custom validation method to your schema:

// Add this inside your component or in a separate validation file
const loginValidationSchema = yup.object().shape({
// ... other fields
username: yup.string()
.required('Username is required')
.test('is-unique', 'Username is already taken', async (value) => {
if (!value) return true; // Let .required handle empty case
// This is an async example. In a real app, you'd call an API here.
// For simplicity, let's simulate an async check:
await new Promise(resolve => setTimeout(resolve, 500)); // Simulate network latency
return value !== 'admin'; // Example: 'admin' is already taken
}),
});

Important Note: Formik’s validationSchema property handles synchronous validation by default. For asynchronous validation (like API calls), you need to manually trigger validation or use Formik’s validate prop, which is a function that receives the form values and should return an errors object.

A more common approach for async validation with Formik & Yup is to use the validate prop directly if you need more control, or to ensure your onSubmit handler handles async validation results.

Formik’s validate prop:

// ... inside useFormik
validate: async values => {
try {
await loginValidationSchema.validate(values, { abortEarly: false });
return {}; // Return empty object if valid
} catch (error) {
// Yup throws a ValidationError with an innerErrors object
const errors = {};
error.innerErrors.forEach(err => {
errors[err.path] = err.message;
});
return errors;
}
},
onSubmit: async (values) => {
// This onSubmit will only be called if validate passes.
console.log('Form submitted:', values);
// ... actual API call
}

This validate function runs before onSubmit. Using abortEarly: false ensures all validation errors are collected, not just the first one.

Arrays of Fields: Dynamic Forms!

This is where things get really powerful. Imagine a form where users can add multiple phone numbers or email addresses. Yup handles arrays beautifully.

const profileValidationSchema = yup.object().shape({
emails: yup.array()
.of(yup.string().email('Invalid email'))
.min(1, 'At least one email is required')
.required('Emails are required'),
phoneNumbers: yup.array()
.of(yup.string().min(10, 'Too short'))
.max(3, 'Max 3 phone numbers allowed')
.nullable(), // Allow the array itself to be null
});

In your component, you’d iterate over formik.values.emails and render a TextInput for each, passing formik.handleChange('emails[index]').

Handling Form State: Loading, Errors, and Success

Beyond just displaying validation errors, you need to manage the overall form state:

Disabling Buttons While Submitting

Formik provides formik.isSubmitting. Use this to disable your submit button and show a loading indicator.

Displaying Validation Errors Gracefully

We covered the basic {formik.errors.fieldName} display. For a more robust UI, consider:

Showing errors only after the field has been touched.
Using different text styles for errors (e.g., red color).
Providing inline error messages below each input.
Potentially a summary of errors at the top of the form.

The ‘Success’ State: What Now?

Once your onSubmit function successfully completes an API call, you’ll want to provide feedback. This might involve:

Showing a success message (e.g., a toast or alert).
Clearing the form fields using formik.resetForm().
Navigating the user to a different screen.

You can also use Formik’s setSubmitting(false) manually in your onSubmit if you’re not using the default behavior, but usually, it handles this for you.

If your API call fails, you can use formik.setErrors(serverErrors) to populate Formik’s error state with errors returned from the server (e.g., ’email already exists’).

Advanced Patterns and Gotchas

Performance Considerations

For very complex forms with many fields, excessive re-renders can become an issue. Formik is generally quite performant, but:

Avoid defining your validation schema inside the component if it doesn’t change. Define it outside.
Use React.memo or useCallback judiciously on your custom input components if they are becoming a performance bottleneck.
Consider using Formik’s FieldArray component (though it’s more for React, not directly React Native’s TextInput). For React Native, manual iteration with handleChange('array[index]') is standard.

Integrating with Third-Party UI Libraries

Libraries like React Native Paper or NativeBase often have their own input components. You’ll need to adapt Formik’s handlers. For example, if a library’s TextInput component expects a value and an onChangeText that receives just the text value:

// Assuming YourUILibraryTextInput needs value and onChangeText(text)

If the component expects an event object (less common in React Native input libraries), you might need a custom handler:

 formik.setFieldValue('email', event.nativeEvent.text)}
/>

Always check the props your UI library’s input component expects. Formik’s handleChange and setFieldValue are your go-to tools.

Testing Your Forms: A Crucial Step

Testing forms is vital. You can use libraries like React Native Testing Library to:

Simulate user interactions (typing, blurring).
Check if validation errors appear correctly.
Verify that the submit function is called with the correct data.

Testing your Formik and Yup integration ensures your complex validation rules are working as expected and your form state is managed correctly.

When Formik Might Not Be the Answer

While Formik is excellent for most use cases, it’s not always the perfect fit:

Extremely simple forms: For a single input field with no validation, the overhead might feel like overkill. You could manage state directly.
Complex, non-standard UI interactions: If your form involves highly custom UI elements that don’t map cleanly to input/change events, you might need more manual control.
Performance-critical, low-level applications: In very niche, hyper-optimized scenarios, you might consider building from scratch, but this is rare.

For the vast majority of mobile applications, Formik and Yup provide a robust, developer-friendly, and maintainable solution.

Lessons Learned from the Trenches

Don’t overcomplicate validation: Yup’s built-in methods cover 90% of cases. Use custom validation sparingly.
Error messages matter: Make them clear, concise, and helpful. They should guide the user, not confuse them.
Async validation is tricky: Understand when and how to use Formik’s validate prop or manual submission logic for API calls.
Always test: Automated tests for forms save countless hours of debugging.
Start with a schema: Before writing any input components, define your Yup schema. It acts as your contract.
Consider `FieldArray` implications: While Formik doesn’t have a direct FieldArray component for React Native like it does for React, you still need to handle array indices correctly for your dynamic fields.

I’ve personally spent hours debugging forms that could have been solved in minutes with a solid Formik and Yup setup. Learning to leverage these tools early on will save you a significant amount of pain.

Conclusion: Building Better Forms

Mastering React Native form handling with Formik and Yup is a game-changer for any developer. You move from wrestling with state and verbose validation to a clean, declarative, and maintainable approach. Formik manages the form’s lifecycle, and Yup provides a powerful, readable way to define your validation rules. Together, they empower you to build robust, user-friendly forms that are a joy to develop and a pleasure to use.

If you’re not already using them, I highly recommend giving Formik and Yup a try on your next React Native project. For more in-depth details and advanced features, the official Formik documentation is an excellent resource: Formik Documentation.

🎥 Video: Handling text input and validate in react native app 2023

📺 Xem trên YouTube

React Native Reanimated 3: Mastering Complex Animations for Production Apps

Lập Trình

React Native

22 min
2 tuần ago
4

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
2 tuần 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
2 tuần 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
2 tuần 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
2 tuần 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
2 tuần 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 tuần 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

Phá Kén

Thẻ: debugging

React Native Gesture Handler: A Practical Guide for Real-World Apps

React Native Form Handling: Mastering Forms with Formik and Yup

React Native Form Handling: Mastering Forms with Formik and Yup

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