Forem: Fouzia Naaz

I built a VS Code extension that scaffolds React Native MVVM features in one command

Fouzia Naaz — Thu, 23 Apr 2026 20:25:00 +0000

Every React Native developer knows this ritual.

You need a new screen. So you open an existing feature folder, copy the files, rename them one by one, fix the broken imports, delete the leftover logic, and spend 15 minutes doing work that has nothing to do with what you actually wanted to build.

I got tired of it. So I built a VS Code extension to fix it.

What it does

React Native MVVM Feature Generator scaffolds a complete MVVM feature folder with one command.

You hit Cmd+Shift+P, type a name like Checkout, and get:

src/features/Checkout/ ├── CheckoutView.tsx ├── useCheckoutViewModel.ts ├── checkoutService.ts ├── checkoutTypes.ts ├── CheckoutView.test.tsx ├── useCheckoutViewModel.test.ts └── index.ts

Every file is pre-wired. The View imports the ViewModel. The ViewModel imports the Service. The Service imports the Types. Zero circular dependencies, zero manual setup.

The problem it solves
On any organised React Native project, every feature needs the same four files. The structure is always the same. The naming convention is always the same. Yet every developer does it slightly differently and every new screen starts with a copy-paste ritual.

What I built into it
5 state adapters — when creating a feature you pick your state library. It generates a ViewModel tailored to useState, Zustand, Redux Toolkit, TanStack Query, or Jotai. Set a default in settings so you're never prompted.

Test files by default — every feature ships with a ViewModel unit test and a View render test already written. Most scaffolders skip this. Shipping tests by default changes the default.

Navigation registration — if @react-navigation/* is in your project, the extension offers to inject the new screen into your navigator file automatically.

Open Feature — a quick pick command that lists all your existing features and jumps straight to the View file. Turns the extension from a one-time generator into something you use every day.

Convert to MVVM — right-click any existing .tsx file and the extension extracts useState blocks into a ViewModel, fetch calls into a Service, and rewrites the original as a thin View. For teams adopting MVVM on an existing codebase.

Try it
Search "React Native MVVM Feature Generator" in the VS Code Extensions tab or install directly:

ext install fouzianaaz.rn-mvvm-feature-generator

How I Refactored a Messy React Native Screen into MVVM (A Real Example)

Fouzia Naaz — Tue, 21 Apr 2026 09:16:43 +0000

Most React Native projects don't start messy.

They become messy over time.

A screen that once handled simple UI gradually starts doing everything:

API calls
state management
data transformation
navigation logic

I recently refactored one such screen, and the difference was bigger than I expected.

The Problem: Everything in One Place

The original screen looked something like this:

API calls inside useEffect
Multiple useState hooks
Inline business logic
Conditional rendering everywhere

It worked - but it wasn't scalable.

The issues were clear:

Hard to read
Hard to test
Hard to reuse logic

Before: A Typical "Messy" Structure

const Screen = () => {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    fetchData();
  }, []);
  const fetchData = async () => {
    setLoading(true);
    const res = await apiCall();
    const filtered = res.filter(item => item.active);
    setData(filtered);
    setLoading(false);
  };
  return (
    <>
      {loading ? <Loader /> : data.map(item => <Item key={item.id} />)}
    </>
  );
};

Everything is tightly coupled.

The Goal
I wanted to:

Separate UI from logic
Make the code reusable
Improve readability
Prepare for scaling

After: Introducing MVVM

I split the logic into:

View (UI)
ViewModel (logic)
Service (API layer)

ViewModel (logic layer)

export const useScreenViewModel = () => {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(false);

  const fetchData = async () => {
    setLoading(true);
    const res = await apiCall();
    const filtered = res.filter(item => item.active);
    setData(filtered);
    setLoading(false);
  };
  return {
    data,
    loading,
    fetchData,
  };
};

View (clean UI)

const Screen = () => {
  const { data, loading, fetchData } = useScreenViewModel();

  useEffect(() => {
    fetchData();
  }, []);
  if (loading) return <Loader />;
  return data.map(item => <Item key={item.id} />);
};

What Changed

Cleaner Components UI is now focused only on rendering.
Reusable Logic ViewModel can be reused or tested independently.
Easier Debugging Logic is centralized and predictable.
Better Team Collaboration Different developers can work on UI and logic separately.

What Didn't Change

The functionality stayed exactly the same.
This is important:
Refactoring is about improving structure - not changing behavior.

Lessons Learned

Messy code is usually a result of growth, not bad intentions
Small architectural decisions compound over time
Separation of concerns is not optional in scaling apps

When to Use This Approach

You don't need MVVM for every screen.
Use it when:

Logic starts growing
State becomes complex
Multiple developers are involved

Final Thoughts

React Native gives you flexibility but that flexibility can become chaos if you don't define structure.
Refactoring this screen reminded me of one thing:
Clean architecture is not about perfection it's about making future changes easier.

How I Structure Scalable React Native Apps Using MVVM

Fouzia Naaz — Mon, 20 Apr 2026 12:34:10 +0000

As React Native apps grow, one problem becomes unavoidable:
things start getting messy.

What begins as a simple component structure slowly turns into:

tightly coupled logic
hard-to-maintain screens
unpredictable state handling

I ran into this while working on production apps, and that’s when I started adopting a more structured approach: MVVM (Model–View–ViewModel).

Why React Native Apps Become Hard to Scale

In many projects, logic ends up inside components:

API calls
business logic
state transformations

This creates:

poor readability
difficult testing
repeated logic across screens

The bigger the app gets, the worse it becomes.

What MVVM Solves

MVVM separates responsibilities:

Model → data layer (API, storage, types)
View → UI components
ViewModel → business logic + state handling

This separation helps keep your UI clean and your logic reusable.

My Folder Structure

Here’s how I typically organize a feature:

/features
  /user
    UserView.tsx
    useUserViewModel.ts
    userModel.ts
    userService.ts

View handles rendering
ViewModel manages logic
Model/Service handles data

Example: View vs ViewModel

View (UI only)

const UserView = () => {
  const { user, loading, fetchUser } = useUserViewModel();

useEffect(() => {
    fetchUser();
  }, []);
  if (loading) return <Loader />;
  return <Text>{user.name}</Text>;
};

ViewModel (logic)

export const useUserViewModel = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(false);

  const fetchUser = async () => {
    setLoading(true);
    const data = await getUser();
    setUser(data);
    setLoading(false);
  };
  return { user, loading, fetchUser };
};

Why This Works Well in Production

Easier to test logic separately
Reusable business logic
Cleaner UI components
Better team collaboration

Most importantly:

You stop rewriting the same logic in multiple places

How It Fits with Redux

If you’re using Redux:

Keep global state in Redux
Keep screen-specific logic in ViewModels

This avoids overloading Redux with unnecessary complexity.

Common Mistakes to Avoid

Putting everything into Redux
Mixing UI and business logic
Over-engineering small features

MVVM should simplify your app — not complicate it.

Final Thoughts

React Native doesn’t enforce architecture, which is both a strength and a weakness.

If you don’t define structure early, scaling becomes painful.

For me, MVVM has been a simple and effective way to:

organize code
improve maintainability
build more predictable apps

It’s not the only approach — but it’s one that works well in real-world projects.