# MVC Partials with fetch: an overview

An MVC page can reload just one part of itself. JavaScript fetches the new part's HTML from an action that returns a partial view, and swaps it in. That's the MVC way to do what an API and JSON do for a JavaScript-built page.

Journeyman · ASP.NET Core · JavaScript · Updated November 3, 2026

## After this lesson you can

- Explain when to reload part of a page with fetch, and the difference between fetching JSON and fetching HTML

## Key takeaways

- To change one part of a page, fetch just that part instead of reloading the whole page.
- An API sends JSON and JavaScript builds the elements; an MVC action sends finished HTML that JavaScript puts straight into the page.
- Fetching HTML drawn by the same partial view the full page uses keeps one place that decides how the part looks.
- Progressive enhancement means building the plain version first, then making it smoother with JavaScript, so the page still works without it.

Click page 2 on NorthwindWeb's product list from *ASP.NET Core MVC in Depth*, and the whole page comes back: the navigation bar, the *Recently viewed* line, the heading, the pager, the footer, and the scripts and styles behind them. Only the twelve product cards actually changed.

A page can do better: fetch **just the part that changes**, and swap it in.

## Two ways to swap in a part

You've now seen two kinds of server:

| | API, as in *Async and Await* | MVC, as in this topic |
|---|---|---|
| The server sends | **JSON**: the data | **HTML**: the finished part of the page |
| JavaScript then | Builds the elements itself, from the data | Puts the HTML straight into the page |
| The look is decided by | The JavaScript | The server's Razor views, the same ones the page uses |
| Good for | Pages built mostly in JavaScript, and other programs | Mostly server-built MVC pages that need a few live parts |

For an MVC app, fetching HTML has a big advantage: the part is drawn by the **same partial view** the full page uses, so there's one place to change how a product card looks, not a Razor version and a JavaScript version.

## What it takes

Three small pieces, one per lesson in this topic:

1. **A partial view** holding the part that changes: here, the grid of product cards, `_ProductGrid.cshtml`. The full page renders it with `<partial>`, as before.
2. **An action that returns only that partial**, with `PartialView(...)` instead of `View(...)`: `GET /products/grid?page=2` answers with the twelve cards, no layout.
3. **JavaScript** that catches the pager's clicks, fetches the partial's HTML, and puts it in place of the old grid.

## Still works without JavaScript

The pager's links still point at `/products?page=2`, the full page. JavaScript only steps in when it runs: it cancels the click and fetches the partial instead. If the script fails to load, or a search engine follows the link, the page still works the old way.

Building the plain version first, then making it smoother with JavaScript, is called **progressive enhancement**. It's a good habit: the page never depends on its fanciest part.

## Check yourself

1 question to try on the lesson page.

## So what

Reloading a whole page to change one part wastes time and data. Fetch the part's HTML from a partial view instead: the server still decides how it looks, and the user never sees the page flash.

## Key terms

- Partial View
- [Progressive Enhancement](https://www.ask-codey.com/glossary/progressive-enhancement)

## Cheat sheets

- [MVC Partials with fetch: an overview](https://www.ask-codey.com/cheat-sheets/mvc-partials-with-fetch-an-overview-cheat-sheet)

Source: https://www.ask-codey.com/lessons/mvc-partials-with-fetch-an-overview