MVC, MVP, MVVM all come from worlds React Native doesn't fully have. Half of each pattern dies on import. The other half is what most React Native code is already doing under different names. This post is about which half is which.
What React Native is missing
Before mapping a pattern onto React Native, notice what isn't there.
No swappable view. In Cocoa or WPF, the View is an object you can replace, subclass, or wire to a different controller. In React Native the View is a function call result. There's nothing to swap. The closest equivalent is "render a different component," which isn't the same operation.
No two-way binding. WPF, Knockout, early Angular: the View binds to a property; updating either side updates the other. React went the other way on purpose. State flows down, events flow up, and "binding" is a manual value plus onChange. MVVM assumes the binding does work; in React Native, you do that work.
No framework-managed event loop. MVC and MVP came from worlds where the framework dispatched events to your Controller or Presenter. In React Native the runtime is JS plus React's reconciler. Events arrive at components. There's no router for them above that.
Components are functions, not objects. This is the one that breaks the most. Every pattern named here was designed around classes with explicit lifecycles. Hooks replaced that with closures and effects. The shapes don't line up.
You can ignore all of this and write class HomeScreenController extends Controller if you want. It will compile. It won't feel right, and it will be the only Controller in the app inside a month.
The example
One screen, carried through every pattern. A list of items with loading, error, and refresh. Boring on purpose. The interesting part is where the logic ends up.
function ItemsScreen() {
// get list, status, retry, refresh from somewhere
// render based on status
}
Where "somewhere" lives is the whole conversation.
MVC: the Controller has no home
MVC's job split:
- Model holds data and rules
- View renders
- Controller receives input, mutates the model, tells the view to update
In Cocoa, the Controller is a real object. viewDidLoad, tableView(_:didSelectRowAt:), methods you can put a breakpoint on. In Rails, the Controller is the route handler.
In React Native, where would you put one?
function useItemsController() {
const [state, setState] = useState({ status: 'idle', data: [], error: null })
const load = async () => {
setState({ status: 'loading', data: [], error: null })
try {
const data = await api.get('/items')
setState({ status: 'ready', data, error: null })
} catch (error) {
setState({ status: 'error', data: [], error })
}
}
return { ...state, load }
}
That's a hook. We called it a controller. It's still a hook. And it lives inside the component that renders, which is the View. The Controller you can put a breakpoint on, the one that has its own lifecycle, doesn't exist here. Hooks ate it.
The other failure mode is worse. People interpret "Controller" as "the screen file with all the logic in it" and end up with 600-line components that nobody calls a controller but that play the same role. That isn't MVC. That's MVC's symptom without its discipline.
What survives: the Model. A real Model layer (use cases, repositories, types) is still useful and still goes in a folder that isn't screens/. The Controller part has no analog worth defending.
MVP: the Presenter, almost
MVP fixed one thing about MVC: the View becomes passive. It only knows how to render and emit events. The Presenter holds the logic and pushes data to the view.
In Android, this looked like:
class ItemsPresenter {
void onAttach(ItemsView view) { ... }
void onLoad() { ... } // calls model, then view.showList(...)
}
In React Native, the closest analog is a custom hook that returns a fully-shaped props object, paired with a passive component:
function useItemsPresenter() {
const [status, setStatus] = useState<'idle' | 'loading' | 'ready' | 'error'>('idle')
const [items, setItems] = useState<Item[]>([])
const [error, setError] = useState<Error | null>(null)
const load = useCallback(async () => {
setStatus('loading')
try {
setItems(await getItems.execute())
setStatus('ready')
} catch (e) {
setError(e as Error)
setStatus('error')
}
}, [])
useEffect(() => { load() }, [load])
return { status, items, error, retry: load }
}
function ItemsView({ status, items, error, retry }: Props) {
if (status === 'loading') return <Spinner />
if (status === 'error') return <ErrorState error={error} onRetry={retry} />
return <FlatList data={items} renderItem={...} />
}
function ItemsScreen() {
const props = useItemsPresenter()
return <ItemsView {...props} />
}
This works. It's testable: you can render ItemsView with arbitrary props in a Storybook story or a snapshot test, and you can run useItemsPresenter in renderHook without touching the UI.
The friction is honest. You now have three things (screen, presenter, view) where some teams would rather have one. The split feels like ceremony when the screen is small. The first time the same screen needs a tablet variant, an A/B test, or to be reused for a different user role, the split earns its keep.
What survives: the passive view plus presenter hook split, when the split is worth it. What doesn't: calling it MVP. Most React Native engineers will read it as "container plus presentational component," which is the name React used for the same idea before hooks blurred the line.
MVVM: the closest fit, and the most misunderstood
MVVM:
- Model as before
- View binds to a ViewModel
- ViewModel exposes observable state and commands. It doesn't know about the View.
The defining feature is the binding. In WPF, <TextBox Text="{Binding Name}" /> keeps both sides in sync. The ViewModel never imports the View. The View never asks the ViewModel for data; it observes.
React Native has no two-way binding. But the spirit of MVVM, a ViewModel that exposes state and commands and doesn't know who's watching, maps surprisingly well onto two things React Native already has.
Hooks as ViewModels. A custom hook that owns state and exposes commands is a ViewModel. The "binding" is React's render cycle: when state changes, the component re-renders. Same outcome as MVVM, achieved with a different mechanism.
Stores as ViewModels. Zustand, Jotai, MobX. A store that holds state and exposes commands is a textbook ViewModel. The component subscribes via a selector. The store has no idea what's rendering.
const useItemsVM = create<{
status: 'idle' | 'loading' | 'ready' | 'error'
items: Item[]
error: Error | null
load: () => Promise<void>
}>((set) => ({
status: 'idle',
items: [],
error: null,
load: async () => {
set({ status: 'loading' })
try {
const items = await getItems.execute()
set({ status: 'ready', items })
} catch (error) {
set({ status: 'error', error: error as Error })
}
},
}))
function ItemsScreen() {
const status = useItemsVM(s => s.status)
const items = useItemsVM(s => s.items)
const load = useItemsVM(s => s.load)
useEffect(() => { load() }, [load])
if (status === 'loading') return <Spinner />
if (status === 'error') return <ErrorState onRetry={load} />
return <FlatList data={items} renderItem={...} />
}
Two properties of MVVM hold here:
- The ViewModel doesn't import the View. It can be tested by calling
useItemsVM.getState().load()in plain Node, no render tree required. - The View only reads from the ViewModel; it doesn't reach into the Model directly.
What you give up versus classical MVVM: the binding is unidirectional, and there's no INotifyPropertyChanged ceremony. You don't miss it.
The misunderstood part: most "MVVM in React" articles treat hooks as a flawed approximation. They aren't. They're the same idea with the binding mechanism replaced. If anything, they're cleaner. There's no hidden observer registration, just a render that re-runs when state changes.
What survives: most of MVVM's intent. ViewModel-as-hook or ViewModel-as-store is a plausible default for any non-trivial screen. What doesn't: data binding. You wire it manually with value and onChange, and you stop missing it after a week.
What actually survives
Strip the labels. The shared idea behind MVC, MVP, and MVVM is one sentence: keep render separate from logic. They differ on how, on who owns what, on what the framework does for you. They agree that a screen file with API calls, validation, navigation, and rendering is going to hurt.
Three things survive the trip to React Native:
The Model is real. Use cases, repositories, domain types. Lives in its own folder. No imports from the framework. (See clean-architecture-react-native for how to draw that line.)
The View should be small enough to render in a Storybook story. If you can't render a component with arbitrary props because it does its own fetching, you've fused the View and ViewModel without meaning to.
Logic lives in a hook or a store, not in the component. Whether you call it a presenter, a view model, or just
useItems, the rule is the same: the component's body should mostly be branches on state and event handlers that delegate.
The patterns are different names for the same advice, dressed for the framework that birthed them.
When the labels actually help
Two honest cases:
Onboarding. If you join a team that says "we use MVVM," you need to know which part of MVVM they kept and which part they redefined. The label is a starting point, not the answer. The right next questions are "where does the logic live" and "what is the View allowed to know."
Cross-platform conversations. If you're talking to a UIKit engineer who writes MVC, an Android engineer used to MVP, or a WPF engineer with two decades of MVVM, the labels are the bridge. Telling them "we use hooks" describes the mechanism, not the architecture. Telling them "the screen is the View, the hook is the ViewModel, the use case is the Model" lets them ask the right follow-ups.
The bad case for labels is cargo-culting. A folder structure with views/, viewmodels/, and models/ doesn't make a codebase MVVM if half the screens still call fetch directly. Folders are documentation. Lint rules and review are enforcement.
The bill at month twelve
The patterns are old. The advice underneath them isn't. React Native doesn't get to skip the question of where logic lives just because hooks make it cheap to put it everywhere. The screen file that does its own fetching, validation, and animation will still be the one you debug at midnight, regardless of which acronym you put on the wall.
Pick a place for logic that isn't the component. Make the component small enough to render with props. Test the logic without rendering. The label matters less than whether the next engineer can find the bug.
Top comments (0)