react_on_rails_pro 16.2.0.beta.8

data/docs/node-renderer/heroku.md

@@ -0,0 +1,102 @@
+# Heroku Deployment
+
+Most React on Rails Pro installations of the Node SSR Renderer will deploy the Rails and Renderer
+instances on the same server. This technique results in better performance since it avoids network
+latency.
+
+Scroll down if you want to have different servers.
+
+## Deploying to the Same Server As Your App Server
+
+[buildpack for runit](https://github.com/danp/heroku-buildpack-runit)
+
+### Procfile
+
+`/Procfile`
+
+```
+web: bin/runsvdir-dyno
+```
+
+### Procfile.web
+
+`/Procfile.web`
+
+```
+puma: bundle exec puma -C config/puma.rb
+renderer: bin/node-renderer
+```
+
+### bin/node-renderer
+
+```
+#!/bin/bash
+cd client
+yarn run node-renderer
+```
+Be sure your script to run the node-renderer sets some port, like 3800 which is also set as the
+config.renderer_url for your Rails server.
+
+### node-renderer
+Any task in client/package.json that starts the node-renderer
+
+### Modifying Precompile Task
+
+_Not necessary if you are using [bundle caching](../bundle-caching.md) as doing so will result in the below being done automatically._
+
+To avoid the initial round trip to get a bundle on the renderer, you can do something like this to copy the file during precompile.
+
+See [lib/tasks/assets.rake](https://github.com/shakacode/react_on_rails_pro/blob/master/lib/tasks/assets.rake) for a couple tasks that you can use.
+
+If you're using the default tmp/bundles subdirectory for the node-renderer, you don't need to set the
+ENV value for `RENDERER_BUNDLE_PATH`. Otherwise, please set this ENV value so the files get copied
+to the right place.
+
+Then you can use the rake task: `react_on_rails_pro:pre_stage_bundle_for_node_renderer`.
+
+You might do something like this:
+
+```ruby
+Rake::Task["assets:precompile"]
+    .clear_prerequisites
+    .enhance([:environment, "react_on_rails:assets:compile_environment"])
+    .enhance do
+  Rake::Task["react_on_rails_pro:pre_stage_bundle_for_node_renderer"].invoke
+end
+```
+
+## Troubleshooting
+
+If you get this sort of error, then you're forgetting to configure the PORT on the node-renderer and
+setting the config.renderer_url on the Rails App.
+
+```
+bundler: failed to load command: puma (/app/vendor/bundle/ruby/2.6.0/bin/puma)
+Errno::EADDRINUSE: Address already in use - bind(2) for "0.0.0.0" port 21752
+  /app/vendor/bundle/ruby/2.6.0/gems/puma-4.3.3/lib/puma/binder.rb:229:in `initialize'
+```
+
+
+## Separate Rails and Node Render Instances
+
+### Deploy Node renderer to Heroku
+
+1. Create your **Heroku** app with **Node.js** buildpack, say `renderer-test.herokuapp.com`.
+2. In your JS configuration file or
+   1. If setting the port, ensure the port uses `process.env.PORT` so it will use port number provided by **Heroku** environment. The default is to use the env value RENDERER_PORT if available. (*TODO: Need to check on this*)
+   2. Set password in your configuration to something like `process.env.RENDERER_PASSWORD` and configure the corresponding **ENV variable** on your **Heroku** dyno so the `config/initializers/react_on_rails_pro.rb` uses this value.
+3. Run deployment process (usually by pushing changes to **Git** repo associated with created **Heroku** app).
+4. Once deployment process is finished, renderer should start listening from something like `renderer-test.herokuapp.com` host.
+
+### Deploy react_on_rails application to Heroku
+
+1. Create your **Heroku** app for `react_on_rails`.
+2. Configure your app to communicate with renderer app you've created above. Put the following to your `initializers/react_on_rails_pro` (assuming you have **SSL** certificate uploaded to your renderer **Heroku** app or you use **Heroku** wildcard certificate under `*.herokuapp.com`) and configure corresponding **ENV variable** for the render_url and/or password on your **Heroku** dyno.
+3. Run deployment process (usually by pushing changes to **Git** repo associated with created **Heroku** app).
+4. Once deployment process is finished, all rendering requests form your `react_on_rails` app should be served by `<your-heroku-app>.herokuapp.com` app via **HTTPS**.
+
+
+
+## References
+
+* [Heroku Node Settings](https://github.com/damianmr/heroku-node-settings)

data/docs/node-renderer/js-configuration.md

@@ -0,0 +1,91 @@
+# Node Renderer JavaScript Configuration
+
+You can configure the node-renderer with only ENV values using the provided bin file `node-renderer`.
+
+You can also create a custom configuration file to setup and launch the node-renderer.
+
+The values in this file must be kept in sync with with the `config/initializers/react_on_rails_pro.rb` file, as documented in [Configuration](../configuration.md).
+
+Here are the options available for the JavaScript renderer configuration object, as well as the available default ENV values if using the command line program node-renderer.
+
+[//]: # 'If you change text here, you may want to update comments in packages/node-renderer/src/shared/configBuilder.ts as well.'
+
+1. **port** (default: `process.env.RENDERER_PORT || 3800`) - The port the renderer should listen to.
+   [On Heroku](https://devcenter.heroku.com/articles/dyno-startup-behavior#port-binding-of-web-dynos) or [ControlPlane](https://docs.controlplane.com/reference/workload/containers#port-variable) you may want to use `process.env.PORT`.
+1. **logLevel** (default: `process.env.RENDERER_LOG_LEVEL || 'info'`) - The renderer log level. Set it to `silent` to turn logging off.
+   [Available levels](https://getpino.io/#/docs/api?id=levels): `{ fatal: 60, error: 50, warn: 40, info: 30, debug: 20, trace: 10 }`. `silent` can be used as well.
+1. **logHttpLevel** (default: `process.env.RENDERER_LOG_HTTP_LEVEL || 'error'`) - The HTTP server log level (same allowed values as `logLevel`).
+1. **fastifyServerOptions** (default: `{}`) - Additional options to pass to the Fastify server factory. See [Fastify documentation](https://fastify.dev/docs/latest/Reference/Server/#factory).
+1. **serverBundleCachePath** (default: `process.env.RENDERER_SERVER_BUNDLE_CACHE_PATH || process.env.RENDERER_BUNDLE_PATH || '/tmp/react-on-rails-pro-node-renderer-bundles'` ) - Path to a cache directory where uploaded server bundle files will be stored. This is distinct from Shakapacker's public asset directory. For example you can set it to `path.resolve(__dirname, './.node-renderer-bundles')` if you configured renderer from the `/` directory of your app.
+1. **workersCount** (default: `process.env.RENDERER_WORKERS_COUNT || defaultWorkersCount()` where default is your CPUs count - 1) - Number of workers that will be forked to serve rendering requests. If you set this manually make sure that value is a **Number** and is `>= 0`. Setting this to `0` will run the renderer in a single process mode without forking any workers, which is useful for debugging purposes. For production use, the value should be `>= 1`.
+1. **password** (default: `env.RENDERER_PASSWORD`) - The password expected to receive from the **Rails client** to authenticate rendering requests.
+   If no password is set, no authentication will be required.
+1. **allWorkersRestartInterval** (default: `env.RENDERER_ALL_WORKERS_RESTART_INTERVAL`) - Interval in minutes between scheduled restarts of all workers. By default restarts are not enabled. If restarts are enabled, `delayBetweenIndividualWorkerRestarts` should also be set.
+1. **delayBetweenIndividualWorkerRestarts** (default: `env.RENDERER_DELAY_BETWEEN_INDIVIDUAL_WORKER_RESTARTS`) - Interval in minutes between individual worker restarts (when cluster restart is triggered). By default restarts are not enabled. If restarts are enabled, `allWorkersRestartInterval` should also be set.
+1. **gracefulWorkerRestartTimeout**: (default: `env.GRACEFUL_WORKER_RESTART_TIMEOUT`) - Time in seconds that the master waits for a worker to gracefully restart (after serving all active requests) before killing it. Use this when you want to avoid situations where a worker gets stuck in an infinite loop and never restarts. This config is only usable if worker restart is enabled. The timeout starts when the worker should restart; if it elapses without a restart, the worker is killed.
+1. **maxDebugSnippetLength** (default: 1000) - If the rendering request is longer than this, it will be truncated in exception and logging messages.
+1. **supportModules** - (default: `env.RENDERER_SUPPORT_MODULES || null`) - If set to true, `supportModules` enables the server-bundle code to call a default set of NodeJS global objects and functions that get added to the VM context:
+   `{ Buffer, TextDecoder, TextEncoder, URLSearchParams, ReadableStream, process, setTimeout, setInterval, setImmediate, clearTimeout, clearInterval, clearImmediate, queueMicrotask }`.
+   This option is required to equal `true` if you want to use loadable components.
+   Setting this value to false causes the NodeRenderer to behave like ExecJS.
+   See also `stubTimers`.
+1. **additionalContext** - (default: `null`) - additionalContext enables you to specify additional NodeJS objects (usually from https://nodejs.org/api/globals.html) to add to the VM context in addition to our `supportModules` defaults.
+   Object shorthand notation may be used, but is not required.
+   Example: `{ URL, Crypto }`
+1. **stubTimers** - (default: `env.RENDERER_STUB_TIMERS` if that environment variable is set, `true` otherwise) - With this option set, use of functions `setTimeout`, `setInterval`, `setImmediate`, `clearTimeout`, `clearInterval`, `clearImmediate`, and `queueMicrotask` will do nothing during server-rendering.
+   This is useful when using dependencies like [react-virtuoso](https://github.com/petyosi/react-virtuoso) that use these functions during hydration.
+   In RORP, hydration typically is synchronous and single-task (unless you use streaming) and thus callbacks passed to task-scheduling functions should never run during server-side rendering.
+   Because these functions are valid client-side, they are ignored on server-side rendering without errors or warnings.
+   See also `supportModules`.
+
+Deprecated options:
+
+1. **bundlePath** - Renamed to `serverBundleCachePath`. The old name will continue to work but will log a deprecation warning.
+1. **honeybadgerApiKey**, **sentryDsn**, **sentryTracing**, **sentryTracesSampleRate** - Deprecated and have no effect.
+   If you have any of them set, see [Error Reporting and Tracing](./error-reporting-and-tracing.md) for the new way to set up error reporting and tracing.
+1. **includeTimerPolyfills** - Renamed to `stubTimers`.
+
+## Example Launch Files
+
+### Testing example:
+
+[spec/dummy/client/node-renderer.js](https://github.com/shakacode/react_on_rails_pro/blob/master/spec/dummy/client/node-renderer.js)
+
+### Simple example:
+
+Create a file './node-renderer.js'
+
+```js
+import path from 'path';
+import { reactOnRailsProNodeRenderer } from 'react-on-rails-pro-node-renderer';
+
+const config = {
+  // Save bundles to relative "./.node-renderer-bundles" dir of our app
+  serverBundleCachePath: path.resolve(__dirname, './.node-renderer-bundles'),
+
+  // All other values are the defaults, as described above
+};
+
+// For debugging, run in single process mode
+if (process.env.NODE_ENV === 'development') {
+  config.workersCount = 0;
+}
+// Renderer detects a total number of CPUs on virtual hostings like Heroku or CircleCI instead
+// of CPUs number allocated for current container. This results in spawning many workers while
+// only 1-2 of them really needed.
+else if (process.env.CI) {
+  config.workersCount = 2;
+}
+
+reactOnRailsProNodeRenderer(config);
+```
+
+And add this line to your `scripts` section of `package.json`
+
+```json
+  "scripts": {
+    "start": "echo 'Starting React on Rails Pro Node Renderer.' && node ./node-renderer.js"
+  },
+```
+
+`yarn start` will run the renderer.

data/docs/node-renderer/troubleshooting.md

@@ -0,0 +1,5 @@
+# Node Renderer Troubleshooting
+
+- If you enabled restarts (having `allWorkersRestartInterval` and `delayBetweenIndividualWorkerRestarts`), you should set it with a high number to avoid the app from crashing because all Node renderer workers are stopped/killed.
+
+- If your app contains streamed pages that take too much time to be streamed to the client, ensure to not set the `gracefulWorkerRestartTimeout` parameter or set to a high number, so the worker is not killed while it's still serving an active request.

data/docs/profiling-server-side-rendering-code.md

@@ -0,0 +1,179 @@
+# Profiling Server-Side Renderer In RORP
+
+This guide helps you profile the server-side code running in RORP node-renderer. It may help you find slow parts or bottlenecks in code.
+
+This guide uses the RORP dummy app in profiling the server-side code.
+
+## Profiling Server-Side Code Running On Node Renderer
+
+1. Run node-renderer using the `--inspect` node option.
+    
+    Open the `spec/dummy/Procfile.dev` file and update the `node-renderer` process to run the renderer using `node --inspect` command. Change the following line
+    
+    ```bash
+    node-renderer: RENDERER_LOG_LEVEL=debug yarn run node-renderer
+    ```
+    
+    To
+    
+    ```bash
+    node-renderer: RENDERER_LOG_LEVEL=debug RENDERER_PORT=3800 node --inspect client/node-renderer.js
+    ```
+
+1. Run the App
+    
+    ```bash
+    bin/dev
+    ```
+
+1. Visit `chrome://inspect` on Chrome browser and you should see something like this:
+    
+    ![Chrome Inspect Tab](https://github.com/shakacode/react_on_rails_pro/assets/7099193/2a64660f-9381-4bbb-b385-318aa833389d)
+
+1. Click the `inspect` link. This should open a developer tools window. Open the performance tab there
+    
+    ![Chrome Performance Tab](https://github.com/shakacode/react_on_rails_pro/assets/7099193/ddf572bd-182f-4911-bb8f-4bafa4ec1034)
+
+1. Click the `record` button
+    
+    ![Chrome Performance Tab](https://github.com/shakacode/react_on_rails_pro/assets/7099193/20848091-d446-4690-988b-09db59ddf9e0)
+
+1. Open the web app you want to test and refresh it multiple times. We use the React on Rails Pro dummy app for this tutorial. So, we will open it in the browser by going to [http://localhost:3000](http://localhost:3000)
+    
+    ![RORP Dummy App](https://github.com/shakacode/react_on_rails_pro/assets/7099193/8dc1ef3d-62e4-492d-a5b4-c693b7f7e08c)
+
+1. If you get any `Timeout Error` while visiting the page, you may need to increase the `ssr_timeout` in the Ruby on Rails initializer file. **Running node-renderer** using the `--inspect` flag makes it slower. So, you can increase the `ssr_timeout` to `10 seconds` by adding the following line to `config/initializers/react_on_rails_pro.rb` file
+    
+    ```ruby
+    config.ssr_timeout = 10
+    ```
+
+1. Stop performance recording
+    
+    ![Running profiler at the performance tab](https://github.com/shakacode/react_on_rails_pro/assets/7099193/bc02bbd6-3358-4edf-ba3a-36e11620a096)
+
+1. You should see something like this
+   
+   ![Recorded Node JS profile](https://github.com/shakacode/react_on_rails_pro/assets/7099193/6dc098bb-9f07-49be-9a1f-2149f6712631)
+
+## Profile Analysis
+
+You can see that there is much work done during the first request because it contains the process of uploading the component bundles and executing the server-side bundle code.
+
+![Recorded Node JS profile](https://github.com/shakacode/react_on_rails_pro/assets/7099193/9ff91973-7190-465b-9750-c99d95f16711)
+
+By zooming into it, you can see the function that’s called `buildVM` (you can also search for it by clicking Ctrl+f and type the function name)
+
+![NodeJS startup code profile](https://github.com/shakacode/react_on_rails_pro/assets/7099193/e16d2028-83a2-43e6-a2ca-c788873dd88c)
+
+All code that runs later inside that code context calls the `runInContext` function. Like this code that calls `renderToString` to render a specific react component
+
+![runInContext function profile](https://github.com/shakacode/react_on_rails_pro/assets/7099193/a50f76de-83aa-4af7-8eb2-2941f419f4aa)
+
+To check the profile of other requests, zoom into any of the following spots of work
+
+![Recorded Node JS profile](https://github.com/shakacode/react_on_rails_pro/assets/7099193/6bfff9bf-375a-4ba8-817e-81509821e8df)
+
+You should find a call to `serverRenderReactComponent`
+
+![serverRenderReactComponent function profile](https://github.com/shakacode/react_on_rails_pro/assets/7099193/6b2014e2-db85-4ba5-9dfc-2600cc863e98)
+
+**If you can’t find any requests coming to the renderer server, component caching may be the cause.** You can try to disable React on Rails caching by adding the following line to `config/initializers/react_on_rails_pro.rb` file
+
+```ruby
+config.prerender_caching = false
+```
+
+## Profiling Renderer With High Loads
+
+To see the renderer behavior while there are many requests coming to it, you can use the `ApacheBench (ab)` tool that lets you make many HTTP requests to a specific end points at the same time.
+
+1. The `ApacheBench (ab)` is installed on macOS by default. You can install it on Linux by running the following command
+    
+    ```bash
+    sudo apt-get install apache2-utils 
+    ```
+
+1. Do all steps in `Profiling Server-Side Code Running On Node Renderer` section except the step number 6. Instead of opening the page in the browser, let the `ab` tool make many HTTP requests for you by running the following command.
+    
+    ```bash
+    ab -n 100 -c 10 http://localhost:3000/
+    ```
+
+1. Now, we you open the noder-renderer profile, you will see it very busy responding to all requests
+    
+    ![Busy renderer profile](https://github.com/shakacode/react_on_rails_pro/assets/7099193/2ce69bf2-45ee-4a9d-af33-37e20aed86bc)
+
+1. Then, you can analyze the renderer behavior of each request as stated in `Profile Analysis` section.
+
+### ExecJS
+React on Rails Pro supports profiling with ExecJS starting from version **4.0.0**. You will need to do more work to profile ExecJS if you are using an older version.
+
+If you are using **v4.0.0** or later, you can enable the profiler by setting the `profile_server_rendering_js_code` config by adding the following line to the ReactOnRails initializer.
+
+```ruby
+config.profile_server_rendering_js_code = true
+```
+
+Then, run the app you are profiling and open some pages in it.
+You will find many log files with the name `isloate-0x*.log` in the root of your app. You can use the following command to analyze the log files.
+
+```bash
+rake react_on_rails_pro:process_v8_logs
+```
+
+You will find all log files are converted to `profile.v8log.json` file and moved to the **v8_profiles** directory.
+
+You can use `speedscope` to analyze the `profile.v8log.json` file. You can install `speedscope` by running the following command
+
+```bash
+npm install -g speedscope
+```
+
+Then, you can analyze the profile by running the following command
+
+```bash
+speedscope /path/to/profile.v8log.json
+```
+
+### Profiling ExecJS with Older Versions of React on Rails Pro
+
+If you are using an older version of React on Rails Pro, you need to do more work to profile the server-side code running in the ExecJS.
+
+If you are using `node` as the runtime for ExecJS, you can enable the profiler by adding the following code on top of the `ReactOnRailsPro` initializer.
+
+```ruby
+class CustomRuntime < ExecJS::ExternalRuntime
+  def initialize
+    super(
+      name: 'Custom Node.js (with --prof)',
+      command: ['node --prof'],
+      runner_path: ExecJS.root + '/support/node_runner.js'
+    )
+  end
+end
+
+ExecJS.runtime = CustomRuntime.new
+```
+
+If you are using V8 as the runtime for ExecJS, you can enable the profiler by adding the following code on top of the `ReactOnRailsPro` initializer.
+
+```ruby
+class CustomRuntime < ExecJS::ExternalRuntime
+  def initialize
+    super(
+      name: 'Custom V8 (with --prof)',
+      command: ['d8 --prof'],
+      runner_path: ExecJS.root + '/support/v8_runner.js'
+    )
+  end
+end
+```
+
+After adding the code, you can run the app and open some pages in it. You will find many log files with the name `isloate-0x*.log` in the root of your app. You can use the following command to analyze any log file.
+
+```bash
+node --prof-process --preprocess -j isolate*.log > profile.v8log.json
+npm install -g speedscope
+speedscope /path/to/profile.v8log.json
+```

data/docs/react-server-components/add-streaming-and-interactivity.md

@@ -0,0 +1,190 @@
+# Add Streaming and Interactivity to RSC Page
+
+Before reading this document, please read the [Create React Server Component without SSR](./create-without-ssr.md) document.
+
+## Make the React Server Component Page Progressively Load
+React Server Components support progressive loading, which means they can be built as asynchronous functions that resolve and render after the initial HTML is sent to the client. This enables a better user experience by:
+
+1. Showing initial content quickly while async data loads;
+2. Maintaining interactivity while loading;
+3. Streaming updates to the page as server components resolve.
+
+This progressive enhancement approach allows React Server Components to efficiently handle data fetching and rendering without blocking the initial page load.
+
+Let's create an `async` React Server Component that will be progressively loaded.
+
+```js
+// app/javascript/components/Posts.jsx
+import React from 'react';
+import fetch from 'node-fetch';
+import _ from 'lodash';
+import moment from 'moment';
+
+const Posts = async () => {
+  // Add artificial delay to simulate network latency
+  await new Promise((resolve) => setTimeout(resolve, 1000));
+
+  const posts = await (await fetch(`http://localhost:3000/api/posts`)).json();
+  const postsByUser = _.groupBy(posts, 'user_id');
+  const onePostPerUser = _.map(postsByUser, (group) => group[0]);
+
+  return (
+    <div>
+      {onePostPerUser.map((post) => (
+        <div style={{ border: '1px solid black', margin: '10px', padding: '10px' }}>
+          <h1>{post.title}</h1>
+          <p>{post.body}</p>
+          <p>
+            Created <span style={{ fontWeight: 'bold' }}>{moment(post.created_at).fromNow()}</span>
+          </p>
+          <img src="https://placehold.co/200" alt={post.title} />
+        </div>
+      ))}
+    </div>
+  );
+};
+
+export default Posts;
+```
+
+The async `Posts` component fetches and displays a list of posts, showing one post per user with title, body, timestamp and thumbnail image.
+
+Let's add the Posts component to the React Server Component Page.
+
+```js
+// app/javascript/packs/components/ReactServerComponentPage.jsx
+import React from 'react';
+import ReactServerComponent from '../../components/ReactServerComponent';
+import Posts from '../../components/Posts';
+
+const ReactServerComponentPage = () => {
+  return (
+    <div>
+      <ReactServerComponent />
+      <Suspense fallback={<div>Loading...</div>}>
+        <Posts />
+      </Suspense>
+    </div>
+  );
+};
+
+export default ReactServerComponentPage;
+```
+
+The `Suspense` component is used to wrap the Posts component to handle its loading state. The `fallback` prop is used to display a loading message while the Posts component is loading.
+
+## Run the Development Server
+
+Run the development server:
+
+```bash
+bin/dev
+```
+
+Navigate to the React Server Component Page:
+
+```
+http://localhost:3000/react_server_component_without_ssr
+```
+
+When you open the page, you'll see the React Server Component render immediately, followed by the "Loading..." fallback state from the Suspense component. After a 1-second delay, the Posts component will render with the fetched data. This artificial delay helps demonstrate how React Server Components handle asynchronous operations and streaming:
+
+1. The page loads instantly with the ReactServerComponent.
+2. The Suspense fallback shows "Loading..." where the Posts will appear.
+3. After the delay, the Posts component streams in and replaces "Loading...".
+
+## How The Streaming Works
+
+The streaming happens through the `rsc_payload/ReactServerComponentPage` fetch request that React on Rails Pro initiates when loading the page. The server keeps this connection open and sends data in chunks:
+
+1. The initial chunk contains the immediately available content (ReactServerComponent).
+2. When the Posts component's async operation completes, the server sends another chunk with its rendered content.
+3. The browser progressively receives and renders these chunks, updating the page seamlessly.
+
+This streaming approach means users see content as soon as it's ready, rather than waiting for everything to load before seeing anything. The `Suspense` boundary ensures a smooth transition between the loading state and the final content.
+
+You can observe this streaming behavior in your browser's network tab: the `rsc/ReactServerComponentPage` request will show multiple chunks arriving over time, each one adding more content to your page.
+
+## Add Interactivity
+
+Let's add interactivity to the Posts component. Only client components can be interactive, so we'll create a new client component that helps us to show or hide the post image and call it `ToggleContainer`. It can receive any component as a child and toggle the visibility of the child component.
+
+```js
+// app/javascript/components/ToggleContainer.jsx
+'use client';
+
+import React, { useState } from 'react';
+
+const ToggleContainer = ({ children }) => {
+  const [isVisible, setIsVisible] = useState(false);
+
+  return (
+    <div>
+      <button onClick={() => setIsVisible((prev) => !prev)}>Toggle</button>
+      {isVisible && children}
+    </div>
+  );
+};
+
+export default ToggleContainer;
+```
+
+Now, let's use the `ToggleContainer` component to wrap the post image.
+
+```js
+// app/javascript/components/Posts.jsx
+import ToggleContainer from './ToggleContainer';
+
+const Posts = () => {
+  // existing code..
+
+  return (
+    <div>
+      {onePostPerUser.map((post) => (
+        <div>
+          {/* existing code.. */}
+          <ToggleContainer>
+            <img src="https://placehold.co/200" alt={post.title} />
+          </ToggleContainer>
+        </div>
+      ))}
+    </div>
+  );
+};
+
+export default Posts;
+```
+
+Now when you visit the page, you'll see a "Toggle" button for each post. Clicking the button will show/hide that post's image. This demonstrates how we can add client-side interactivity to a React Server Component by creating a client component (`ToggleContainer`) that manages its own state.
+
+The `ToggleContainer` is marked with [`'use client'`](https://react.dev/reference/rsc/use-client) directive, indicating it runs on the client-side and can handle user interactions. It uses the `useState` hook to maintain the visibility state of its children. Meanwhile, the parent `Posts` component remains a server component, fetching and rendering the initial posts data on the server.
+
+It's important to note that while client components (like `ToggleContainer`) cannot directly import server components, they can receive server components as props (like children in this case). This is why we can pass the server-rendered image element as a child to our client-side `ToggleContainer` component. This pattern allows for flexible composition while maintaining the boundaries between server and client code.
+
+This pattern allows us to optimize performance by keeping most of the component logic on the server while selectively adding interactivity where needed on the client.
+
+
+## Checking The Network Requests
+
+Let's check what bundles are being loaded for this page. By opening the browser's developer tools and going to the "Network" tab, you can see JavaScript bundles being loaded for this page.
+
+![image](https://github.com/user-attachments/assets/369e4f76-7d1a-4545-a354-3cbecba35fcc)
+
+Looking at the network requests, you'll notice two key JavaScript bundles:
+
+1. The original `ReactServerComponentPage.js` bundle (1.4KB) - This contains the core server component code.
+2. A new `client25.js` (can be different for you) bundle - This contains the client-side interactive code, specifically the `ToggleContainer` component and React hooks like `useState`.
+
+The browser automatically knows to load this additional client bundle because of how React Server Components work:
+
+1. When the server renders the RSC tree, it includes references to any client components used (in this case, `ToggleContainer`).
+2. These references point to the specific JavaScript chunks needed to hydrate those client components.
+3. The React runtime on the client then ensures those chunks are loaded before hydrating the interactive parts of the page.
+
+This demonstrates one of the key benefits of React Server Components - automatic code splitting and loading of just the client-side JavaScript needed for interactivity, while keeping the bulk of the application logic on the server.
+
+For more details on this architecture, see React's [Server Components documentation](https://react.dev/learn/thinking-in-react#how-react-server-components-work).
+
+## Next Steps
+
+Now that you understand how to add streaming and interactivity to React Server Components, you can proceed to the next article: [SSR React Server Components](./server-side-rendering.md) to learn how to enable server-side rendering (SSR) for your React Server Components.