Build a React Native drawer menu inside a stack navigator, wire a profile edit form to Redux Saga, and fix real errors from a 2020 Dev Doido lesson.
How do you add a React Native drawer menu inside a stack navigator?
A React Native drawer menu in a stack navigator is created by making the drawer navigator a child screen of the stack, not a sibling. The stack keeps login and signup at the root, and one stack screen renders the drawer so the hamburger icon appears only on the routes that need it. Dev Doido built this in a React Navigation lesson published in 2020.
The structure he settled on is worth repeating, because the wrong version is what produces a screen with no visible menu:
// ClientNavigator.js (structure, not production code)
<Stack.Navigator>
<Stack.Screen name="Login" component={SignIn} />
<Stack.Screen name="SignUp" component={SignUp} />
<Stack.Screen name="App" component={AppContainer} />
</Stack.Navigator>
// AppContainer.js
<Drawer.Navigator>
<Drawer.Screen name="Profile" component={Profile} />
</Drawer.Navigator>The transcript shows two failed attempts before the working version. First he had the drawer configured beside the stack rather than inside it, and the profile screen rendered as a plain purple block. The fix was extracting a container component that holds the drawer and registering that container as a stack screen.
Naming matters as much as nesting. The lesson's initial import used a misspelled package path, which produced a module resolution error rather than a navigation error. He corrected the package name and reinstalled before the hamburger icon rendered.
Which versions of React Navigation and React Native does this lesson assume?
The lesson assumes React Navigation 5 and a React Native release from mid-2020, and the video description contradicts itself by listing both navigation 4 and navigation 5. The code that appears in the transcript uses the Stack.Navigator component API introduced in React Navigation 5. Current documentation at reactnavigation.org describes the same nested pattern, so the structure has aged better than the exact prop names.
| Layer | Version in the 2020 lesson | Status in late 2026 |
|---|---|---|
| React Navigation | 5 | Several major versions ahead |
| React Native Paper | Contemporary release | Still maintained |
| Formik | Contemporary release | Maintenance mode, docs encourage alternatives |
| Redux Saga | Contemporary release | Still maintained |
Two details in the transcript date it precisely. The recording happened on Brazil's Valentine's Day in 2020, which he mentions on camera, and the code uses react-native-vector-icons alongside React Native Paper for the icon set. Neither detail changes the architecture, but a reader copying the code today will need current install commands for each package.
How do you wire the profile edit form to Redux Saga?
The profile form is wired to Redux Saga through one action, one watcher, one worker, and one reducer case that writes the updated user object into state. Dev Doido created a request action, a success action, and a failure action, then let the worker call the backend and dispatch success with the response payload.
The pattern he wrote is close to the standard Redux Saga shape:
- A request action carries the form values: name, old password, password, and password confirmation, grouped into one object.
- A watcher function listens for that action type and calls the worker.
- The worker calls the API, then dispatches a success action with the response data.
- The reducer handles the success case and writes the profile into the user state.
The component dispatches the request action only after Formik reports the form as valid. The submit handler receives both the values and the form state, checks the isValid flag, and dispatches; the button stays inert while validation fails. This keeps invalid submissions out of the saga entirely.
How does Formik and Yup validation protect the password fields?
Formik holds the form state and Yup defines the schema, and the password confirmation rule uses Yup's oneOf check to compare two fields. Dev Doido defined name, old password, password, and confirmation in the schema, and the confirmation field fails validation unless it matches the password field exactly.
He kept the email field visible but read-only so the user can see the account address without changing it. That decision removes email from the submit payload and avoids a backend update path the lesson never built, since email is treated as an identity field rather than editable profile data.
The initial form values are pulled from the user object in Redux state. Name and email load from the stored profile, and the password fields start empty because the app never holds the current password as a readable value. Anything else would mean storing credentials in client state, which the lesson avoids.
Why did the profile update fail, and how was it fixed?
The profile update failed because the backend returned the user object with a field type the frontend did not expect, and the fix was changing the backend response shape rather than the client. Dev Doido hit the error while testing a save, traced it to the response, edited the backend user fields, redeployed, and the same request then succeeded.
The transcript makes the correction look simple, but the useful lesson is about where to look. A response-shape mismatch surfaces in the component that reads the object, which made the error appear to be a form bug at first. The actual cause sat in the API layer, and the client code was already correct.
He redeployed the backend and re-ran the same test with a new password, and the app showed the updated profile. He did not isolate which field caused the mismatch on camera, so treat the exact field as undocumented rather than guessing.
Where should the logout action live in a drawer app?
The logout action belongs inside the drawer's own screen area, where it can dispatch the authentication action and let the root navigator swap back to login. Dev Doido created a small inline component that dispatches the sign-out action when mounted, then placed it as a drawer entry so selecting it immediately returns the user to the login screen.
That pattern is a hack, and he says so on camera. An effect that dispatches on mount works because the drawer screen never renders until the user picks it, so the action fires exactly once per selection. A dedicated button handler would be cleaner and easier to test.
The visible outcome matters more than the implementation. Once the auth state clears, the root navigator unmounts the drawer container and shows the login route again, which is why the logout screen needs no visual design of its own.
What work does the profile screen leave for later?
The profile screen ends with a name field, a read-only email, password change fields, and a save button, and the lesson defers everything tied to payments and address data. The closing minutes list the next screens: profile completion, billing address with postal code lookup, and a credit card form.
He also mentions a planned payment integration with Pagar.me, a Brazilian payment gateway, and says the next video would cover it. Treat that as a stated intention from June 2020 rather than a delivered lesson, since the transcript gives no date for the follow-up.
The repository that accompanies the class, gumiranda/Aula6DevDoido, is a teaching sample rather than a maintained starter. It was created in 2021 and carries no guarantee of current dependency versions.
Should you copy this 2020 stack today?
Copy the structure, not the package list. The nested drawer inside a stack is still the documented way to build a React Native drawer menu in current React Navigation, but the surrounding stack of Formik, Yup, Redux Saga, and React Native Paper reflects 2020 conventions more than 2026 recommendations.
Formik's own maintainers have moved its documentation toward a maintenance-mode framing and point readers to alternatives, so a new project should evaluate the current recommendation before adopting it. Redux Saga remains a valid choice for complex async flows, though Redux Toolkit now covers many cases that once needed a saga.
For a new build, keep the navigation shape, replace the form library if you prefer, and confirm every package version against its current documentation. The lesson's lasting value is the architecture and the debugging sequence, not the exact dependency set.
Frequently asked questions
- Does a drawer have to be nested inside a stack? Not always, but nesting is what allows a drawer to appear on some routes and not others. A single-navigator app can use a drawer alone, and a stack alone has no drawer.
- Why did the hamburger icon not appear? The most common cause in this lesson was the drawer configured outside the stack rather than rendered as a stack screen. A misspelled package import produced a separate error before the icon issue appeared.
- Is Redux Saga still used in 2026? Yes, Redux Saga remains maintained and is still used for complex async flows. Redux Toolkit covers many simpler cases that previously required a saga.
- Can the email field be edited on this profile screen? No, the lesson renders it read-only so the user can see the address without changing it. The submit payload excludes email.
- What caused the profile save error? A backend response shape mismatch, fixed by editing the user fields in the backend and redeploying rather than changing the frontend.
Turning one recorded lesson into a written reference
The recurring theme in this 2020 class is that the architecture survives longer than the tooling around it. The nested drawer inside a stack still answers the same question today, while the Formik, Yup, and Redux Saga choices sit on a 2020 vintage.
If your channel carries similar material, whether a live debugging session or a walkthrough of a navigation pattern, that content can become a written article. Skala Blog takes a YouTube URL, transcribes the video, and generates a structured draft.
Dev Doido and other creator-led channels record explanations worth keeping, and Crazystack typescript resources at crazystack.com.br show how technical material reads when it is written for reference rather than playback.