Rendering strategies

Two ways the same shop page can arrive

Every React page you've built in this course rendered in the browser: React ran your components there and put the result on the page. That isn't the only place it can happen. Here is a small shop page. Its result is live; click Add.

1import { useState } from "react";2 3const products = [4  { id: "tea", name: "Green tea", price: 3 },5  { id: "cake", name: "Carrot cake", price: 4 },6];7 8export default function App() {9  const [count, setCount] = useState(0);10  return (11    <main>12      <h1>Shop</h1>13      <p>Cart: {count}</p>14      <ul>15        {products.map((product) => (16          <li key={product.id}>17            {product.name}: ${product.price} <button onClick={() => setCount(count + 1)}>Add</button>18          </li>19        ))}20      </ul>21    </main>22  );23}

Lines 3 to 6 are the products. Line 9 keeps the cart's count in state, and line 17 makes one list item per product, each with a button that adds 1. Nothing new. What this lesson asks is: where and when do these components turn into HTML, and what does the browser get first? With a plain Vite app, the server sends this:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Shop</title>
    <script type="module" crossorigin src="/assets/index-B7xQ2k.js"></script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

Line 9 is the whole body: an empty <div id="root">. Line 6 loads the JavaScript. Until that file has downloaded and run, the page is blank. A server can instead run the components itself and send what they show:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Shop</title>
    <script type="module" crossorigin src="/assets/index-B7xQ2k.js"></script>
  </head>
  <body>
    <div id="root"><main><h1>Shop</h1><p>Cart: <!-- -->0</p><ul><li>Green tea<!-- -->: $<!-- -->3<!-- --> <button>Add</button></li><li>Carrot cake<!-- -->: $<!-- -->4<!-- --> <button>Add</button></li></ul></main></div>
  </body>
</html>

Line 9 now holds the shop: the heading, the count, and both products, as plain HTML. The browser can show it as soon as it arrives. This is the real output of React's server renderer for the component above. The <!-- --> comments mark where one piece of text ends and the next begins, so React in the browser can match them later. The buttons are there, but they don't work until the same JavaScript has loaded.

Client-side rendering: the browser builds the page

With client-side rendering (CSR), the server sends the empty HTML and the JavaScript, and the browser does everything else. Data comes last, because the code that asks for it is in that JavaScript. Here, fetchProducts stands in for a request to a server that takes 1.5 seconds. Press Run again under the result to watch it load again.

1import { useEffect, useState } from "react";2 3function fetchProducts() {4  return new Promise((resolve) => {5    const products = [6      { id: "tea", name: "Green tea", price: 3 },7      { id: "cake", name: "Carrot cake", price: 4 },8    ];9    setTimeout(() => resolve(products), 1500);10  });11}12 13export default function App() {14  const [products, setProducts] = useState(null);15 16  useEffect(() => {17    fetchProducts().then(setProducts);18  }, []);19 20  if (!products) return <p>Loading products…</p>;21  return (22    <ul>23      {products.map((product) => (24        <li key={product.id}>25          {product.name}: ${product.price}26        </li>27      ))}28    </ul>29  );30}

Lines 3 to 11 fake a server: a promise that gives the products after 1500 ms. Line 14 starts with no products, so line 20 shows Loading products…. Lines 16 to 18 are an Effect that asks for the data after the first render (Fetching data covers this pattern and its pitfalls). When the answer arrives, setProducts stores it, and lines 21 to 29 show the list.

Here is the whole page load as three lanes, server, network and browser, using the lesson's model of a phone on a fast connection:

Client-side rendering, in short:

• The first HTML is empty. Something shows at 460 ms, after the JavaScript runs, and the products at 1390 ms, after a second trip for the data.
• Search engines and link previews see little. Google runs JavaScript, but in a later pass; many other crawlers, and the link previews in chat apps, read only the HTML.
• It's cheap and simple to host. The server only sends files, which a CDN (a network of servers close to your visitors) can do.
• After the first load, moving between pages is fast, because the app is already running in the browser (Routing shows how).

Server-side rendering: HTML for every request

With server-side rendering (SSR), a server runs your components for each request and sends the HTML they describe. React does this with react-dom/server. Its simplest function, renderToString, takes JSX and returns HTML as text. It runs in a browser too, so you can watch it here:

