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

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

Cheat sheets