1import { renderToString } from "react-dom/server";2 3function ProductList({ products }) {4  return (5    <ul>6      {products.map((product) => (7        <li key={product.id}>{`${product.name}: $${product.price}`}</li>8      ))}9    </ul>10  );11}12 13const products = [14  { id: "tea", name: "Green tea", price: 3 },15  { id: "cake", name: "Carrot cake", price: 4 },16];17 18// On a real server, this line runs for every request.19const html = renderToString(<ProductList products={products} />);20 21export default function App() {22  return <pre style={{ whiteSpace: "pre-wrap" }}>{html}</pre>;23}

Lines 3 to 11 are an ordinary component. Line 19 calls renderToString with it, and the result shows the text it returns: <ul><li>Green tea: $3</li>…. On a server, that text goes inside the page's <div id="root">, as in the overview. Press Edit & run and add a third product on line 15: the HTML grows.

HTML can't respond to clicks. To make the page interactive, the browser loads the same JavaScript, and React runs the components again and connects them to the HTML that's already there. That step is hydration. Until it's done, the page looks ready but isn't. This demo has no server, so line 8 makes the server's HTML itself; line 12 hydrates it 3 seconds later, the way a slow script would arrive. Click Add to cart right away, then again after the sentence changes:

1import { hydrateRoot } from "react-dom/client";2import { renderToString } from "react-dom/server";3import App from "./App.jsx";4 5const root = document.getElementById("root");6 7// 1. The server's HTML arrives: the page shows, but nothing responds.8root.innerHTML = renderToString(<App />);9 10// 2. Three seconds later the JavaScript has loaded, and React takes over.11setTimeout(() => {12  hydrateRoot(root, <App />);13}, 3000);

Line 8 fills the root with the HTML that App renders: you see the price and the button at once. Line 12, hydrateRoot, runs after 3 seconds and takes over that HTML. Before then, nothing listens for clicks, so they're lost: the count stays at 0. In the App.jsx tab, line 8 runs only in the browser after hydration, so the sentence on line 15 changes from HTML only: clicks do nothing yet. to JavaScript has run: clicks work. The lesson Server rendering and hydration explains hydrateRoot, and what happens when the server's HTML and the browser's render don't match.

Server-side rendering, in short:

• The first HTML has the content, so the products show at 960 ms in the lesson's model, and search engines read them.
• The first byte waits for the data. The server loads the products before it sends anything: 930 ms here, and slower data makes it later.
• The page responds only after hydration, at 1340 ms: the gap you clicked into.
• Every visit costs server work: loading data and rendering, for every request.

Static generation: HTML built ahead of time

If a page is the same for every visitor, there's no need to render it for each one. With static generation (SSG), you render every page once, when you build the site, and save the HTML as files. React 19 added prerender, in react-dom/static, for this: unlike renderToString, it waits for data that Suspense is waiting on, so the files are complete. Frameworks run a build step like this for you; written by hand it looks like this:

import { writeFile } from "node:fs/promises";
import { prerender } from "react-dom/static";
import { ProductPage } from "./ProductPage.js";
import { loadProducts } from "./data.js";

const products = await loadProducts();

for (const product of products) {
  const { prelude } = await prerender(<ProductPage product={product} />);
  const html = await new Response(prelude).text();
  await writeFile(`dist/products/${product.id}.html`, html);
}

Line 6 loads the products once, at build time. Lines 8 to 12 render ProductPage for each one: line 9 calls prerender, line 10 reads its result as text, and line 11 writes a file. This is the component it renders:

export function ProductPage({ product }) {
  return (
    <main>
      <h1>{product.name}</h1>
      <p>{`$${product.price}`}</p>
    </main>
  );
}

With the shop's two products, the build writes dist/products/tea.html, holding <main><h1>Green tea</h1><p>$3</p></main>, and dist/products/cake.html. A CDN then sends those files as they are.

Static generation, in short:

• It's the fastest first response: a file from a server near the visitor, with the products in it, at 80 ms, whatever the data costs.
• It's cheap: no rendering per visit.
• The data is as old as the build. A new price needs a new build, and a site with a million products takes long to build.
• It can't differ per visitor. Anything personal, like a signed-in name, is added by the browser after hydration.

Revalidation: static pages that refresh themselves

Revalidation keeps static pages fresh without rebuilding the whole site. Next.js calls it Incremental Static Regeneration (ISR). Here is how a Next.js page asks for it (Next.js 16, checked in October 2026; Next.js's newer Cache Components option sets this up differently). A page says how many seconds its HTML stays fresh:

// app/products/[id]/page.jsx in a Next.js app
export const revalidate = 60;

export async function generateStaticParams() {
  const products = await db.products.all();
  return products.map((product) => ({ id: product.id }));
}

export default async function ProductPage({ params }) {
  const { id } = await params;
  const product = await db.products.find(id);
  return <h1>{product.name}: ${product.price}</h1>;
}

Line 2 exports revalidate = 60. Lines 4 to 7 list the pages to build, one per product, like the build script above (db stands for your database code). Lines 9 to 13 are the page: an async component that reads one product from the database. Next.js renders each page, saves the HTML, and sends the saved copy. Once the copy is older than 60 seconds, the next visitor still gets it, and a rebuild starts in the background. Visitors after the rebuild get the new HTML. Nobody waits for a rebuild. Try it: open the page, raise the price, then wait and open the page again.

A price that changes at 20 s shows up only after the first visit after 60 s, and that visit still sees the old price. If a change must show at once, revalidate from the code that makes the change:

"use server";
import { revalidatePath } from "next/cache";

export async function updatePrice(id, price) {
  await db.products.update(id, { price });
  revalidatePath(`/products/${id}`);
}

Line 1 makes this a Server Function, which a form can call (Form actions; a later lesson, Server Functions, covers them). Line 5 saves the price, and line 6 tells Next.js that the saved page for this product is out of date, so the next visitor gets a fresh one.

Streaming: the page in pieces

Server-side rendering waits for all the data before it sends a byte. Streaming sends the page in pieces instead: first everything that's ready, with a Suspense fallback where a slow part goes, then that part when its data arrives. React's renderToReadableStream does it. This demo runs it in the browser and lists each piece of HTML as it arrives:

1import { Suspense, use, useEffect, useState } from "react";2import { renderToReadableStream } from "react-dom/server";3 4const reviews = new Promise((resolve) => {5  setTimeout(() => resolve(["Fresh and light", "Lovely with honey"]), 2000);6});7 8function Reviews() {9  const list = use(reviews);10  return <ul>{list.map((text) => <li key={text}>{text}</li>)}</ul>;11}12 13function ProductPage() {14  return (15    <main>16      <h1>Green tea: $3</h1>17      <Suspense fallback={<p>Loading reviews…</p>}>18        <Reviews />19      </Suspense>20    </main>21  );22}23 24export default function App() {25  const [pieces, setPieces] = useState([]);26 27  useEffect(() => {28    let active = true;29    const start = performance.now();30    renderToReadableStream(<ProductPage />).then(async (stream) => {31      const reader = stream.pipeThrough(new TextDecoderStream()).getReader();32      while (true) {33        const { done, value } = await reader.read();34        if (done || !active) return;35        const ms = Math.round(performance.now() - start);36        setPieces((list) => [...list, { ms, html: value }]);37      }38    });39    return () => {40      active = false;41    };42  }, []);43 44  return (45    <ol>46      {pieces.map((piece, index) => (47        <li key={index}>48          after {piece.ms} ms: <code style={{ wordBreak: "break-all" }}>{piece.html}</code>49        </li>50      ))}51    </ol>52  );53}

Lines 4 to 6 are reviews that take 2 seconds. Line 9 reads them with use, which suspends Reviews until they're ready. Lines 17 to 19 wrap it in Suspense with a fallback. Line 30 starts the stream, and lines 32 to 37 read it piece by piece and add each one, with its time, to the list.

The first piece arrives at once. It holds the heading and Loading reviews…, marked with a <template id="B:0">, plus a small script. About 2 seconds later a second piece arrives: the reviews in a hidden <div id="S:0">, and a script that moves them in place of the fallback. A browser shows the first piece while the server is still loading the reviews. The lesson Streaming server rendering covers how it works and how hydration happens piece by piece.

Server Components, at a glance

So far, every strategy sends the JavaScript for every component, because the browser runs them all again to hydrate. Server Components are components that run only on the server, or at build time. They can read a database directly, and their code is never sent to the browser: only what they rendered is. Components that need state or clicks are marked "use client" and work as before.

// ProductPage.jsx: a Server Component. It runs on the server only.
import { db } from "./db.js";
import AddToCart from "./AddToCart.jsx";

export default async function ProductPage({ id }) {
  const product = await db.products.find(id);
  return (
    <main>
      <h1>{product.name}: ${product.price}</h1>
      <AddToCart id={product.id} />
    </main>
  );
}

// AddToCart.jsx: a Client Component. Its code is sent to the browser.
"use client";
import { useState } from "react";

export default function AddToCart({ id }) {
  const [added, setAdded] = useState(false);
  return <button onClick={() => setAdded(true)}>{added ? "Added" : "Add to cart"}</button>;
}

In ProductPage.jsx, line 5 is an async component, and line 6 reads the product straight from the database: no API, no Effect. Line 10 uses AddToCart. In AddToCart.jsx, line 2, "use client", marks it as a Client Component: its code goes to the browser, and it hydrates. ProductPage's code doesn't.

Server Components need a framework that supports them, like Next.js's App Router, and they usually work together with streaming server rendering for the first HTML. In this lesson's model they send 120 kB of JavaScript instead of 200 kB. The lesson Server Components goes through them properly.

Every strategy on one timeline

A few numbers describe how a page load feels. How to read the table: each row is one number, what it measures, and what makes it smaller.

The playground runs one product page load with each strategy. Pick a strategy and watch its lanes; the table under the lanes compares all six with the same settings. Then press Data: 2000 ms: server rendering gets 1200 ms slower to the first byte, static generation doesn't move, and streaming still shows its shell at 140 ms. Then try Slow connection with Streaming and RSC: less JavaScript means the page responds sooner.

How to read the table: each row is a strategy, what its first HTML holds, how fresh its data is, and what kind of page it suits.

A strategy for each page of a shop

You don't pick one strategy for a whole app. A shop's About page, its product pages, its search and its account pages have different needs, and frameworks let you choose per page (per route). Three questions decide most cases:

1. Is the page the same for everyone? If not, it can't be built ahead of time.
2. How often does it change? Rarely: static. During the day: static with revalidation.
3. Must search engines and link previews read it? If so, send HTML with content: render on the server.

How to read the table: each row is a tool, and the rendering it offers (checked against each project's documentation, October 2026).

React's own docs recommend starting a new app with a framework, and note that the frameworks they recommend can all build static, client-only apps and add server rendering per route later (Setting up a React project). Sort these pages with the three questions:

Common mix-ups

• "Server-side rendering means less JavaScript." No. The browser still downloads every component to hydrate the page. Server Components are what send less.
• "Once the page shows, it works." No. A server-rendered page shows before it's hydrated, and clicks before hydration do nothing.
• "Static means the page can't change." No. The HTML is fixed until the next build or revalidation, but after hydration it's a normal React app with state, clicks and data from the browser.
• "Revalidate = 60 means visitors see changes within 60 seconds." Not quite. The first visit after 60 seconds still gets the old page and starts the rebuild. Without visitors, nothing rebuilds.
• "Client-side rendering is outdated." No. For apps behind a login it's simple, cheap, and fast after the first load. It's a choice, not a mistake.
• "Server Components replace server-side rendering." No. They decide which components run only on the server; streaming server rendering still turns the result into the first HTML.

Practice exercises

Some exercises show their result under the code; the ones that ask you to predict show it when you press Edit & run. Guess first, then check.

import { useEffect, useState } from "react";

function fetchProducts() {
  return new Promise((resolve) => {
    const products = [
      { id: "tea", name: "Green tea", price: 3 },
      { id: "cake", name: "Carrot cake", price: 4 },
    ];
    setTimeout(() => resolve(products), 1500);
  });
}

export default function App() {
  const [products, setProducts] = useState(null);

  useEffect(() => {
    fetchProducts().then(setProducts);
  }, []);

  if (!products) return <p>Loading products…</p>;
  return (
    <ul>
      {products.map((product) => (
        <li key={product.id}>
          {product.name}: ${product.price}
        </li>
      ))}
    </ul>
  );
}

1import { useEffect, useState } from "react";2 3function fetchProducts() {4  return new Promise((resolve) => {5    const products = [6      { id: "tea", name: "Green tea", price: 3 },7      { id: "cake", name: "Carrot cake", price: 4 },8    ];9    setTimeout(() => resolve(products), 1500);10  });11}12 13export default function App() {14  const [products, setProducts] = useState(null);15 16  useEffect(() => {17    fetchProducts().then(setProducts);18  }, []);19 20  if (!products) return <p>Loading products…</p>;21  return (22    <ul>23      {products.map((product) => (24        <li key={product.id}>25          {product.name}: ${product.price}26        </li>27      ))}28    </ul>29  );30}

import { renderToString } from "react-dom/server";

function Price({ amount }) {
  return <strong>{`$${amount}`}</strong>;
}

const html = renderToString(<Price amount={3} />);

export default function App() {
  return <pre>{html}</pre>;
}

1import { renderToString } from "react-dom/server";2 3function Price({ amount }) {4  return <strong>{`$${amount}`}</strong>;5}6 7const html = renderToString(<Price amount={3} />);8 9export default function App() {10  return <pre>{html}</pre>;11}

1import { hydrateRoot } from "react-dom/client";2import { renderToString } from "react-dom/server";3import App from "./App.jsx";4 5const root = document.getElementById("root");6 7// 1. The server's HTML arrives: the page shows, but nothing responds.8root.innerHTML = renderToString(<App />);9 10// 2. Three seconds later the JavaScript has loaded, and React takes over.11setTimeout(() => {12  hydrateRoot(root, <App />);13}, 3000);

1import { hydrateRoot } from "react-dom/client";2import { renderToString } from "react-dom/server";3import App from "./App.jsx";4 5const root = document.getElementById("root");6 7// 1. The server's HTML arrives: the page shows, but nothing responds.8root.innerHTML = renderToString(<App />);9 10// 2. Three seconds later the JavaScript has loaded, and React takes over.11setTimeout(() => {12  hydrateRoot(root, <App />);13}, 3000);

1import { Suspense, use, useEffect, useState } from "react";2import { renderToReadableStream } from "react-dom/server";3 4const reviews = new Promise((resolve) => {5  setTimeout(() => resolve(["Fresh and light", "Lovely with honey"]), 2000);6});7 8function Reviews() {9  const list = use(reviews);10  return <ul>{list.map((text) => <li key={text}>{text}</li>)}</ul>;11}12 13function ProductPage() {14  return (15    <main>16      <h1>Green tea: $3</h1>17      <Reviews />18    </main>19  );20}21 22export default function App() {23  const [pieces, setPieces] = useState([]);24 25  useEffect(() => {26    let active = true;27    const start = performance.now();28    renderToReadableStream(<ProductPage />).then(async (stream) => {29      const reader = stream.pipeThrough(new TextDecoderStream()).getReader();30      while (true) {31        const { done, value } = await reader.read();32        if (done || !active) return;33        const ms = Math.round(performance.now() - start);34        setPieces((list) => [...list, { ms, html: value }]);35      }36    });37    return () => {38      active = false;39    };40  }, []);41 42  return (43    <ol>44      {pieces.map((piece, index) => (45        <li key={index}>46          after {piece.ms} ms: <code style={{ wordBreak: "break-all" }}>{piece.html}</code>47        </li>48      ))}49    </ol>50  );51}

1import { Suspense, use, useEffect, useState } from "react";2import { renderToReadableStream } from "react-dom/server";3 4const reviews = new Promise((resolve) => {5  setTimeout(() => resolve(["Fresh and light", "Lovely with honey"]), 2000);6});7 8function Reviews() {9  const list = use(reviews);10  return <ul>{list.map((text) => <li key={text}>{text}</li>)}</ul>;11}12 13function ProductPage() {14  return (15    <main>16      <h1>Green tea: $3</h1>17      <Suspense fallback={<p>Loading reviews…</p>}>18        <Reviews />19      </Suspense>20    </main>21  );22}23 24export default function App() {25  const [pieces, setPieces] = useState([]);26 27  useEffect(() => {28    let active = true;29    const start = performance.now();30    renderToReadableStream(<ProductPage />).then(async (stream) => {31      const reader = stream.pipeThrough(new TextDecoderStream()).getReader();32      while (true) {33        const { done, value } = await reader.read();34        if (done || !active) return;35        const ms = Math.round(performance.now() - start);36        setPieces((list) => [...list, { ms, html: value }]);37      }38    });39    return () => {40      active = false;41    };42  }, []);43 44  return (45    <ol>46      {pieces.map((piece, index) => (47        <li key={index}>48          after {piece.ms} ms: <code style={{ wordBreak: "break-all" }}>{piece.html}</code>49        </li>50      ))}51    </ol>52  );53}

function chooseStrategy(page) {
  return "CSR";
}

const pages = [
  { name: "About us", sameForEveryone: true, changes: "rarely", needsSearch: true },
  { name: "Product page", sameForEveryone: true, changes: "hourly", needsSearch: true },
  { name: "Order history", sameForEveryone: false, changes: "often", needsSearch: false },
  { name: "Search results", sameForEveryone: false, changes: "often", needsSearch: true },
];

for (const page of pages) console.log(`${page.name}: ${chooseStrategy(page)}`);

function chooseStrategy(page) {
  if (page.sameForEveryone && page.changes === "rarely") return "SSG";
  if (page.sameForEveryone) return "ISR";
  if (page.needsSearch) return "SSR";
  return "CSR";
}

const pages = [
  { name: "About us", sameForEveryone: true, changes: "rarely", needsSearch: true },
  { name: "Product page", sameForEveryone: true, changes: "hourly", needsSearch: true },
  { name: "Order history", sameForEveryone: false, changes: "often", needsSearch: false },
  { name: "Search results", sameForEveryone: false, changes: "often", needsSearch: true },
];

for (const page of pages) console.log(`${page.name}: ${chooseStrategy(page)}`);

const revalidate = 60; // seconds the saved page stays fresh
const rebuild = 2; // seconds a rebuild takes
let saved = { price: 3, builtAt: 0 };
let database = 3;
let rebuilding = null;

function at(time, what) {
  if (rebuilding && rebuilding.doneAt <= time) {
    saved = { price: rebuilding.price, builtAt: rebuilding.doneAt };
    rebuilding = null;
  }
  if (what === "change") {
    database += 1;
    return;
  }
  const stale = time - saved.builtAt >= revalidate;
  if (stale && !rebuilding) rebuilding = { doneAt: time + rebuild, price: database };
  console.log(`${time} s: $${saved.price}${stale ? " (stale)" : ""}`);
}

at(10, "change");
at(50, "visit");
at(65, "visit");
at(66, "visit");
at(70, "visit");

const revalidate = 60; // seconds the saved page stays fresh
const rebuild = 2; // seconds a rebuild takes
let saved = { price: 3, builtAt: 0 };
let database = 3;
let rebuilding = null;

function at(time, what) {
  if (rebuilding && rebuilding.doneAt <= time) {
    saved = { price: rebuilding.price, builtAt: rebuilding.doneAt };
    rebuilding = null;
  }
  if (what === "change") {
    database += 1;
    return;
  }
  const stale = time - saved.builtAt >= revalidate;
  if (stale && !rebuilding) rebuilding = { doneAt: time + rebuild, price: database };
  console.log(`${time} s: $${saved.price}${stale ? " (stale)" : ""}`);
}

at(10, "change");
at(50, "visit");
at(65, "visit");
at(66, "visit");
at(70, "visit");

Check your understanding

For each question, ask where the HTML is made, when, and what the browser has to wait for: the server, the data, or the JavaScript.

Key takeaways

• Client-side rendering sends an empty root; the browser runs the JavaScript, then fetches the data. Simple and cheap, slow to first content.
• Server-side rendering sends the page's HTML for each request. The first byte waits for the data, and the page responds only after hydration.
• Static generation renders at build time, so a CDN sends finished HTML fast; revalidation rebuilds it in the background after a set time.
• Streaming sends the ready parts first and the slow parts later, with Suspense fallbacks in between.
• Server Components run only on the server and send their result, not their code, so the browser downloads less JavaScript.
• Choose per page: same for everyone or not, how often it changes, and whether search engines must read it.

Coming next: Server rendering and hydration. It shows how renderToString and hydrateRoot work together, and how to fix the page when the server and the browser disagree.