Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for RSC #1644

Merged
merged 105 commits into from
Mar 7, 2025
Merged

Conversation

AbanoubGhadban
Copy link
Collaborator

@AbanoubGhadban AbanoubGhadban commented Jul 22, 2024

Summary

RSC_in_RORP.mp4

Remove this paragraph and provide a general description of the code changes in your pull
request... were there any bugs you had fixed? If so, mention them. If
these bugs have open GitHub issues, be sure to tag them here as well,
to keep the conversation linked together.

Pull Request checklist

Remove this line after checking all the items here. If the item is not applicable to the PR, both check it out and wrap it by ~.

  • Add/update test to cover these changes
  • Update documentation
  • Update CHANGELOG file
    Add the CHANGELOG entry at the top of the file.

Other Information

Remove this paragraph and mention any other important and relevant information such as benchmarks.


This change is Reviewable

Summary by CodeRabbit

  • New Features

    • Introduced support for React Server Components (RSC), allowing dynamic component registration and improved hydration.
    • Added asynchronous APIs for dynamic component and store retrieval, reducing initial load times.
    • Enhanced asset management and page lifecycle handling, improving integration with Turbo/Turbolinks.
    • Introduced new methods for managing stores and components in the ReactOnRails API.
    • Added new configuration options for improved handling of React client manifests and server components.
  • Breaking Changes

    • Updated default hydration behavior to load components immediately with force-loading enabled.
    • Modified core API signatures to support asynchronous operations, affecting page load functions.
    • Changed the default behavior of the force_load configuration to true.
    • Updated the default value of defer_generated_component_packs from true to false.
  • Documentation

    • Revised guides and API docs to reflect the new streaming features and updated configuration defaults.

Copy link
Contributor

coderabbitai bot commented Jul 22, 2024

Walkthrough

The commit introduces comprehensive updates across the project to improve React Server Components and Redux store management. New helper methods now handle NDJSON streaming using fibers, and additional configuration options and TypeScript types support asynchronous store/component registration. Asset resolution, webpack bundle handling, and client/server component registration have been refactored. Several tests, build configurations, and documentation files have been updated accordingly to reflect the new streaming, error management, and lifecycle handling functionality.

Changes

File(s) Change Summary
lib/react_on_rails/
helper.rb, react_component/render_options.rb, configuration.rb, ruby_embedded_java_script.rb
Added/updated helper methods for React Server Components streaming (e.g. rsc_payload_react_component, run_stream_inside_fiber), and enhanced Redux store methods with additional options.
lib/react_on_rails/
utils.rb, packer_utils.rb, packs_generator.rb, test_helper/webpack_assets_status_checker.rb
Refactored asset path resolution, introduced methods for determining development server URLs and client manifest paths, and improved webpack-generated file handling.
node_package/src/ (e.g. ReactOnRailsRSC.ts, types/index.ts, CallbackRegistry.ts, ClientSideRenderer.ts, ComponentRegistry.ts, StoreRegistry.ts, context.ts, loadReactClientManifest.ts, streamServerRenderedReactComponent.ts, transformRSCStreamAndReplayConsoleLogs.ts, utils.ts, registerServerComponent/client.ts, registerServerComponent/server.ts, ReactOnRails.client.ts) Implemented new streaming rendering strategies and client/server component registration for RSC, introduced asynchronous retrieval methods for stores and components, and expanded TypeScript type definitions.
Tests & Configuration
(files in spec/, node_package/tests/, jest.config.js, tsconfig.json, knip.ts, script/convert)
Enhanced test suites with new shared contexts and helpers; updated configuration and build files to support new streaming and registration features.
Docs & Changelog
(docs/api/javascript-api.md, docs/guides/streaming-server-rendering.md, CHANGELOG.md)
Updated documentation and changelog to reflect API changes, including new React Server Components support and revised default behaviors (e.g. force_load now defaults to true).

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant ReactOnRailsHelper
    participant Fiber
    participant Renderer
    Client->>ReactOnRailsHelper: rsc_payload_react_component(component, options)
    ReactOnRailsHelper->>Fiber: run_stream_inside_fiber (initialize streaming)
    Fiber->>Renderer: Generate NDJSON chunks (html, metadata)
    Renderer-->>Fiber: Return streaming data chunks
    Fiber-->>ReactOnRailsHelper: Yield streaming output
    ReactOnRailsHelper-->>Client: Return NDJSON stream
Loading
sequenceDiagram
    participant Browser
    participant ClientStartup
    participant Renderer
    Browser->>ClientStartup: onPageLoaded event
    ClientStartup->>Renderer: renderOrHydrateForceLoadedComponents()
    Renderer-->>ClientStartup: Components hydrated
    ClientStartup-->>Browser: Components rendered successfully
Loading

Possibly related PRs

  • Reduce bundle size #1697: The changes in the main PR, which enhance the handling of React Server Components and Redux store management, are related to the modifications in the retrieved PR that involve the separation of client and server exports, as both address the structure and functionality of server-side rendering in the ReactOnRails module.
  • Refactor serverRenderReactComponent function #1653: The changes in the main PR, which enhance the handling of React Server Components and Redux store management, are related to the modifications in the retrieved PR that refactor the serverRenderReactComponent function, as both involve improvements to server-side rendering logic and component management.
  • Add support for console replay while streaming component #1647: The changes in the main PR, particularly the enhancements to the ReactOnRails::Helper module for handling React Server Components and streaming, are directly related to the modifications in the retrieved PR, which also focuses on streaming server-rendered components and includes the streamServerRenderedReactComponent function.

Suggested reviewers

  • Judahmeek
  • justin808

Poem

Hoppity, hoppity, code leaps with delight,
Streaming like carrots in the cool moonlight.
Fibers spin magic in every byte,
As React and Rails make futures bright.
With a twitch of my nose and joyful cheer,
This rabbit sings the PR’s code so dear! 🐰✨


🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Outside diff range, codebase verification and nitpick comments (4)
spec/dummy/config/webpack/alias.js (1)

7-7: Add a comment explaining the alias mapping.

Adding a comment to explain why the stream alias is needed would improve maintainability.

+      // Alias for stream module to ensure compatibility with browser environments
       stream: 'stream-browserify'
spec/dummy/config/webpack/webpackConfig.js (1)

7-7: Add a comment explaining the fallback configuration.

Adding a comment to explain why the stream fallback is needed would improve maintainability.

+  // Fallback configuration for stream module to ensure compatibility with browser environments
   clientConfig.resolve.fallback = { stream: require.resolve('stream-browserify') };
node_package/src/ReactOnRailsRSC.ts (2)

13-20: Handle the absence of AsyncLocalStorage more robustly.

Consider providing more details in the log message or handling the absence of AsyncLocalStorage in a way that informs the user of potential limitations.

-    console.log('AsyncLocalStorage not found');
+    console.warn('AsyncLocalStorage not found. Some features may not work as expected.');

29-76: Ensure comprehensive test coverage for serverRenderRSCReactComponent.

Given the complexity of this function, ensure that it is comprehensively tested, especially for error handling and edge cases.

  • No references to serverRenderRSCReactComponent were found in the existing test files.
Analysis chain

Ensure comprehensive test coverage for serverRenderRSCReactComponent.

Given the complexity of this function, ensure that it is comprehensively tested, especially for error handling and edge cases.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify if comprehensive tests are provided for `serverRenderRSCReactComponent`.

# Test: Search for test cases related to `serverRenderRSCReactComponent`. Expect: Comprehensive test cases.
rg --type javascript --type typescript 'serverRenderRSCReactComponent'

Length of output: 105


Script:

#!/bin/bash
# Description: Verify if comprehensive tests are provided for `serverRenderRSCReactComponent`.

# Test: Search for test cases related to `serverRenderRSCReactComponent`. Expect: Comprehensive test cases.
rg --type js --type ts 'serverRenderRSCReactComponent'

Length of output: 488


Script:

#!/bin/bash
# Description: Verify if comprehensive tests are provided for `serverRenderRSCReactComponent`.

# Step 1: Find all test files in the repository.
test_files=$(fd --type f --extension js --extension ts --glob '*test*')

# Step 2: Search for references to `serverRenderRSCReactComponent` in the identified test files.
if [ -n "$test_files" ]; then
  rg 'serverRenderRSCReactComponent' $test_files
else
  echo "No test files found."
fi

Length of output: 1289

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 7f01c2a and 4e3ad5b.

Files ignored due to path filters (2)
  • Gemfile.lock is excluded by !**/*.lock
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
Files selected for processing (11)
  • lib/react_on_rails/helper.rb (4 hunks)
  • lib/react_on_rails/react_component/render_options.rb (1 hunks)
  • lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (1 hunks)
  • lib/react_on_rails/utils.rb (2 hunks)
  • node_package/src/ReactOnRails.ts (2 hunks)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
  • node_package/src/serverRenderReactComponent.ts (4 hunks)
  • node_package/src/types/index.ts (2 hunks)
  • package.json (3 hunks)
  • spec/dummy/config/webpack/alias.js (1 hunks)
  • spec/dummy/config/webpack/webpackConfig.js (1 hunks)
Additional comments not posted (26)
node_package/src/ReactOnRailsRSC.ts (3)

22-27: LGTM!

The stringToStream function is correctly implemented.


78-79: LGTM!

The export statements are correctly implemented.


1-4: Ensure type definitions are added for the modules.

The @ts-expect-error comments indicate that type definitions are pending. Ensure these are added to avoid type errors.

Verification successful

Ensure type definitions are added for the modules.

The @ts-expect-error comments indicate that type definitions are pending for the renderToReadableStream and PassThrough modules. Ensure these are added to avoid type errors.

  • node_package/src/ReactOnRailsRSC.ts
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify if type definitions for the modules are added or tracked in the codebase.

# Test: Search for type definition files or TODO comments. Expect: Type definitions or tracking comments.
rg --type typescript -A 2 '@ts-expect-error'

Length of output: 79


Script:

#!/bin/bash
# Description: Verify if type definitions for the modules are added or tracked in the codebase.

# Test: Search for type definition files or TODO comments. Expect: Type definitions or tracking comments.
rg --type-add 'ts:*.ts' -A 2 '@ts-expect-error'

Length of output: 883

package.json (5)

23-23: LGTM!

Updating @types/react to ^18.2.0 ensures better type safety and compatibility with the latest React version.


24-24: LGTM!

Updating @types/react-dom to ^18.2.0 ensures better type safety and compatibility with the latest React version.


49-49: LGTM! Verify the usage of the new dependency.

Adding react-server-dom-webpack enhances server-side rendering capabilities.

However, ensure that the new dependency is correctly utilized in the codebase.

Verification successful

Verified Usage of react-server-dom-webpack

The react-server-dom-webpack dependency is correctly utilized in the codebase, specifically in node_package/src/ReactOnRailsRSC.ts.

  • node_package/src/ReactOnRailsRSC.ts: Import and usage of renderToReadableStream from react-server-dom-webpack/server.edge.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the new dependency in the codebase.

# Test: Search for the usage of `react-server-dom-webpack`. Expect: Correct usage of the new dependency.
rg --type js -A 5 $'react-server-dom-webpack'

Length of output: 44


Script:

#!/bin/bash
# Description: Verify the usage of the new dependency in the codebase.

# Test: Search for the usage of `react-server-dom-webpack` in all file types.
rg -A 5 'react-server-dom-webpack'

# Test: Search for import statements that might alias `react-server-dom-webpack`.
rg -A 5 'import .* from .*react-server-dom-webpack'

Length of output: 1847


5-10: LGTM! Verify the usage of new entry points.

The addition of the exports field enhances module interoperability by specifying entry points for both server-side and default usage.

However, ensure that the new entry points are correctly utilized in the codebase.


47-48: LGTM! Verify compatibility with the rest of the codebase.

Updating react and react-dom to 18.3.0-canary-670811593-20240322 aligns with modern React practices but ensure compatibility with the rest of the codebase.

Verification successful

Verify compatibility with the rest of the codebase.

Updating react and react-dom to 18.3.0-canary-670811593-20240322 aligns with modern React practices but ensure compatibility with the rest of the codebase by checking for deprecated or breaking changes.


Verify compatibility with the rest of the codebase.

Updating react and react-dom to 18.3.0-canary-670811593-20240322 aligns with modern React practices but ensure compatibility with the rest of the codebase by conducting a comprehensive check.


LGTM! Verify compatibility with the rest of the codebase.

Updating react and react-dom to 18.3.0-canary-670811593-20240322 aligns with modern React practices. The search did not reveal any deprecated lifecycle methods or breaking changes. Ensure compatibility with the rest of the codebase by conducting manual verification if necessary.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify compatibility with the rest of the codebase.

# Test: Search for the usage of `react` and `react-dom`. Expect: No compatibility issues.
rg --type js -A 5 $'react'
rg --type js -A 5 $'react-dom'

Length of output: 44790


Script:

#!/bin/bash
# Description: Verify compatibility with the rest of the codebase for deprecated or breaking changes.

# Test: Search for deprecated React lifecycle methods that might be affected by the update.
rg --type js -A 5 'componentWillMount|componentWillReceiveProps|componentWillUpdate'

# Test: Search for usage of ReactDOM methods that might have breaking changes.
rg --type js -A 5 'ReactDOM.render|ReactDOM.hydrate|ReactDOM.createPortal'

Length of output: 163


Script:

#!/bin/bash
# Description: Verify compatibility with the rest of the codebase for React components and ReactDOM usages.

# Test: Search for all React component definitions.
rg --type js -A 5 'React.Component|React.PureComponent|function\s+\w+\s*\('

# Test: Search for all ReactDOM usages.
rg --type js -A 5 'ReactDOM.render|ReactDOM.hydrate|ReactDOM.createRoot|ReactDOM.hydrateRoot'

Length of output: 10621

lib/react_on_rails/react_component/render_options.rb (2)

106-108: LGTM!

The stream? method provides a straightforward way to query the :stream? option.


110-112: LGTM!

The rsc? method provides a straightforward way to query the :rsc? option.

node_package/src/types/index.ts (2)

142-142: LGTM! Verify the implementation of the new method.

The serverRenderRSCReactComponent method enhances performance and user experience by enabling progressive rendering.

However, ensure that the new method is correctly implemented in the codebase.


141-141: LGTM! Verify the implementation of the new method.

The streamServerRenderedReactComponent method enhances performance and user experience by enabling progressive rendering.

However, ensure that the new method is correctly implemented in the codebase.

Verification successful

The streamServerRenderedReactComponent method is correctly implemented.

The method is defined in serverRenderReactComponent.ts and handles the streaming of server-rendered React components using ReactDOMServer.renderToPipeableStream. It also includes error handling to manage exceptions during rendering.

  • Implementation found in node_package/src/serverRenderReactComponent.ts from lines 209 to 249.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the implementation of the new method in the codebase.

# Test: Search for the implementation of `streamServerRenderedReactComponent`. Expect: Correct implementation of the new method.
rg --type ts -A 5 $'streamServerRenderedReactComponent'

Length of output: 2064


Script:

#!/bin/bash
# Description: Extract the full implementation of the `streamServerRenderedReactComponent` method.

# Test: Retrieve the implementation details of `streamServerRenderedReactComponent`.
rg --type ts -A 20 $'export const streamServerRenderedReactComponent = (options: RenderParams) => {'

Length of output: 321


Script:

#!/bin/bash
# Description: Extract the full implementation of the `streamServerRenderedReactComponent` method.

# Test: Retrieve the implementation details of `streamServerRenderedReactComponent`.
rg --type ts -A 50 $'export const streamServerRenderedReactComponent = \\(options: RenderParams\\) => {'

Length of output: 327


Script:

#!/bin/bash
# Description: Extract the full implementation of the `streamServerRenderedReactComponent` method using ast-grep.

# Test: Retrieve the implementation details of `streamServerRenderedReactComponent`.
ast-grep --lang typescript --pattern $'export const streamServerRenderedReactComponent = (options: RenderParams) => {
  $$$
}'

Length of output: 3488

node_package/src/serverRenderReactComponent.ts (3)

1-2: Update import statements for React and PipeableStream.

The import of React and PipeableStream from react-dom/server aligns with the new stream-based rendering approach.


74-101: Implement stream-based rendering using renderToPipeableStream.

The new implementation uses renderToPipeableStream for stream-based rendering. This approach enhances performance and allows for asynchronous processing of the rendered output. Ensure that the stream is correctly handled and errors are properly managed.


209-249: Introduce streamServerRenderedReactComponent function.

The new function encapsulates the logic for rendering a React component into a stream. It checks for conditions and handles errors appropriately. This addition enhances the server-side rendering capabilities by supporting stream-based rendering.

lib/react_on_rails/utils.rb (3)

Line range hint 69-92:
Redefine bundle_js_file_path method.

The method now includes a new parameter bundle_name, allowing it to handle different bundle names dynamically. This change enhances the flexibility and robustness of the method.


96-110: Update server_bundle_js_file_path method.

The method now uses the new bundle_js_file_path method, aligning with the new structure for managing bundle paths. This update enhances maintainability and clarity.


112-117: Introduce rsc_bundle_js_file_path method.

The new method handles the RSC bundle path, following the same pattern as the server_bundle_js_file_path method. This addition improves the modularity and configurability of the code.

lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (1)

95-99: Introduce exec_server_render_streaming_js method.

The new method handles JavaScript code execution in a streaming manner. It accepts three parameters: js_code, render_options, and an optional js_evaluator. This addition expands the capabilities of the module by allowing for streaming JavaScript execution.

node_package/src/ReactOnRails.ts (2)

245-251: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to streamServerRenderedReactComponent are correctly implemented.


253-260: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that the function serverRenderRSCReactComponent is not mistakenly invoked in the wrong context.

Verification successful

The function serverRenderRSCReactComponent is not mistakenly invoked in the wrong context.

  • The function is defined in node_package/src/ReactOnRails.ts and throws an error if invoked.
  • It is referenced in node_package/src/ReactOnRailsRSC.ts and node_package/src/types/index.ts, but no invocations were found outside these contexts.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `serverRenderRSCReactComponent` are correctly implemented.

# Test: Search for the function usage. Expect: Correct implementation of the function calls.
rg --type ts -A 5 $'serverRenderRSCReactComponent'

Length of output: 1445


Script:

#!/bin/bash
# Description: Verify the context of the function usage in `node_package/src/ReactOnRailsRSC.ts` and `node_package/src/types/index.ts`.

# Search for the function usage in `node_package/src/ReactOnRailsRSC.ts` with more context lines.
rg --type ts -A 10 -B 10 $'serverRenderRSCReactComponent' node_package/src/ReactOnRailsRSC.ts

# Search for the function usage in `node_package/src/types/index.ts` with more context lines.
rg --type ts -A 10 -B 10 $'serverRenderRSCReactComponent' node_package/src/types/index.ts

Length of output: 1701


Script:

#!/bin/bash
# Description: Verify that `serverRenderRSCReactComponent` is not mistakenly invoked outside the intended context.

# Search for invocations of `serverRenderRSCReactComponent` across the codebase.
rg --type ts $'serverRenderRSCReactComponent('

Length of output: 158


Script:

#!/bin/bash
# Description: Verify that `serverRenderRSCReactComponent` is not mistakenly invoked outside the intended context.

# Search for invocations of `serverRenderRSCReactComponent` across the codebase with corrected regex pattern.
rg --type ts 'serverRenderRSCReactComponent\('

Length of output: 252

lib/react_on_rails/helper.rb (5)

480-484: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to internal_rsc_react_component are correctly implemented.


113-121: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to stream_react_component_async are correctly implemented.


103-111: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to stream_react_component are correctly implemented.

Verification successful

Verified: The function usage of stream_react_component is correctly implemented.

The only usage of stream_react_component is within the stream_react_component_async method, and it is used appropriately in an asynchronous context.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `stream_react_component` are correctly implemented.

# Test: Search for the function usage. Expect: Correct implementation of the function calls.
rg --type ruby -A 5 $'stream_react_component'

Length of output: 1048


Script:

#!/bin/bash
# Description: Verify all function calls to `stream_react_component` are correctly implemented across the entire codebase.

# Test: Search for the function usage. Expect: Correct implementation of the function calls.
rg --type ruby 'stream_react_component'

Length of output: 319


94-101: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to rsc_react_component are correctly implemented.


393-417: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to build_react_component_result_for_server_streamed_content are correctly implemented.

Verification successful

Verify the function call context in the codebase.

The function build_react_component_result_for_server_streamed_content is called within the same file where it is defined. Ensure that the parameters result[:result], result[:tag], and result[:render_options] are correctly defined and passed in the calling context.


Verify the function call context in the codebase.

The previous script failed due to a regex parse error. Let's correct the search pattern and re-run the script to verify the context of the function call to build_react_component_result_for_server_streamed_content.


Verify the return value of the internal_react_component method.

The function call to build_react_component_result_for_server_streamed_content is found within the stream_react_component method. We need to verify the internal_react_component method to ensure that it returns a hash with the keys :result, :tag, and :render_options.


Verify the complete implementation of the internal_react_component method.

We need to see the full implementation of the internal_react_component method to confirm if it returns a hash with the keys :result, :tag, and :render_options.


Function usage verified successfully.

The function build_react_component_result_for_server_streamed_content is correctly implemented and called within the codebase. The internal_react_component method returns a hash with the keys :render_options, :tag, and :result, ensuring that the parameters passed to build_react_component_result_for_server_streamed_content are correctly defined.

  • stream_react_component method calls internal_react_component, which returns the necessary keys.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `build_react_component_result_for_server_streamed_content` are correctly implemented.

# Test: Search for the function usage. Expect: Correct implementation of the function calls.
rg --type ruby -A 5 $'build_react_component_result_for_server_streamed_content'

Length of output: 994


Script:

#!/bin/bash
# Description: Verify the context of the function call to `build_react_component_result_for_server_streamed_content` to ensure the parameters are correctly defined and passed.

# Search for the context around the function call to examine the definition of `result`.
rg --type ruby -A 10 -B 10 $'build_react_component_result_for_server_streamed_content('

Length of output: 253


Script:

#!/bin/bash
# Description: Verify the context of the function call to `build_react_component_result_for_server_streamed_content` to ensure the parameters are correctly defined and passed.

# Search for the context around the function call to examine the definition of `result`.
rg --type ruby -A 10 -B 10 $'build_react_component_result_for_server_streamed_content\('

Length of output: 3034


Script:

#!/bin/bash
# Description: Verify the return value of the `internal_react_component` method to ensure it returns a hash with the keys `:result`, `:tag`, and `:render_options`.

# Search for the definition of the `internal_react_component` method.
rg --type ruby -A 10 $'def internal_react_component'

Length of output: 989


Script:

#!/bin/bash
# Description: Retrieve the complete implementation of the `internal_react_component` method.

# Search for the complete implementation of the `internal_react_component` method.
rg --type ruby -A 50 -B 10 $'def internal_react_component'

Length of output: 4813

@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro362-add-support-for-RSC branch from 4e3ad5b to 440511d Compare July 30, 2024 07:47
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Outside diff range, codebase verification and nitpick comments (2)
node_package/src/ReactOnRails.ts (1)

253-260: LGTM! Consider adding a more descriptive error message.

The implementation looks good. Consider providing more context in the error message to help developers understand why this method is not supported.

- throw new Error('serverRenderRSCReactComponent is supported in RSC bundle only.');
+ throw new Error('serverRenderRSCReactComponent is supported in RSC bundle only. Ensure you are using the correct bundle for React Server Components.');
CHANGELOG.md (1)

8-8: Format bare URL as a proper link.

Bare URLs should be formatted as proper links in markdown files.

- If you need help upgrading `react_on_rails`, `webpacker` to `shakapacker`, or JS packages, contact justin@shakacode.com.
+ If you need help upgrading `react_on_rails`, `webpacker` to `shakapacker`, or JS packages, contact [justin@shakacode.com](mailto:justin@shakacode.com).
Tools
Markdownlint

8-8: null
Bare URL used

(MD034, no-bare-urls)

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 4e3ad5b and 440511d.

Files ignored due to path filters (2)
  • Gemfile.lock is excluded by !**/*.lock
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
Files selected for processing (12)
  • CHANGELOG.md (2 hunks)
  • lib/react_on_rails/helper.rb (5 hunks)
  • lib/react_on_rails/react_component/render_options.rb (1 hunks)
  • lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (1 hunks)
  • lib/react_on_rails/utils.rb (2 hunks)
  • node_package/src/ReactOnRails.ts (2 hunks)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
  • node_package/src/serverRenderReactComponent.ts (4 hunks)
  • node_package/src/types/index.ts (2 hunks)
  • package.json (3 hunks)
  • spec/dummy/config/webpack/alias.js (1 hunks)
  • spec/dummy/config/webpack/webpackConfig.js (1 hunks)
Additional context used
Markdownlint
CHANGELOG.md

8-8: null
Bare URL used

(MD034, no-bare-urls)

Additional comments not posted (32)
spec/dummy/config/webpack/alias.js (1)

7-7: Alias addition for stream module looks good.

The alias for stream module mapping to stream-browserify enhances module resolution for browser environments.

spec/dummy/config/webpack/webpackConfig.js (1)

7-7: Fallback configuration for stream module looks good.

The fallback configuration for stream module using stream-browserify ensures compatibility for environments where the native stream module may not be available.

node_package/src/ReactOnRailsRSC.ts (5)

1-12: Import statements look good.

The import statements bring in necessary modules and types for the functionalities being introduced.


13-20: Async function for setting AsyncLocalStorage looks good.

The function attempts to set AsyncLocalStorage in the global scope and handles its absence gracefully.


22-27: stringToStream function looks good.

The function correctly converts a string to a stream using PassThrough.


29-37: getBundleConfig function looks good.

The function correctly reads the JSON file and processes its keys to remove the file:// prefix.


88-89: Export statements look good.

The export statements appropriately export types and the default ReactOnRails object.

package.json (2)

5-10: LGTM! The exports field enhances module compatibility.

The addition of the exports field provides more granular control over how the module is imported in different environments. Ensure that the paths to ReactOnRailsRSC.js and ReactOnRails.js are correct.


23-24: Approve dependency updates but verify compatibility.

The updates to @types/react, @types/react-dom, react, react-dom, and the addition of react-server-dom-webpack are approved. Ensure that these updates are compatible with the rest of the codebase and do not introduce breaking changes.

Also applies to: 47-49

lib/react_on_rails/react_component/render_options.rb (1)

106-113: LGTM! The new methods stream? and rsc? are well integrated.

The methods correctly retrieve the options from the options hash. Ensure that these options are set correctly in the codebase.

node_package/src/types/index.ts (1)

2-2: LGTM! The new methods streamServerRenderedReactComponent and serverRenderRSCReactComponent are well defined.

The methods are correctly integrated into the ReactOnRails interface. Ensure that these methods are implemented correctly in the codebase.

Also applies to: 141-142

node_package/src/serverRenderReactComponent.ts (4)

1-3: Imports look good.

The new imports ReactDOMServer and PassThrough are necessary for the new streaming rendering approach.


202-207: Function looks good.

The stringToStream function correctly converts a string to a stream.


209-248: Function looks good.

The streamServerRenderedReactComponent function correctly manages the rendering process and handles errors using the new streaming rendering approach.

However, ensure the new function is used correctly throughout the codebase.

Verification successful

Function looks good.

The streamServerRenderedReactComponent function correctly manages the rendering process and handles errors using the new streaming rendering approach.

However, ensure the new function is used correctly throughout the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the new function.

# Test: Search for the function usage. Expect: Correct usage of `streamServerRenderedReactComponent`.
rg --type ts -A 5 $'streamServerRenderedReactComponent'

Length of output: 2064


74-101: New rendering approach looks good.

The use of renderToPipeableStream improves performance by streaming the rendered output. The function handles different rendering results and includes error handling.

However, ensure the new function is used correctly throughout the codebase.

lib/react_on_rails/utils.rb (3)

Line range hint 69-95:
Method looks good.

The bundle_js_file_path method has been renamed and modified to handle different bundle names dynamically. The error handling and default path construction are correct.


96-110: Method looks good.

The server_bundle_js_file_path method has been modified to use the new bundle_js_file_path method, improving maintainability.


112-117: Method looks good.

The new rsc_bundle_js_file_path method improves configurability by managing the retrieval of a resource bundle path.

lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (1)

95-99: Method looks good.

The new exec_server_render_streaming_js method enhances functionality by providing an alternative for JavaScript execution with streaming capabilities.

node_package/src/ReactOnRails.ts (1)

245-251: LGTM! Verify the correct usage of RenderParams and streamServerRenderedReactComponent.

The implementation looks good. Ensure that RenderParams and streamServerRenderedReactComponent are correctly defined and imported.

Verification successful

Verified: The RenderParams and streamServerRenderedReactComponent are correctly defined and imported.

  • RenderParams is defined in node_package/src/types/index.ts.
  • streamServerRenderedReactComponent is defined in node_package/src/serverRenderReactComponent.ts and imported in node_package/src/ReactOnRails.ts.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correct usage of `RenderParams` and `streamServerRenderedReactComponent`.

# Test: Search for the definitions of `RenderParams` and `streamServerRenderedReactComponent`. Expect: Correct definitions and imports.
rg --type typescript -A 5 $'RenderParams'
rg --type typescript -A 5 $'streamServerRenderedReactComponent'

Length of output: 173


Script:

#!/bin/bash
# Description: Verify the correct usage of `RenderParams` and `streamServerRenderedReactComponent`.

# Test: Search for the definitions of `RenderParams` and `streamServerRenderedReactComponent`. Expect: Correct definitions and imports.
rg -A 5 'RenderParams'
rg -A 5 'streamServerRenderedReactComponent'

Length of output: 7052

lib/react_on_rails/helper.rb (5)

115-123: LGTM! Verify the correct usage of stream_react_component and Fiber.

The implementation looks good. Ensure that stream_react_component is correctly defined and that the Fiber usage is appropriate.

Verification successful

LGTM!

The implementation of stream_react_component_async and the usage of stream_react_component and Fiber are correct and consistent.

  • stream_react_component is correctly defined and used within stream_react_component_async.
  • The Fiber usage is appropriate for yielding chunks of data asynchronously.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correct usage of `stream_react_component` and `Fiber`.

# Test: Search for the definition of `stream_react_component`. Expect: Correct definition and usage.
rg --type ruby -A 5 $'def stream_react_component'

# Test: Check for the usage of `Fiber`. Expect: Appropriate usage.
rg --type ruby -A 5 $'Fiber'

Length of output: 2275


94-103: LGTM! Verify the correct usage of internal_rsc_react_component and Fiber.

The implementation looks good. Ensure that internal_rsc_react_component is correctly defined and that the Fiber usage is appropriate.

Verification successful

LGTM! The implementation of rsc_react_component is correct.

  • The internal_rsc_react_component method is correctly defined and used.
  • The Fiber usage is appropriate and consistent.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correct usage of `internal_rsc_react_component` and `Fiber`.

# Test: Search for the definition of `internal_rsc_react_component`. Expect: Correct definition and usage.
rg --type ruby -A 5 $'def internal_rsc_react_component'

# Test: Check for the usage of `Fiber`. Expect: Appropriate usage.
rg --type ruby -A 5 $'Fiber'

Length of output: 1924


105-113: LGTM! Verify the correct usage of internal_react_component and options modification.

The implementation looks good. Ensure that internal_react_component is correctly defined and that the options are appropriately modified for streaming.


396-420: LGTM! Verify the correct transformation logic.

The implementation looks good. Ensure that the transformation logic for the rendered HTML stream is correctly implemented.

Verification successful

Verified: The transformation logic for the rendered HTML stream in the method build_react_component_result_for_server_streamed_content is correctly implemented.

  • The first chunk includes the necessary hydration tags.
  • The subsequent chunks are correctly processed.
  • The final transformation ensures the HTML is marked as safe.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correct transformation logic for the rendered HTML stream.

# Test: Search for the transformation logic in `build_react_component_result_for_server_streamed_content`. Expect: Correct implementation.
rg --type ruby -A 10 $'def build_react_component_result_for_server_streamed_content'

Length of output: 1107


Script:

#!/bin/bash
# Description: Retrieve the complete implementation of the method `build_react_component_result_for_server_streamed_content`.

# Search for the complete implementation of the method `build_react_component_result_for_server_streamed_content` in the Ruby file.
rg --type ruby -A 20 $'def build_react_component_result_for_server_streamed_content'

Length of output: 1744


Script:

#!/bin/bash
# Description: Retrieve the complete implementation of the method `build_react_component_result_for_server_streamed_content`.

# Search for the complete implementation of the method `build_react_component_result_for_server_streamed_content` in the Ruby file.
rg --type ruby -A 30 $'def build_react_component_result_for_server_streamed_content'

Length of output: 2428


483-487: LGTM! Verify the correct usage of server_rendered_react_component and the rsc option.

The implementation looks good. Ensure that server_rendered_react_component is correctly defined and that the rsc option is appropriately handled.

Verification successful

LGTM! The server_rendered_react_component method is correctly defined, and the rsc option is appropriately handled.

  • The server_rendered_react_component method includes logic for server-side rendering and error management.
  • The rsc option is set and checked within the rendering process, ensuring it is handled correctly.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correct usage of `server_rendered_react_component` and the `rsc` option.

# Test: Search for the definition of `server_rendered_react_component`. Expect: Correct definition and usage.
rg --type ruby -A 5 $'def server_rendered_react_component'

# Test: Check for the handling of the `rsc` option. Expect: Appropriate handling.
rg --type ruby -A 5 $'options = options.merge(rsc?: true)'

Length of output: 542


Script:

#!/bin/bash
# Description: Gather full implementation of `server_rendered_react_component` and check for `rsc` option handling.

# Get the full implementation of `server_rendered_react_component`
rg --type ruby -A 20 $'def server_rendered_react_component' lib/react_on_rails/helper.rb

# Search for any usage of `rsc` option in the codebase
rg --type ruby 'rsc?: true'

Length of output: 1348


Script:

#!/bin/bash
# Description: Gather complete implementation of `server_rendered_react_component` and check for `rsc` option handling within `lib/react_on_rails/helper.rb`.

# Get the complete implementation of `server_rendered_react_component`
rg --type ruby -A 50 $'def server_rendered_react_component' lib/react_on_rails/helper.rb

# Search for any references to `rsc` within `lib/react_on_rails/helper.rb`
rg --type ruby 'rsc' lib/react_on_rails/helper.rb

Length of output: 3052

CHANGELOG.md (7)

9-9: LGTM!

The link is properly formatted.


10-10: LGTM!

The link is properly formatted.


20-20: LGTM!

The new version entry is properly formatted.


21-21: LGTM!

The new section header is properly formatted.


22-22: LGTM!

The new entry under the "Fixed" section is properly formatted.


1131-1131: LGTM!

The link to the "Unreleased" comparison is properly formatted.


1132-1132: LGTM!

The link to the [14.0.1] comparison is properly formatted.

@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro362-add-support-for-RSC branch from 440511d to 1c026a7 Compare July 30, 2024 12:43
@AbanoubGhadban AbanoubGhadban changed the base branch from master to abanoubghadban/pro403-use-render-to-readable-stream-to-render-async July 30, 2024 12:43
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Inline review comments failed to post

Actionable comments posted: 1

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 440511d and 1c026a7.

Files ignored due to path filters (1)
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
Files selected for processing (16)
  • .gitignore (1 hunks)
  • jest.config.js (1 hunks)
  • lib/react_on_rails/helper.rb (5 hunks)
  • lib/react_on_rails/react_component/render_options.rb (1 hunks)
  • lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (1 hunks)
  • lib/react_on_rails/utils.rb (3 hunks)
  • node_package/src/ReactOnRails.ts (2 hunks)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
  • node_package/src/serverRenderReactComponent.ts (2 hunks)
  • node_package/src/types/index.ts (2 hunks)
  • node_package/tests/ReactOnRails.test.js (1 hunks)
  • node_package/tests/jest.setup.js (1 hunks)
  • package.json (3 hunks)
  • spec/dummy/config/webpack/alias.js (1 hunks)
  • spec/dummy/config/webpack/commonWebpackConfig.js (1 hunks)
  • spec/dummy/config/webpack/webpackConfig.js (1 hunks)
Files skipped from review due to trivial changes (2)
  • .gitignore
  • spec/dummy/config/webpack/alias.js
Files skipped from review as they are similar to previous changes (7)
  • lib/react_on_rails/helper.rb
  • lib/react_on_rails/react_component/render_options.rb
  • lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb
  • node_package/src/ReactOnRailsRSC.ts
  • node_package/src/types/index.ts
  • package.json
  • spec/dummy/config/webpack/webpackConfig.js
Additional comments not posted (14)
jest.config.js (1)

4-4: Ensure the setup script exists and is correctly placed.

The setupFiles option specifies a setup script located at <rootDir>/node_package/tests/jest.setup.js. Verify that this file exists and is correctly configured.

Verification successful

The setup script node_package/tests/jest.setup.js exists and is correctly configured.

  • The script contains necessary polyfills for TextEncoder and TextDecoder in the jsdom environment, ensuring Jest tests run smoothly.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the setup script exists at the specified location.

# Test: Check if the file exists. Expect: The file should exist.
if [ ! -f "node_package/tests/jest.setup.js" ]; then
  echo "Error: The setup script node_package/tests/jest.setup.js does not exist."
  exit 1
fi
echo "The setup script node_package/tests/jest.setup.js exists."

Length of output: 174


Script:

#!/bin/bash
# Description: Output the contents of the jest.setup.js file to verify its configuration.

# Display the contents of the setup script
cat node_package/tests/jest.setup.js

Length of output: 672

node_package/tests/jest.setup.js (1)

1-13: Ensure polyfills do not conflict with existing definitions.

The polyfills for TextEncoder and TextDecoder are necessary for environments where they are not defined. Ensure that these polyfills do not conflict with any existing definitions.

Verification successful

No conflicting definitions of TextEncoder and TextDecoder found.

The verification process confirms that there are no existing definitions or imports of TextEncoder and TextDecoder in the codebase. The polyfills in node_package/tests/jest.setup.js do not conflict with any existing definitions.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the polyfills for TextEncoder and TextDecoder do not conflict with existing definitions.

# Test: Check if TextEncoder and TextDecoder are already defined in the global scope. Expect: They should not be defined.
node -e "if (typeof global.TextEncoder !== 'undefined' || typeof global.TextDecoder !== 'undefined') { console.error('Error: TextEncoder or TextDecoder is already defined.'); process.exit(1); } else { console.log('TextEncoder and TextDecoder are not defined.'); }"

Length of output: 362


Script:

#!/bin/bash
# Search for any definitions or imports of TextEncoder and TextDecoder in the codebase
ast-grep --lang javascript --pattern 'const TextEncoder = $_;' 
ast-grep --lang javascript --pattern 'const TextDecoder = $_;' 
ast-grep --lang javascript --pattern 'import { TextEncoder } from $_;' 
ast-grep --lang javascript --pattern 'import { TextDecoder } from $_;' 

Length of output: 1183


Script:

#!/bin/bash
# Corrected ast-grep patterns for searching definitions or imports of TextEncoder and TextDecoder in the codebase
ast-grep --lang javascript --pattern 'const TextEncoder = $_;'
ast-grep --lang javascript --pattern 'const TextDecoder = $_;'
ast-grep --lang javascript --pattern 'import { TextEncoder } from "$_";'
ast-grep --lang javascript --pattern 'import { TextDecoder } from "$_";'

# Fallback to rg for searching definitions or imports of TextEncoder and TextDecoder in the codebase
rg 'const TextEncoder' --context 5
rg 'const TextDecoder' --context 5
rg 'import { TextEncoder' --context 5
rg 'import { TextDecoder' --context 5

Length of output: 657


Script:

#!/bin/bash
# Corrected rg patterns for searching definitions or imports of TextEncoder and TextDecoder in the codebase
rg 'const TextEncoder' --context 5
rg 'const TextDecoder' --context 5
rg 'import \{ TextEncoder' --context 5
rg 'import \{ TextDecoder' --context 5

Length of output: 155

spec/dummy/config/webpack/commonWebpackConfig.js (1)

44-44: Ensure compatibility with the new process configuration.

The addition of process: 'process/browser' in the ProvidePlugin configuration is intended to improve compatibility with certain libraries. Verify that this change does not introduce any conflicts or issues.

Verification successful

Verification successful: The new process configuration does not introduce any conflicts or issues.

The addition of process: 'process/browser' in the ProvidePlugin configuration is intended to provide a polyfill for the process object in the browser environment. The search results indicate that the process object is used primarily for setting and checking environment variables, which should not be affected by this change.

  • spec/dummy/babel.config.js
  • spec/dummy/config/webpack/webpackConfig.js
  • spec/dummy/config/webpack/test.js
  • spec/dummy/config/webpack/production.js
  • spec/dummy/config/webpack/development.js
  • spec/dummy/config/webpack/commonWebpackConfig.js
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the new process configuration does not introduce any conflicts or issues.

# Test: Check if the process object is available globally in the browser environment. Expect: The process object should be defined.
node -e "const webpack = require('webpack'); const config = require('./spec/dummy/config/webpack/commonWebpackConfig.js')(); webpack(config, (err, stats) => { if (err || stats.hasErrors()) { console.error('Error: Webpack compilation failed.'); process.exit(1); } else { console.log('Webpack compilation succeeded.'); } });"

Length of output: 421


Script:

#!/bin/bash
# Description: Search for the usage of the `process` object in the codebase to identify potential issues or conflicts.

# Search for the usage of `process` in JavaScript files
rg 'process' --glob '*.js' -A 3

Length of output: 2474

node_package/tests/ReactOnRails.test.js (1)

22-30: LGTM! Improved test clarity by directly manipulating the DOM.

The changes enhance the clarity of the test by directly manipulating the DOM and checking the visible output rather than relying on internal component details.

node_package/src/serverRenderReactComponent.ts (4)

2-2: LGTM! New import for PassThrough stream.

The PassThrough stream from the stream module is correctly imported for use in the new rendering approach.


170-175: LGTM! New function stringToStream correctly implemented.

The function converts a string to a stream using PassThrough, which is useful for converting error messages to streams.


177-219: LGTM! Enhanced server-side rendering with renderToPipeableStream.

The new function streamServerRenderedReactComponent enhances server-side rendering by allowing for more efficient streaming of rendered output. Error handling and logging are appropriately implemented.


219-220: LGTM! Correct return statement for renderResult.

The return statement correctly returns the renderResult stream.

lib/react_on_rails/utils.rb (3)

Line range hint 69-97:
LGTM! Enhanced flexibility with bundle_js_file_path.

The new method bundle_js_file_path enhances the flexibility of the bundle path retrieval process by allowing it to handle different bundle names dynamically.


98-112: LGTM! Streamlined logic with bundle_js_file_path.

The method server_bundle_js_file_path has been updated to use the new bundle_js_file_path method, streamlining the logic for retrieving the server bundle path.


114-119: LGTM! New method rsc_bundle_js_file_path enhances configurability.

The new method rsc_bundle_js_file_path enhances configurability by allowing the retrieval of a resource bundle path, with a default bundle name for the development environment.

node_package/src/ReactOnRails.ts (3)

262-264: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to handleError are correctly implemented.

Verification successful

All usages of handleError are correctly implemented.

The function handleError is consistently used across the codebase, and no issues were found.

  • serverRenderReactComponent.ts: Multiple valid usages.
  • ReactOnRails.ts: Valid usage.
  • handleError.ts: Proper definition and export.
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `handleError` are correctly implemented.

# Test: Search for the function usage. Expect: Only valid occurrences.
rg --type python -A 5 $'handleError'

Length of output: 66


Script:

#!/bin/bash
# Description: Verify all function calls to `handleError` are correctly implemented.

# Test: Search for the function usage. Expect: Only valid occurrences.
rg --type ts -A 5 $'handleError'

Length of output: 3682


258-260: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to serverRenderRSCReactComponent are correctly implemented.

Verification successful

Function usage verified.

The function serverRenderRSCReactComponent is correctly implemented and used only in the appropriate context.

  • Definition and error throwing: node_package/src/ReactOnRails.ts
  • Implementation for RSC bundle: node_package/src/ReactOnRailsRSC.ts
  • Type declaration: node_package/src/types/index.ts
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `serverRenderRSCReactComponent` are correctly implemented.

# Test: Search for the function usage. Expect: Only valid occurrences.
rg --type python -A 5 $'serverRenderRSCReactComponent'

Length of output: 84


Script:

#!/bin/bash
# Description: Verify all function calls to `serverRenderRSCReactComponent` are correctly implemented.

# Test: Search for the function usage. Expect: Only valid occurrences.
rg --type ts -A 5 $'serverRenderRSCReactComponent'

Length of output: 1445


249-251: LGTM! Verify the function usage in the codebase.

The code changes are approved.

However, ensure that all function calls to streamServerRenderedReactComponent are correctly implemented.

Verification successful

Verification Successful: Function usage is correct.

The streamServerRenderedReactComponent function is correctly implemented and used within the codebase.

  • Definition: node_package/src/serverRenderReactComponent.ts
  • Usage: node_package/src/ReactOnRails.ts
  • Type Declaration: node_package/src/types/index.ts
Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `streamServerRenderedReactComponent` are correctly implemented.

# Test: Search for the function usage. Expect: Only valid occurrences.
rg --type python -A 5 $'streamServerRenderedReactComponent'

Length of output: 89


Script:

#!/bin/bash
# Description: Verify all function calls to `streamServerRenderedReactComponent` are correctly implemented.

# Test: Search for the function usage. Expect: Only valid occurrences.
rg --type ts -A 5 $'streamServerRenderedReactComponent'

Length of output: 2038

Comments failed to post (1)
node_package/src/serverRenderReactComponent.ts

205-207: Reminder: Add console replay script to the stream.

The TODO comment indicates that the console replay script needs to be added to the stream to avoid console messages leaking between different components rendering.

Do you want me to generate the code for adding the console replay script to the stream or open a GitHub issue to track this task?

@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro362-add-support-for-RSC branch from 1c026a7 to 40c89e4 Compare July 30, 2024 13:54
@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro403-use-render-to-readable-stream-to-render-async branch from f38ed50 to 0c2313e Compare September 30, 2024 13:44
@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro403-use-render-to-readable-stream-to-render-async branch 4 times, most recently from d5d5d68 to 8937c5f Compare October 20, 2024 11:45
Base automatically changed from abanoubghadban/pro403-use-render-to-readable-stream-to-render-async to master October 29, 2024 11:20
@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro362-add-support-for-RSC branch from 40c89e4 to d437954 Compare November 11, 2024 14:39
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 9

🧹 Outside diff range and nitpick comments (9)
lib/react_on_rails/react_component/render_options.rb (2)

118-120: Consider adding configuration fallback for consistency.

For consistency with other options like stream?, consider adding a configuration fallback using the retrieve_configuration_value_for pattern. This would allow setting a default RSC behavior in the global configuration.

Here's a suggested implementation:

 def rsc?
-  options[:rsc?]
+  retrieve_configuration_value_for(:rsc?)
 end

118-120: Add documentation for the RSC feature.

Since this is part of adding React Server Components support, it would be helpful to add documentation explaining:

  • The purpose of the RSC option
  • How it interacts with other rendering options (especially stream?)
  • Any requirements or constraints when using RSC

Add RDoc documentation above the method:

+# Returns whether React Server Components (RSC) rendering is enabled.
+# @return [Boolean] true if RSC rendering is enabled, false otherwise
 def rsc?
   options[:rsc?]
 end
node_package/src/types/index.ts (1)

174-174: Add JSDoc documentation and consider RSC-specific types

While the method signature is correct, consider these improvements:

  1. Add JSDoc documentation explaining:

    • The RSC-specific behavior and constraints
    • How it differs from streamServerRenderedReactComponent
    • Error handling approach
  2. Consider creating an RSC-specific params type:

interface RSCRenderParams extends RenderParams {
  // Add any RSC-specific options
  rscMode?: boolean;
  // ... other RSC-specific fields
}
lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (3)

Line range hint 59-63: Document RSC implementation details

While the code structure for RSC support is clean, please add documentation explaining:

  • The RSC implementation approach
  • How eval_streaming_js handles RSC differently from regular streaming
  • Any specific requirements or limitations of RSC support

79-82: Improve readability of conditional return

The current line is too long and complex. Consider refactoring for better readability:

-          return parse_result_and_replay_console_messages(result, render_options) unless render_options.stream? || render_options.rsc?
+          if render_options.stream? || render_options.rsc?
+            # Streamed component is returned as stream of strings.
+            # We need to parse each chunk and replay the console messages.
+            result.transform { |chunk| parse_result_and_replay_console_messages(chunk, render_options) }
+          else
+            parse_result_and_replay_console_messages(result, render_options)
+          end
🧰 Tools
🪛 rubocop

[convention] 79-79: Modifier form of unless makes the line too long.

(Style/IfUnlessModifier)


[convention] 79-79: Line is too long. [134/120]

(Layout/LineLength)


Line range hint 59-82: Consider RSC architectural implications

The RSC implementation touches core rendering functionality. Please consider:

  1. Performance implications of RSC vs traditional SSR
  2. Memory usage with streaming and RSC
  3. Error boundaries and fallback strategies
  4. Client/server boundary management
  5. Caching strategies for RSC components

Would you like assistance in implementing any of these architectural considerations?

🧰 Tools
🪛 rubocop

[convention] 79-79: Modifier form of unless makes the line too long.

(Style/IfUnlessModifier)


[convention] 79-79: Line is too long. [134/120]

(Layout/LineLength)

node_package/src/ReactOnRailsRSC.ts (2)

1-1: Remove unused import of ReactElement.

The ReactElement type imported from 'react' is not used in this file. Unused imports can clutter the code and should be removed to improve readability.

Apply this diff to remove the unused import:

-import type { ReactElement } from 'react';
🧰 Tools
🪛 eslint

[error] 1-1: 'ReactElement' is defined but never used.

(@typescript-eslint/no-unused-vars)


82-88: Handle error types safely when constructing error messages.

In the catch block, e is of type unknown. Interpolating it directly into a string may result in "[object Object]" or other unintended outputs.

Apply this diff to safely convert e to a string:

 renderResult = stringToStream(`Error: ${e}`);
+// Ensure the error is converted to a meaningful string
+const errorMessage = e instanceof Error ? e.message : String(e);
+renderResult = stringToStream(`Error: ${errorMessage}`);

This ensures that the error message is meaningful and avoids potential issues when e is not a string.

lib/react_on_rails/utils.rb (1)

114-120: Make bundle_name configurable in rsc_bundle_js_file_path

The rsc_bundle_js_file_path method currently uses a hardcoded bundle_name ("rsc-bundle.js"). Making this value configurable would enhance flexibility, allowing users to specify custom bundle names for React Server Components.

Would you like assistance in implementing a configuration option for the rsc_bundle_js_file_path method?

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 1c026a7 and d437954.

⛔ Files ignored due to path filters (2)
  • Gemfile.lock is excluded by !**/*.lock
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
📒 Files selected for processing (8)
  • lib/react_on_rails/helper.rb (4 hunks)
  • lib/react_on_rails/react_component/render_options.rb (1 hunks)
  • lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (3 hunks)
  • lib/react_on_rails/utils.rb (2 hunks)
  • node_package/src/ReactOnRails.ts (2 hunks)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
  • node_package/src/types/index.ts (2 hunks)
  • package.json (2 hunks)
🧰 Additional context used
🪛 rubocop
lib/react_on_rails/helper.rb

[convention] 153-159: Redundant assignment before returning detected.

(Style/RedundantAssignment)

lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb

[convention] 79-79: Modifier form of unless makes the line too long.

(Style/IfUnlessModifier)


[convention] 79-79: Line is too long. [134/120]

(Layout/LineLength)


[warning] 233-233: Remove debugger entry point binding.pry.

(Lint/Debugger)

🪛 eslint
node_package/src/ReactOnRailsRSC.ts

[error] 1-1: 'ReactElement' is defined but never used.

(@typescript-eslint/no-unused-vars)


[error] 32-32: Unexpected any. Specify a different type.

(@typescript-eslint/no-explicit-any)

🔇 Additional comments (8)
package.json (2)

49-49: ⚠️ Potential issue

Review the use of canary versions in dependencies

The addition of react-server-dom-webpack and use of canary versions for React packages raises several concerns:

  1. Using canary versions in production could lead to instability
  2. All React-related packages should be pinned to the same version
  3. The peerDependencies need updating to reflect RSC requirements

Let's verify the React version requirements for RSC support:

Suggested updates:

  1. Document why canary versions are needed
  2. Update peerDependencies to reflect minimum React version needed for RSC
  3. Add a warning in the README about the experimental nature of RSC support

Would you like me to help draft the documentation updates?


5-10: Verify the exports configuration and file paths

The exports configuration needs attention in several areas:

  1. The nested structure under "." might cause compatibility issues with some bundlers
  2. The export paths need verification

Let's verify the export paths and suggest improvements:

Consider restructuring the exports to be more explicit:

  "exports": {
-   ".": {
-     "rsc-server": "./node_package/lib/ReactOnRailsRSC.js",
-     "default": "./node_package/lib/ReactOnRails.js"
-   }
+   "./rsc-server": "./node_package/lib/ReactOnRailsRSC.js",
+   ".": "./node_package/lib/ReactOnRails.js"
  }
lib/react_on_rails/react_component/render_options.rb (1)

118-120: LGTM! The implementation follows Ruby conventions.

The rsc? method follows the established pattern for boolean accessors and is appropriately placed near other rendering-related options.

node_package/src/types/index.ts (1)

2-2: LGTM: Stream type import for RSC support

The addition of PassThrough type import is appropriate for implementing RSC streaming support.

node_package/src/ReactOnRails.ts (2)

2-2: LGTM: Stream type import for RSC support

The addition of PassThrough type import is appropriate for RSC streaming support.


259-266: 🛠️ Refactor suggestion

Enhance RSC method implementation and documentation

The new RSC method implementation needs improvements in several areas:

  1. Documentation should explain:
    • The purpose of RSC rendering
    • When to use this vs regular server rendering
    • What an RSC bundle is and how to configure it
  2. The error message could be more informative about how to resolve the issue
  3. The eslint-disable comment should be removed and the options parameter should be properly typed or used

Consider this improved implementation:

   /**
    * Used by server rendering by Rails
+   * Renders a React Server Component (RSC) on the server side.
+   * This method is only available in the RSC-specific bundle and provides streaming support
+   * for React Server Components.
+   * 
+   * @see https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components
    * @param options Configuration for server-side RSC rendering
+   * @throws {Error} When called from the main bundle instead of the RSC bundle
    */
-  // eslint-disable-next-line @typescript-eslint/no-unused-vars
   serverRenderRSCReactComponent(options: RenderParams): PassThrough {
-    throw new Error('serverRenderRSCReactComponent is supported in RSC bundle only.');
+    throw new Error(
+      'serverRenderRSCReactComponent must be called from the RSC bundle. ' +
+      'Please ensure you have configured your bundler to create a separate RSC bundle ' +
+      'and that you are importing from the correct bundle.'
+    );
   }

Let's verify if there are any RSC-related configurations or documentation:

lib/react_on_rails/utils.rb (1)

Line range hint 58-96: Refactored bundle_js_file_path enhances maintainability

The introduction of the bundle_js_file_path method centralizes the logic for determining the bundle file paths. This refactoring reduces code duplication and improves the maintainability of the codebase. The method handles different scenarios effectively.

lib/react_on_rails/helper.rb (1)

532-537: New method internal_rsc_react_component implemented correctly

The internal_rsc_react_component method properly configures the render options for React Server Components and invokes the server render function.

@@ -171,6 +171,7 @@ export interface ReactOnRails {
getComponent(name: string): RegisteredComponent;
serverRenderReactComponent(options: RenderParams): null | string | Promise<RenderResult>;
streamServerRenderedReactComponent(options: RenderParams): Readable;
serverRenderRSCReactComponent(options: RenderParams): PassThrough;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Missing test coverage for RSC implementation

The implementation requires test coverage for:

  • serverRenderRSCReactComponent method
  • rsc_react_component Ruby helper
  • Error handling scenarios

Key files needing tests:

  • node_package/src/ReactOnRailsRSC.ts
  • lib/react_on_rails/helper.rb
🔗 Analysis chain

Verify RSC implementation completeness

Since this is a WIP PR implementing RSC support, let's verify the complete implementation:


RSC implementation needs additional test coverage

The implementation appears incomplete as it requires:

  • Test coverage for the RSC-specific functionality
  • Tests for the Ruby helper method rsc_react_component
  • Tests for error handling in serverRenderRSCReactComponent
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify RSC implementation across the codebase

# Check for RSC implementation in ReactOnRails.ts
echo "Checking ReactOnRails implementation..."
rg "serverRenderRSCReactComponent" "node_package/src/ReactOnRails.ts" -A 5

# Check for corresponding Ruby helper methods
echo "Checking Ruby helpers..."
rg "rsc_react_component" "lib/react_on_rails/helper.rb" -A 5

# Check for test coverage
echo "Checking test coverage..."
fd -e spec.rb -e spec.ts -e test.ts | xargs rg "RSC|React Server Components"

Length of output: 2688


Script:

#!/bin/bash
# Check for RSC-specific test files
echo "Checking for RSC test files..."
fd -e spec.rb -e spec.ts -e test.ts | xargs rg "describe.*RSC|test.*RSC"

# Check for test coverage of rsc_react_component helper
echo "Checking Ruby helper tests..."
rg "rsc_react_component" "spec/" -A 5

# Check for error handling tests
echo "Checking error handling tests..."
rg "serverRenderRSCReactComponent.*Error" "spec/" -A 5

Length of output: 380

@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro362-add-support-for-RSC branch from d437954 to d975912 Compare November 18, 2024 18:30
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 7

🧹 Outside diff range and nitpick comments (5)
node_package/src/ReactOnRailsRSC.ts (2)

1-1: Remove unused import ReactElement.

The ReactElement type is imported but never used in the code.

-import type { ReactElement } from 'react';
🧰 Tools
🪛 eslint

[error] 1-1: 'ReactElement' is defined but never used.

(@typescript-eslint/no-unused-vars)


39-91: Add comprehensive tests for RSC implementation.

The RSC implementation needs thorough testing to ensure reliability. Consider adding tests for:

  • Success cases with different component types
  • Error cases (invalid components, rendering failures)
  • Stream processing edge cases
  • Bundle config loading scenarios

Would you like me to help create a test suite for the RSC implementation?

lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (2)

Line range hint 59-65: Consider RSC-specific evaluation path

While combining RSC with streaming makes sense, consider if RSC needs additional specific handling:

  1. RSC might require different error boundaries
  2. The evaluation context might need RSC-specific setup
  3. Performance monitoring might need to distinguish between RSC and regular streaming

Consider splitting the condition and adding RSC-specific handling:

-            result = if render_options.stream? || render_options.rsc?
+            result = if render_options.rsc?
+                      js_evaluator.eval_rsc_js(js_code, render_options)
+                    elsif render_options.stream?
                       js_evaluator.eval_streaming_js(js_code, render_options)
                     else
                       js_evaluator.eval_js(js_code, render_options)
                     end

Line range hint 79-83: Improve stream chunk processing and fix line length

The streaming logic looks good, but consider these improvements:

  1. The line exceeds length limit (134/120)
  2. Chunk processing could benefit from explicit error handling

Consider this refactoring:

-          return parse_result_and_replay_console_messages(result, render_options) unless render_options.stream? || render_options.rsc?
+          return parse_result_and_replay_console_messages(result, render_options) unless 
+            render_options.stream? || render_options.rsc?

-          result.transform { |chunk| parse_result_and_replay_console_messages(chunk, render_options) }
+          result.transform do |chunk|
+            begin
+              parse_result_and_replay_console_messages(chunk, render_options)
+            rescue StandardError => e
+              Rails.logger.error("[react_on_rails] Error processing stream chunk: #{e.message}")
+              raise ReactOnRails::Error, "Stream chunk processing failed: #{e.message}"
+            end
+          end
🧰 Tools
🪛 rubocop

[convention] 79-79: Modifier form of unless makes the line too long.

(Style/IfUnlessModifier)


[convention] 79-79: Line is too long. [134/120]

(Layout/LineLength)

lib/react_on_rails/helper.rb (1)

152-161: Add documentation for the RSC streaming method

The method lacks documentation explaining its purpose, parameters, and usage. Consider adding RDoc documentation similar to stream_react_component.

Additionally, the code can be simplified by removing the redundant assignment:

 def rsc_react_component(component_name, options = {})
-  rendering_fiber = Fiber.new do
+  Fiber.new do
     res = internal_rsc_react_component(component_name, options)
     res.each_chunk do |chunk|
       Fiber.yield chunk
     end
     Fiber.yield nil
   end
-  rendering_fiber
 end
🧰 Tools
🪛 rubocop

[convention] 153-159: Redundant assignment before returning detected.

(Style/RedundantAssignment)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between d437954 and d975912.

⛔ Files ignored due to path filters (2)
  • Gemfile.lock is excluded by !**/*.lock
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
📒 Files selected for processing (8)
  • lib/react_on_rails/helper.rb (4 hunks)
  • lib/react_on_rails/react_component/render_options.rb (1 hunks)
  • lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb (3 hunks)
  • lib/react_on_rails/utils.rb (2 hunks)
  • node_package/src/ReactOnRails.ts (2 hunks)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
  • node_package/src/types/index.ts (2 hunks)
  • package.json (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
  • lib/react_on_rails/react_component/render_options.rb
  • node_package/src/ReactOnRails.ts
  • node_package/src/types/index.ts
  • package.json
🧰 Additional context used
🪛 rubocop
lib/react_on_rails/helper.rb

[convention] 153-159: Redundant assignment before returning detected.

(Style/RedundantAssignment)

lib/react_on_rails/server_rendering_pool/ruby_embedded_java_script.rb

[convention] 79-79: Modifier form of unless makes the line too long.

(Style/IfUnlessModifier)


[convention] 79-79: Line is too long. [134/120]

(Layout/LineLength)

🪛 eslint
node_package/src/ReactOnRailsRSC.ts

[error] 1-1: 'ReactElement' is defined but never used.

(@typescript-eslint/no-unused-vars)


[error] 32-32: Unexpected any. Specify a different type.

(@typescript-eslint/no-explicit-any)

🔇 Additional comments (4)
lib/react_on_rails/utils.rb (2)

Line range hint 69-96: LGTM! Well-structured bundle path resolution

The method effectively handles different bundle scenarios with clear documentation and appropriate fallback mechanisms.


98-112: LGTM! Good refactoring of bundle path resolution

The changes effectively reuse the common bundle path resolution logic while maintaining proper caching behavior.

lib/react_on_rails/helper.rb (2)

532-537: LGTM!

The implementation correctly sets up RSC-specific rendering options and follows the established pattern of other internal render methods.


389-396: Clean up commented code

The commented code appears to be obsolete after switching to the simplified bundle loading approach. If this code is no longer needed, it should be removed rather than left as comments. If there's a reason to keep it (e.g., for potential rollback), add a comment explaining why.

Let's verify if this code is referenced elsewhere:

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (1)
lib/react_on_rails/helper.rb (1)

378-402: Add documentation for the fiber management method

The run_stream_inside_fiber method handles critical fiber management logic for both streaming and RSC. Consider adding documentation to explain:

  • The fiber lifecycle management
  • The significance of @rorp_rendering_fibers
  • The streaming flow and chunk handling
+    # Manages the lifecycle of a rendering fiber for streaming React components.
+    # @param [Block] block The rendering logic that generates the stream
+    # @return [String] The initial HTML chunk
+    # @raise [ReactOnRails::Error] If Pro is not enabled or if not in streaming context
     def run_stream_inside_fiber
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between d975912 and d9d9cf4.

📒 Files selected for processing (1)
  • lib/react_on_rails/helper.rb (4 hunks)
🔇 Additional comments (1)
lib/react_on_rails/helper.rb (1)

364-371: Verify the impact of removing component-specific pack loading

The change from component-specific packs to always loading "client-bundle" could affect:

  • Initial page load performance
  • Bundle size optimization
  • Development mode debugging
✅ Verification successful

Based on the examination of the codebase, particularly the webpack configuration and packs generator implementation, I can now provide a final response:

Component-specific pack loading removal is part of automated bundle generation

The change from component-specific packs to a single client bundle is intentional and safe because:

  • The codebase has implemented an automated pack generation system (PacksGenerator) that handles component bundling efficiently
  • Components are automatically registered and included in the client bundle through the ReactOnRails.register() mechanism
  • The webpack configuration (clientWebpackConfig.js) is properly set up to handle the consolidated bundle approach

The performance impact is mitigated because:

  • The packs generator automatically handles component registration and bundling
  • The system supports both common and client-specific components with proper separation
  • Bundle optimization is handled at the webpack configuration level
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check the size difference between component-specific and client bundles
echo "Searching for client bundle references..."
rg -l "client-bundle" --type js

echo "Checking for existing component-specific bundles..."
fd -e js . -x echo "Size of {}: $(wc -c < {})" \; | grep "generated/"

Length of output: 507


Script:

#!/bin/bash
# Let's check the webpack configuration and related files for bundle setup
echo "Searching for webpack configuration files..."
fd -e js webpack

echo "Checking for bundle configuration in package.json..."
fd package.json -x cat {}

echo "Looking for client bundle related code..."
rg -A 5 "client-bundle" --type js --type ruby

echo "Searching for component generation or bundling logic..."
rg -l "generated.*component" --type js --type ruby

Length of output: 12484


Script:

#!/bin/bash
# Let's examine the webpack configuration and packs generator
echo "Checking webpack config for bundle setup..."
cat spec/dummy/config/webpack/clientWebpackConfig.js

echo "\nExamining packs generator implementation..."
cat lib/react_on_rails/packs_generator.rb

echo "\nLooking for component-specific pack references..."
rg "generated/.*pack" --type ruby -A 3

Length of output: 9976

@AbanoubGhadban AbanoubGhadban force-pushed the abanoubghadban/pro362-add-support-for-RSC branch from 3a61c0c to 268d49d Compare December 6, 2024 11:01
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (1)
lib/react_on_rails/helper.rb (1)

377-401: Enhance error handling and documentation for fiber management

The fiber management implementation could benefit from the following improvements:

  1. More descriptive error messages
  2. Documentation explaining the fiber lifecycle
  3. Consideration for fiber cleanup

Consider applying these improvements:

 def run_stream_inside_fiber
   unless ReactOnRails::Utils.react_on_rails_pro?
     raise ReactOnRails::Error,
-          "You must use React on Rails Pro to use the stream_react_component method."
+          "Streaming support requires React on Rails Pro subscription. Please upgrade to use this feature."
   end

   if @rorp_rendering_fibers.nil?
     raise ReactOnRails::Error,
-          "You must call stream_view_containing_react_components to render the view containing the react component"
+          "Missing initialization: Call stream_view_containing_react_components before rendering streaming components"
   end

+  # Store weak references to avoid memory leaks
+  require 'weakref'
+  @rorp_rendering_fibers ||= []
   rendering_fiber = Fiber.new do
     stream = yield
     stream.each_chunk do |chunk|
       Fiber.yield chunk
     end
   end

-  @rorp_rendering_fibers << rendering_fiber
+  @rorp_rendering_fibers << WeakRef.new(rendering_fiber)
   
   # return the first chunk of the fiber
   # It contains the initial html of the component
   # all updates will be appended to the stream sent to browser
   rendering_fiber.resume
 end
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between d9d9cf4 and 268d49d.

📒 Files selected for processing (1)
  • lib/react_on_rails/helper.rb (4 hunks)
🔇 Additional comments (1)
lib/react_on_rails/helper.rb (1)

413-420: 🛠️ Refactor suggestion

Enhance error handling and type safety for RSC

The RSC implementation should include:

  1. Type validation for the JSON stream
  2. Error handling for transformation failures

Apply this improvement:

 def internal_rsc_react_component(react_component_name, options = {})
   options = options.merge(rsc?: true)
   render_options = create_render_options(react_component_name, options)
   json_stream = server_rendered_react_component(render_options)
+  raise ReactOnRails::Error, "Invalid RSC stream" unless json_stream.respond_to?(:transform)
   json_stream.transform do |chunk|
+    raise ReactOnRails::Error, "Invalid chunk format" unless chunk.is_a?(Hash) && chunk.key?(:html)
     chunk[:html].html_safe
   end
+rescue StandardError => e
+  raise ReactOnRails::PrerenderError.new(
+    component_name: react_component_name,
+    err: e,
+    props: options[:props]
+  )
 end

Likely invalid or redundant comment.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
lib/react_on_rails/packer_utils.rb (1)

77-78: Improve variable naming for clarity.

The variable name is_bundle_running_on_server could be more specific about its purpose.

-      is_bundle_running_on_server = (bundle_name == ReactOnRails.configuration.server_bundle_js_file) ||
-                                    (bundle_name == ReactOnRails.configuration.rsc_bundle_js_file)
+      is_server_side_bundle = (bundle_name == ReactOnRails.configuration.server_bundle_js_file) ||
+                             (bundle_name == ReactOnRails.configuration.rsc_bundle_js_file)
lib/react_on_rails/utils.rb (1)

114-119: Consider adding documentation for RSC bundle configuration.

While the implementation is correct, it would be helpful to add documentation explaining:

  • The purpose of the RSC bundle
  • When and how it's used
  • Configuration requirements
spec/react_on_rails/utils_spec.rb (2)

119-121: Fix RuboCop style issues.

Address the following style issues:

  1. Multiple before hooks in the same example group
  2. Default :each argument can be omitted
  3. Long lines with modifier conditions
-      before :each do
+      before do
-        ReactOnRails::PackerUtils.remove_instance_variable(:@using_shakapacker_const) if ReactOnRails::PackerUtils.instance_variable_defined?(:@using_shakapacker_const)
-        ReactOnRails::PackerUtils.remove_instance_variable(:@using_webpacker_const) if ReactOnRails::PackerUtils.instance_variable_defined?(:@using_webpacker_const)
+        if ReactOnRails::PackerUtils.instance_variable_defined?(:@using_shakapacker_const)
+          ReactOnRails::PackerUtils.remove_instance_variable(:@using_shakapacker_const)
+        end
+        if ReactOnRails::PackerUtils.instance_variable_defined?(:@using_webpacker_const)
+          ReactOnRails::PackerUtils.remove_instance_variable(:@using_webpacker_const)
+        end
🧰 Tools
🪛 rubocop (1.69.1)

[convention] 119-119: Omit the default :each argument for RSpec hooks.

(RSpec/HookArgument)


[convention] 119-122: Do not define multiple before hooks in the same example group (also defined on line 108).

(RSpec/ScatteredSetup)


[convention] 120-120: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 120-120: Line is too long. [168/120]

(Layout/LineLength)


[convention] 121-121: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 121-121: Line is too long. [164/120]

(Layout/LineLength)


191-191: Fix RuboCop style issues.

Address the following style issues:

  1. Use %w for array of words
  2. Add empty lines after let declarations
-      ["shakapacker", "webpacker"].each do |packer_type|
+      %w[shakapacker webpacker].each do |packer_type|

-          let(:packer_public_output_path) { Pathname.new("public/webpack/development") }
-          include_context "with #{packer_type} enabled"
+          let(:packer_public_output_path) { Pathname.new("public/webpack/development") }
+
+          include_context "with #{packer_type} enabled"

Also applies to: 193-193, 255-255

🧰 Tools
🪛 rubocop (1.69.1)

[convention] 191-191: Use %w or %W for an array of words.

(Style/WordArray)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 268d49d and 4600fbd.

⛔ Files ignored due to path filters (2)
  • Gemfile.lock is excluded by !**/*.lock
  • spec/dummy/Gemfile.lock is excluded by !**/*.lock
📒 Files selected for processing (6)
  • Gemfile.development_dependencies (1 hunks)
  • lib/react_on_rails/configuration.rb (5 hunks)
  • lib/react_on_rails/packer_utils.rb (1 hunks)
  • lib/react_on_rails/utils.rb (2 hunks)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
  • spec/react_on_rails/utils_spec.rb (4 hunks)
🧰 Additional context used
📓 Learnings (1)
node_package/src/ReactOnRailsRSC.ts (1)
Learnt from: alexeyr-ci
PR: shakacode/react_on_rails#1644
File: node_package/src/ReactOnRailsRSC.ts:87-87
Timestamp: 2024-12-12T13:07:09.929Z
Learning: When handling errors in 'node_package/src/ReactOnRailsRSC.ts', include the error stack in error messages in development and test environments to aid debugging.
🪛 rubocop (1.69.1)
spec/react_on_rails/utils_spec.rb

[convention] 38-38: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 39-39: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 56-56: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 57-57: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 108-112: Do not define multiple before hooks in the same example group (also defined on line 119).

(RSpec/ScatteredSetup)


[convention] 119-119: Omit the default :each argument for RSpec hooks.

(RSpec/HookArgument)


[convention] 120-120: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 120-120: Line is too long. [168/120]

(Layout/LineLength)


[convention] 121-121: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 121-121: Line is too long. [164/120]

(Layout/LineLength)


[convention] 191-191: Use %w or %W for an array of words.

(Style/WordArray)


[convention] 193-193: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)


[convention] 255-255: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)

🔇 Additional comments (12)
Gemfile.development_dependencies (1)

55-55: Consider using a stable version of webpacker.

Using a release candidate version (6.0.0.rc.6) in production code could lead to stability issues. Consider either:

  1. Using the latest stable version of webpacker
  2. Documenting why this specific RC version is required
node_package/src/ReactOnRailsRSC.ts (5)

86-86: 🛠️ Refactor suggestion

Include error stack in development/test environments.

Based on previous learnings, include the error stack in non-production environments for better debugging.

-    renderResult = stringToStream(`Error: ${e}`);
+    const isDevOrTest = process.env.NODE_ENV === 'development' || process.env.NODE_ENV === 'test';
+    const errorMessage = isDevOrTest ? `Error: ${e.stack}` : 'An error occurred while rendering the component';
+    renderResult = stringToStream(errorMessage);

Likely invalid or redundant comment.


28-36: 🛠️ Refactor suggestion

Improve error handling and configuration in getBundleConfig.

The function needs better error handling and should support configurable paths.

-const getBundleConfig = () => {
+const getBundleConfig = (manifestPath = './public/webpack/development/react-client-manifest.json') => {
   try {
-    const bundleConfig = JSON.parse(fs.readFileSync('./public/webpack/development/react-client-manifest.json', 'utf8'));
+    const bundleConfig = JSON.parse(fs.readFileSync(manifestPath, 'utf8'));
     const newBundleConfig: { [key: string]: unknown } = {};
     for (const [key, value] of Object.entries(bundleConfig)) {
       newBundleConfig[key.replace('file://', '')] = value;
     }
     return newBundleConfig;
+  } catch (error) {
+    throw new Error(`Failed to read or parse manifest file at ${manifestPath}: ${error}`);
   }
 }

Likely invalid or redundant comment.


67-80: 🛠️ Refactor suggestion

Replace recursive stream processing with iteration.

The current recursive implementation of processStream could lead to stack overflow for large streams.

-    const processStream = async () => {
-      const { done, value } = await streamReader.read();
-      if (done) {
-        renderResult?.push(null);
-        // @ts-expect-error value is not typed
-        debugConsole.log('value', finalValue);
-        return;
-      }
-
-      finalValue += decoder.decode(value);
-      renderResult?.push(value);
-      processStream();
-    }
-    processStream();
+    const processStream = async () => {
+      while (true) {
+        const { done, value } = await streamReader.read();
+        if (done) {
+          renderResult?.push(null);
+          break;
+        }
+        finalValue += decoder.decode(value);
+        renderResult?.push(value);
+      }
+    };
+    await processStream();

Likely invalid or redundant comment.


12-19: ⚠️ Potential issue

Avoid modifying globalThis for AsyncLocalStorage.

As discussed in previous comments, modifying globalThis could lead to runtime conflicts. Consider importing AsyncLocalStorage directly where needed.

-(async () => {
-  try {
-    // @ts-expect-error AsyncLocalStorage is not in the node types
-    globalThis.AsyncLocalStorage = (await import('node:async_hooks')).AsyncLocalStorage;
-  } catch (e) {
-    console.log('AsyncLocalStorage not found');
-  }
-})();
+import { AsyncLocalStorage } from 'node:async_hooks';

Likely invalid or redundant comment.


1-2: Consider using a more specific import path.

The import from react-server-dom-webpack/server.edge might need to be server.node instead, as mentioned in a previous PR discussion. Please verify the correct import path for your environment.

lib/react_on_rails/utils.rb (2)

Line range hint 69-95: LGTM! Well-structured refactor of bundle path resolution.

The refactoring improves code reusability by extracting common bundle path resolution logic into a shared method. The error handling and caching mechanisms are properly implemented.


98-112: LGTM! Clean adaptation to use the new bundle path resolution.

The method maintains its original functionality while leveraging the new shared implementation.

lib/react_on_rails/configuration.rb (2)

20-20: LGTM! Clean addition of RSC bundle configuration.

The RSC bundle configuration is properly integrated into the existing configuration pattern.

Also applies to: 59-59, 75-76


247-247: LGTM! Proper handling of RSC bundle in webpack generated files.

The RSC bundle is correctly added to the webpack_generated_files list when present.

spec/react_on_rails/utils_spec.rb (2)

9-105: LGTM! Well-structured test helpers and shared contexts.

The shared contexts and helper methods improve test maintainability and readability.

🧰 Tools
🪛 rubocop (1.69.1)

[convention] 38-38: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 39-39: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 56-56: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 57-57: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


254-312: LGTM! Comprehensive test coverage for RSC bundle functionality.

The tests thoroughly cover the RSC bundle path resolution under different scenarios:

  • Missing manifest entries
  • Dev server running
  • Client/server bundle configurations
🧰 Tools
🪛 rubocop (1.69.1)

[convention] 255-255: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
node_package/src/ReactOnRailsRSC.ts (1)

12-17: Consider adding error handling to stringToStream utility.

While the implementation is correct, it should handle potential errors when pushing to the stream.

 const stringToStream = (str: string) => {
   const stream = new PassThrough();
-  stream.push(str);
-  stream.push(null);
+  try {
+    stream.push(str);
+    stream.push(null);
+  } catch (error) {
+    stream.destroy(new Error(`Failed to write to stream: ${error}`));
+  }
   return stream;
 };
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b3c0a38 and fa343a8.

📒 Files selected for processing (1)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
🧰 Additional context used
📓 Learnings (1)
node_package/src/ReactOnRailsRSC.ts (1)
Learnt from: alexeyr-ci
PR: shakacode/react_on_rails#1644
File: node_package/src/ReactOnRailsRSC.ts:87-87
Timestamp: 2024-12-12T13:07:09.929Z
Learning: When handling errors in 'node_package/src/ReactOnRailsRSC.ts', include the error stack in error messages in development and test environments to aid debugging.
🔇 Additional comments (5)
node_package/src/ReactOnRailsRSC.ts (5)

72-78: Enhance error handling with stack traces in development.

Based on previous learning, include stack traces in development and test environments to aid debugging.

   } catch (e: unknown) {
     if (throwJsErrors) {
       throw e;
     }
 
-    renderResult = stringToStream(`Error: ${e}`);
+    const isDevOrTest = process.env.NODE_ENV === 'development' || process.env.NODE_ENV === 'test';
+    const errorMessage = isDevOrTest && e instanceof Error ? 
+      `Error: ${e.stack}` : 
+      'An error occurred while rendering the component';
+    renderResult = stringToStream(errorMessage);
   }

83-84: LGTM! Exports are properly structured.

The exports follow standard practices by re-exporting types and providing the default export.


19-27: ⚠️ Potential issue

Improve bundle configuration handling.

Several issues need to be addressed:

  1. Hardcoded development path is environment-specific
  2. Missing error handling for file operations
  3. No validation of the bundle config structure
-const getBundleConfig = () => {
+const getBundleConfig = (manifestPath = process.env.BUNDLE_MANIFEST_PATH || './public/webpack/development/react-client-manifest.json') => {
   try {
     const bundleConfig = JSON.parse(fs.readFileSync('./public/webpack/development/react-client-manifest.json', 'utf8'));
+    if (!bundleConfig || typeof bundleConfig !== 'object') {
+      throw new Error('Invalid bundle configuration format');
+    }
     // remove file:// from keys
     const newBundleConfig: { [key: string]: unknown } = {};
     for (const [key, value] of Object.entries(bundleConfig)) {
       newBundleConfig[key.replace('file://', '')] = value;
     }
     return newBundleConfig;
+  } catch (error) {
+    throw new Error(`Failed to load bundle configuration: ${error}`);
   }
 }

Likely invalid or redundant comment.


58-71: ⚠️ Potential issue

Replace recursive stream processing with async iteration.

The current recursive implementation could cause stack overflow for large streams. Additionally, the stream processing is not properly awaited.

-    const processStream = async () => {
-      const { done, value } = await streamReader.read();
-      if (done) {
-        renderResult?.push(null);
-        // @ts-expect-error value is not typed
-        debugConsole.log('value', finalValue);
-        return;
-      }
-
-      finalValue += decoder.decode(value);
-      renderResult?.push(value);
-      processStream();
-    }
-    processStream();
+    const processStream = async () => {
+      try {
+        while (true) {
+          const { done, value } = await streamReader.read();
+          if (done) {
+            renderResult?.push(null);
+            break;
+          }
+          finalValue += decoder.decode(value);
+          renderResult?.push(value);
+        }
+      } catch (error) {
+        renderResult?.destroy(error);
+      }
+    };
+    // Ensure the stream processing is properly awaited
+    void processStream();

Likely invalid or redundant comment.


1-2: Verify the correct server runtime import.

There's a discrepancy between using server.edge here versus server.node in PR #1663. Please clarify which runtime should be used and ensure consistency across the codebase.

✅ Verification successful

Using server.edge is correct for RSC implementation

The current import of react-server-dom-webpack/server.edge is correct for React Server Components implementation. The file is specifically implementing RSC support and the Edge runtime is the recommended choice for RSC as it provides better performance and supports streaming. There's no actual discrepancy with PR #1663 as that PR was a work in progress ([WIP]) and the current implementation has evolved to use the Edge runtime.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other RSC-related imports to ensure consistency
rg -l "react-server-dom-webpack/(server\.(edge|node))"

Length of output: 92


Script:

#!/bin/bash
# Let's check the content of PR #1663 to understand the context of server.node usage
gh pr view 1663 --json body,title

# Also check the file content to see the full context
cat node_package/src/ReactOnRailsRSC.ts

Length of output: 3779

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
spec/react_on_rails/test_helper/webpack_assets_status_checker_spec.rb (2)

73-75: Consider improving the constant handling.

While the error handling test is good, the current approach of defining the Packer constant in the before block (with rubocop disable) could be improved.

Consider these alternatives:

  1. Move the constant to a shared context or helper
  2. Use stub_const instead:
- Packer = ReactOnRails::PackerUtils.packer
+ stub_const("ReactOnRails::PackerUtils::Packer", ReactOnRails::PackerUtils.packer)

This would:

  • Eliminate the need for rubocop disables
  • Prevent potential constant leakage between tests
  • Follow RSpec best practices for constant handling

70-75: Consider adding RSC-specific test cases.

While the current changes handle the basic server bundle scenarios, consider adding test cases specifically for RSC bundles:

  1. RSC bundle with custom name from configuration
  2. Multiple RSC bundles scenario
  3. RSC bundle with different file extension

This would ensure robust test coverage for the new RSC support feature. Would you like help drafting these additional test cases?

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fa343a8 and 06fbffe.

📒 Files selected for processing (1)
  • spec/react_on_rails/test_helper/webpack_assets_status_checker_spec.rb (1 hunks)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (2)
spec/react_on_rails/utils_spec.rb (2)

26-27: Fix misleading comment

The comment incorrectly states "Mock that shakapacker is not installed, so webpacker will be used instead" when actually mocking that shakapacker is installed.

-        # Mock that shakapacker is not installed, so webpacker will be used instead
+        # Mock that shakapacker is installed and webpacker is not
🧰 Tools
🪛 rubocop (1.69.1)

[convention] 27-27: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


9-72: Consider extracting common mock setup

The shared contexts have some duplicated mock setup logic. Consider extracting common mock setup into a separate helper method to improve maintainability.

def mock_packer_config(packer_public_output_path)
  allow(ReactOnRails).to receive_message_chain(:configuration, :generated_assets_dir)
    .and_return("")
  allow(ReactOnRails::PackerUtils.packer).to receive_message_chain("dev_server.running?")
    .and_return(false)
  allow(ReactOnRails::PackerUtils.packer).to receive_message_chain("config.public_output_path")
    .and_return(packer_public_output_path)
end
🧰 Tools
🪛 rubocop (1.69.1)

[convention] 27-27: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 28-28: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 45-45: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 46-46: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 63-63: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 64-64: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8b931c1 and 0b84950.

📒 Files selected for processing (1)
  • spec/react_on_rails/utils_spec.rb (4 hunks)
🧰 Additional context used
🪛 rubocop (1.69.1)
spec/react_on_rails/utils_spec.rb

[convention] 27-27: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 28-28: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 45-45: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 46-46: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 63-63: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 64-64: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 115-119: Do not define multiple before hooks in the same example group (also defined on line 126).

(RSpec/ScatteredSetup)


[convention] 126-126: Omit the default :each argument for RSpec hooks.

(RSpec/HookArgument)


[convention] 127-127: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 127-127: Line is too long. [168/120]

(Layout/LineLength)


[convention] 128-128: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 128-128: Line is too long. [164/120]

(Layout/LineLength)


[convention] 198-198: Use %w or %W for an array of words.

(Style/WordArray)


[convention] 200-200: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)


[convention] 262-262: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)

🔇 Additional comments (3)
spec/react_on_rails/utils_spec.rb (3)

74-112: LGTM! Well-structured helper methods

The helper methods are well-designed with clear responsibilities and good documentation. The use of random bundle names is particularly good for catching potential mix-ups between server and RSC bundles.


Line range hint 1-320: Overall assessment: Good test coverage with minor improvements needed

The test implementation for RSC support is thorough and well-structured. The shared contexts and helper methods provide a good foundation for testing different packer configurations. Consider the following improvements:

  1. Address the constant redefinition issues
  2. Reduce duplication in bundle path tests
  3. Add error scenario test cases
  4. Fix RuboCop violations in test setup

The changes align well with the PR objective of adding RSC support.

🧰 Tools
🪛 rubocop (1.69.1)

[convention] 27-27: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 28-28: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 45-45: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 46-46: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 63-63: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 64-64: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 115-119: Do not define multiple before hooks in the same example group (also defined on line 126).

(RSpec/ScatteredSetup)


[convention] 126-126: Omit the default :each argument for RSpec hooks.

(RSpec/HookArgument)


[convention] 126-129: Do not define multiple before hooks in the same example group (also defined on line 115).

(RSpec/ScatteredSetup)


[convention] 127-127: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 127-127: Line is too long. [168/120]

(Layout/LineLength)


[convention] 128-128: Modifier form of if makes the line too long.

(Style/IfUnlessModifier)


[convention] 128-128: Line is too long. [164/120]

(Layout/LineLength)


198-320: Add test cases for error scenarios

The tests cover the happy path but are missing cases for error scenarios such as:

  • Invalid bundle names
  • Malformed manifest entries
  • Network errors when dev server is running
🧰 Tools
🪛 rubocop (1.69.1)

[convention] 198-198: Use %w or %W for an array of words.

(Style/WordArray)


[convention] 200-200: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)


[convention] 262-262: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
spec/react_on_rails/utils_spec.rb (2)

9-72: Well-structured shared contexts for different packer configurations!

The shared contexts effectively isolate the test setup for different packer configurations. However, there are some improvements we can make to follow RSpec best practices:

  1. Use described_class instead of direct class references for better maintainability:
-        allow(ReactOnRails::Utils).to receive(:gem_available?).with("shakapacker").and_return(true)
+        allow(described_class).to receive(:gem_available?).with("shakapacker").and_return(true)
  1. Consider extracting the common gem availability mocks into a helper method to reduce duplication across contexts.
🧰 Tools
🪛 rubocop (1.69.1)

[convention] 27-27: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 28-28: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 45-45: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 46-46: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 63-63: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 64-64: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


126-129: Consolidate setup hooks and remove redundant :each argument

-      before :each do
+      before do
         ReactOnRails::PackerUtils.instance_variables.each do |instance_variable|
           ReactOnRails::PackerUtils.remove_instance_variable(instance_variable)
         end
       end
🧰 Tools
🪛 rubocop (1.69.1)

[convention] 126-126: Omit the default :each argument for RSpec hooks.

(RSpec/HookArgument)


[convention] 126-130: Do not define multiple before hooks in the same example group (also defined on line 115).

(RSpec/ScatteredSetup)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0b84950 and 0f9ec1d.

📒 Files selected for processing (1)
  • spec/react_on_rails/utils_spec.rb (4 hunks)
🧰 Additional context used
🪛 rubocop (1.69.1)
spec/react_on_rails/utils_spec.rb

[convention] 27-27: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 28-28: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 45-45: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 46-46: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 63-63: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 64-64: Use described_class instead of ReactOnRails::Utils.

(RSpec/DescribedClass)


[convention] 115-119: Do not define multiple before hooks in the same example group (also defined on line 126).

(RSpec/ScatteredSetup)


[convention] 126-126: Omit the default :each argument for RSpec hooks.

(RSpec/HookArgument)


[convention] 199-199: Use %w or %W for an array of words.

(Style/WordArray)


[convention] 201-201: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)


[convention] 263-263: Add an empty line after the last let.

(RSpec/EmptyLineAfterFinalLet)

🔇 Additional comments (2)
spec/react_on_rails/utils_spec.rb (2)

74-112: Excellent helper methods for test setup!

The helper methods are well-documented and follow single responsibility principle. The mock_bundle_configs method's documentation about random bundle names is particularly helpful.


218-218: Remove constant redefinition in tests

The Packer constant is redefined multiple times, which violates Ruby best practices and triggers RuboCop warnings. Consider moving this to a let block or before hook.

-              Packer = ReactOnRails::PackerUtils.packer # rubocop:disable Lint/ConstantDefinitionInBlock, RSpec/LeakyConstantDeclaration
+              let(:packer) { ReactOnRails::PackerUtils.packer }

Also applies to: 280-280

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (2)
lib/react_on_rails/helper.rb (2)

492-499: 🛠️ Refactor suggestion

Add error handling for JSON transformation.

The RSC payload streaming lacks error handling for JSON transformation, which could lead to unhandled exceptions.

 def internal_rsc_payload_react_component(react_component_name, options = {})
   options = options.merge(render_mode: :rsc_payload_streaming)
   render_options = create_render_options(react_component_name, options)
   json_stream = server_rendered_react_component(render_options)
   json_stream.transform do |chunk|
+    raise ReactOnRails::Error, "Invalid RSC chunk format" unless chunk.is_a?(Hash)
+    begin
       "#{chunk.to_json}\n".html_safe
+    rescue JSON::GeneratorError => e
+      raise ReactOnRails::Error, "Failed to serialize RSC chunk: #{e.message}"
+    end
   end
 end

434-458: 🛠️ Refactor suggestion

Add fiber cleanup to prevent memory leaks.

The current implementation doesn't handle cleanup when fibers complete or fail, which could lead to memory leaks.

 def run_stream_inside_fiber
   unless ReactOnRails::Utils.react_on_rails_pro?
     raise ReactOnRails::Error,
           "You must use React on Rails Pro to use the stream_react_component method."
   end

   if @rorp_rendering_fibers.nil?
     raise ReactOnRails::Error,
           "You must call stream_view_containing_react_components to render the view containing the react component"
   end

   rendering_fiber = Fiber.new do
     stream = yield
-    stream.each_chunk do |chunk|
-      Fiber.yield chunk
+    begin
+      stream.each_chunk do |chunk|
+        Fiber.yield chunk
+      end
+    rescue StandardError => e
+      @rorp_rendering_fibers.delete(rendering_fiber)
+      raise e
+    ensure
+      # Clean up completed fibers
+      @rorp_rendering_fibers.delete(rendering_fiber) if stream.nil? || stream.closed?
     end
   end

   @rorp_rendering_fibers << rendering_fiber

   rendering_fiber.resume
 end
🧹 Nitpick comments (6)
lib/react_on_rails/helper.rb (6)

127-129: Consider using keyword arguments for clearer parameter handling.

Rather than mutating the options hash directly, consider using keyword arguments or a more functional approach to parameter handling.

-  # stream_react_component doesn't have the prerender option
-  # Because setting prerender to false is equivalent to calling react_component with prerender: false
-  options[:prerender] = true
-  options = options.merge(force_load: true) unless options.key?(:force_load)
-  run_stream_inside_fiber do
-    internal_stream_react_component(component_name, options)
+  # stream_react_component always uses prerender: true
+  # Setting prerender: false is equivalent to calling react_component with prerender: false
+  run_stream_inside_fiber do
+    internal_stream_react_component(component_name, **options, prerender: true, 
+                                    force_load: options.fetch(:force_load, true))

134-134: Fix trailing whitespace in documentation.

Remove trailing whitespace at the end of the line.

-# a special format designed by React for serializing server components and transmitting them 
+# a special format designed by React for serializing server components and transmitting them

252-256: Fix style issues in hash formatting.

There's inconsistent commas in the hash formatting.

   redux_store_data = { store_name: store_name,
                        props: props,
-                       force_load: force_load }
+                       force_load: force_load 
+                     }

639-639: Use double pipes instead of ternary for nil/false check.

Use double pipes (||) for simpler conditional logic.

-                                               "data-trace" => (render_options.trace ? true : nil),
+                                               "data-trace" => render_options.trace || nil,
🧰 Tools
🪛 RuboCop (1.73)

[convention] 639-639: Use double pipes || instead.

(Style/RedundantCondition)


642-642: Use double pipes instead of ternary for nil/false check.

Use double pipes (||) for simpler conditional logic.

-                                               "data-force-load" => (render_options.force_load ? true : nil))
+                                               "data-force-load" => render_options.force_load || nil)
🧰 Tools
🪛 RuboCop (1.73)

[convention] 642-642: Use double pipes || instead.

(Style/RedundantCondition)


668-668: Use double pipes instead of ternary for nil/false check.

Use double pipes (||) for simpler conditional logic.

-                                         "data-force-load" => (redux_store_data[:force_load] ? true : nil))
+                                         "data-force-load" => redux_store_data[:force_load] || nil)
🧰 Tools
🪛 RuboCop (1.73)

[convention] 668-668: Use double pipes || instead.

(Style/RedundantCondition)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4de5e78 and 6fd73e7.

📒 Files selected for processing (2)
  • lib/react_on_rails/helper.rb (13 hunks)
  • spec/dummy/spec/helpers/react_on_rails_helper_spec.rb (7 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • spec/dummy/spec/helpers/react_on_rails_helper_spec.rb
🧰 Additional context used
🧠 Learnings (1)
lib/react_on_rails/helper.rb (2)
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1644
File: lib/react_on_rails/helper.rb:190-197
Timestamp: 2025-02-18T13:08:01.477Z
Learning: RSC support validation in React on Rails Pro is handled through a chain of validations:
1. Pro version check in `run_stream_inside_fiber`
2. RSC support check during pack generation via `ReactOnRailsPro.configuration.enable_rsc_support`
3. RSC support validation during component registration
This makes additional validation in the helper methods unnecessary.
Learnt from: AbanoubGhadban
PR: shakacode/react_on_rails#1644
File: lib/react_on_rails/helper.rb:190-197
Timestamp: 2025-02-18T13:08:01.477Z
Learning: RSC support validation is handled in deeper level calls of the React on Rails Pro codebase, so it doesn't need to be validated again in the `rsc_payload_react_component` helper method.
🪛 RuboCop (1.73)
lib/react_on_rails/helper.rb

[convention] 639-639: Use double pipes || instead.

(Style/RedundantCondition)


[convention] 642-642: Use double pipes || instead.

(Style/RedundantCondition)


[convention] 668-668: Use double pipes || instead.

(Style/RedundantCondition)

⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: rspec-package-tests (newest)
  • GitHub Check: rspec-package-tests (oldest)
  • GitHub Check: build
  • GitHub Check: build-dummy-app-webpack-test-bundles (oldest)
🔇 Additional comments (5)
lib/react_on_rails/helper.rb (5)

134-182: Thorough documentation for React Server Components - good work!

The documentation for the RSC payload rendering is comprehensive and provides valuable context for developers, including examples and configuration details.


183-190: Implementation looks good - validation handled at deeper level.

Based on the learnings from earlier review cycles, RSC support validation is already handled at deeper levels through:

  1. Pro version check in run_stream_inside_fiber
  2. RSC support check during pack generation
  3. RSC support validation during component registration

670-678: Great enhancement for immediate store loading.

The implementation of immediate store loading through the force_load parameter is a useful enhancement that allows for better control over store hydration timing.


767-791: Improved Redux store initialization with dependency filtering.

The refactored initialize_redux_stores method now efficiently filters for store dependencies, which should improve performance when there are many registered stores but only a few are needed for a particular component.


752-752:

✅ Verification successful

Method name change from stream? to streaming?.

This appears to be a method name change in the RenderOptions class. Ensure that the corresponding method has been updated in the RenderOptions class to prevent runtime errors.


🏁 Script executed:

#!/bin/bash
# Check if the streaming? method exists in RenderOptions class
rg -A 5 "def streaming\?" lib/react_on_rails/react_component/render_options.rb

# Also check if there are any remaining references to stream?
rg "\.stream\?" --type ruby

Length of output: 319


RenderOptions Method Name Verified

  • Confirmed that RenderOptions#streaming? exists as expected in lib/react_on_rails/react_component/render_options.rb.
  • Verified that there are no lingering references to .stream? in the codebase.

This change should prevent any runtime errors.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (2)
node_package/src/ReactOnRailsRSC.ts (2)

35-53: 🛠️ Refactor suggestion

Enhance error logging to include stack traces in development environments.

Based on previous feedback and learnings, you should include error stack traces in development and test environments to aid debugging.

  onError: (err) => {
    const error = convertToError(err);
-   console.error("Error in RSC stream", error);
+   const isDevOrTest = process.env.NODE_ENV === 'development' || process.env.NODE_ENV === 'test';
+   console.error("Error in RSC stream", isDevOrTest ? error.stack : error);
    if (throwJsErrors) {
      emitError(error);
    }
    renderState.hasErrors = true;
    renderState.error = error;
  }

53-60: 🛠️ Refactor suggestion

Apply consistent error handling for manifest loading errors.

For consistency with the error handling approach in the onError callback, include stack traces in development and test environments for manifest loading errors as well.

}).catch((e) => {
  const error = convertToError(e);
+ const isDevOrTest = process.env.NODE_ENV === 'development' || process.env.NODE_ENV === 'test';
+ console.error("Error loading manifest", isDevOrTest ? error.stack : error);
  renderState.hasErrors = true;
  renderState.error = error;
  const htmlResult = handleError({ e: error, name: options.name, serverSide: true });
  const jsonResult = JSON.stringify(createResultObject(htmlResult, buildConsoleReplay(), renderState));
  return stringToStream(jsonResult);
});
🧹 Nitpick comments (1)
package.json (1)

101-102: Consider if explicit empty dependencies object is necessary.

You've added an explicit empty dependencies object. While this is valid, it's generally not necessary to include an empty dependencies object in package.json as it's the default when no dependencies are specified.

-  "packageManager": "yarn@1.22.22+sha512.a6b2f7906b721bba3d67d4aff083df04dad64c399707841b7acf00f6b133b7ac24255f2652fa22ae3534329dc6180534e98d17432037ff6fd140556e2bb3137e",
-  "dependencies": {}
+  "packageManager": "yarn@1.22.22+sha512.a6b2f7906b721bba3d67d4aff083df04dad64c399707841b7acf00f6b133b7ac24255f2652fa22ae3534329dc6180534e98d17432037ff6fd140556e2bb3137e"
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b1a3bbf and 109293f.

⛔ Files ignored due to path filters (1)
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
📒 Files selected for processing (8)
  • .github/workflows/examples.yml (1 hunks)
  • .github/workflows/lint-js-and-ruby.yml (1 hunks)
  • .github/workflows/main.yml (2 hunks)
  • .github/workflows/package-js-tests.yml (1 hunks)
  • jest.config.js (1 hunks)
  • node_package/src/RSCClientRoot.ts (1 hunks)
  • node_package/src/ReactOnRailsRSC.ts (1 hunks)
  • package.json (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
  • .github/workflows/package-js-tests.yml
  • .github/workflows/examples.yml
  • .github/workflows/lint-js-and-ruby.yml
  • .github/workflows/main.yml
  • node_package/src/RSCClientRoot.ts
  • jest.config.js
🧰 Additional context used
🧠 Learnings (1)
node_package/src/ReactOnRailsRSC.ts (1)
Learnt from: alexeyr-ci
PR: shakacode/react_on_rails#1644
File: node_package/src/ReactOnRailsRSC.ts:87-87
Timestamp: 2024-12-12T13:07:09.929Z
Learning: When handling errors in 'node_package/src/ReactOnRailsRSC.ts', include the error stack in error messages in development and test environments to aid debugging.
⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: rspec-package-tests (newest)
  • GitHub Check: build
  • GitHub Check: build-dummy-app-webpack-test-bundles (oldest)
  • GitHub Check: rspec-package-tests (oldest)
🔇 Additional comments (11)
node_package/src/ReactOnRailsRSC.ts (6)

5-18: LGTM - Good organization of imports.

The imports are well-organized, with clear separation between external dependencies, internal types, and utility functions.


20-25: LGTM - Well-implemented utility function.

The stringToStream function is a clean and effective implementation for converting strings to streams.


27-33: LGTM - Well-structured component rendering setup.

The initialization of rendering state with proper typing is well-implemented. The defaults for isShellReady, hasErrors, and result are appropriately set.


64-70: LGTM - Good integration with ReactOnRails.

The serverRenderRSCReactComponent method is cleanly integrated with the ReactOnRails object, using the stream rendering functionality and properly cleaning up the console history regardless of success or failure.


72-73: LGTM - Proper exports.

Exporting all types and the ReactOnRails object is the right approach for this module.


1-1:

❓ Verification inconclusive

Verify compatibility with the imported package.

Make sure the RSC package @shakacode-tools/react-on-rails-rsc is properly maintained and compatible with your React version. Previous review comments suggested this might have been a temporary or custom solution.


🏁 Script executed:

#!/bin/bash
# Check the npm package info for the RSC package
npm view @shakacode-tools/react-on-rails-rsc

# Check the package lockfile for actual version resolution
if [ -f "yarn.lock" ]; then
  grep -A 5 "@shakacode-tools/react-on-rails-rsc" yarn.lock
elif [ -f "package-lock.json" ]; then
  grep -A 5 "@shakacode-tools/react-on-rails-rsc" package-lock.json
fi

Length of output: 1016


Attention: RSC Package Compatibility Verification

The package @shakacode-tools/react-on-rails-rsc is not published to the public npm registry and is instead being resolved from GitHub Packages (locked at version 19.0.0 as shown in your lockfile). Please verify that this specific version (and its dependency on react-server-dom-webpack v19.0.0) is actively maintained and fully compatible with your current React version. Given that previous notes indicated this might be a temporary or custom solution, it’s important to reassess its long-term suitability for your project.

package.json (5)

8-14: LGTM - Well-structured exports configuration.

The exports configuration clearly defines the entry points for different environments, including the new React Server Components support via the react-server condition and the new server component registration paths.


24-26: LGTM - Appropriate testing libraries.

The addition of Testing Library packages will improve the quality of React component tests.


47-48: LGTM - Testing utilities for modern React applications.

Adding jest-fetch-mock and jsdom is appropriate for testing modern React applications, especially when dealing with server components that might involve fetch operations.


3-3:

✅ Verification successful

Ensure version meets semantic versioning requirements.

The version 15.0.0-alpha.2 correctly indicates this is a major version change with breaking changes. Make sure to thoroughly document these changes in the CHANGELOG and ensure all tests pass before releasing.


🏁 Script executed:

#!/bin/bash
# Check if CHANGELOG.md contains information about version 15.0.0
grep -A 10 "15.0.0" CHANGELOG.md || echo "No entry for version 15.0.0 found in CHANGELOG.md"

Length of output: 594


Version and CHANGELOG verification passed.

  • The package.json entry "15.0.0-alpha.2" correctly follows semantic versioning for a prerelease with breaking changes.
  • The corresponding CHANGELOG.md entry for [15.0.0-alpha.2] confirms that the changes have been documented.
  • Please ensure all tests pass before releasing.

23-23:

✅ Verification successful

Verify compatibility with the specific RSC version.

You're using a fixed major version (^19.0.0) of @shakacode-tools/react-on-rails-rsc. Ensure this version is compatible with the React version you're using (React 19 in devDependencies).


🌐 Web query:

Is React Server Components fully supported in React 19?

💡 Result:

React Server Components (RSCs) are fully supported in React 19 as a stable feature, marking a major shift in React's architecture. Here's a detailed breakdown:


Key Features and Implementation

  1. Stable Core Functionality
    RSCs are now production-ready in React 19, enabling components to render exclusively on the server. This reduces client-side JavaScript, improves initial load times, and allows direct server-side data fetching without exposing sensitive logic to the client[1][2][9].
    Example:

    // Server Component (file ends with .server.jsx)
    async function ProductDetails({ id }) {
      const product = await db.query(`SELECT * FROM products WHERE id = ${id}`);
      return <div>{product.name}</div>;
    }
  2. Integration with Frameworks
    While React 19 stabilizes RSCs, frameworks like Next.js handle the underlying bundler/framework APIs. These APIs do not follow semver in React 19.x, so frameworks must pin specific React versions or use Canary releases for compatibility[1][4][10].

  3. Async Server Components
    Server Components can use async/await for data fetching, enabling streaming HTML and partial rendering via <Suspense>[2][3][7].
    Example:

    async function Page({ slug }) {
      const post = await fetchPost(slug);
      return <Article post={post} />;
    }
  4. Directives for Clarity

    • 'use client': Marks Client Components (required for interactivity/state).
    • 'use server': Defines Server Actions (server-side functions callable from the client)[9][10].

Benefits and Use Cases

  • Performance: Pre-rendered HTML reduces client-side load[5][7].
  • Security: Sensitive operations (e.g., database access) stay server-side[6][10].
  • SEO: Fully rendered HTML improves search engine indexing[5][9].

Limitations and Considerations

  • No Standalone Server Runtime: RSCs require a server environment (e.g., Node.js) and cannot run in static sites without frameworks like Next.js[6].
  • Interactivity: Server Components cannot use state/effects; pair them with Client Components for dynamic features[3][10].
  • Tooling Maturity: While RSCs are stable, some bundler/framework integrations remain in flux[1][4].

Example Architecture

// Server Component (ProductList.server.jsx)
async function ProductList() {
  const products = await db.query('SELECT * FROM products');
  return (
    <ul>
      {products.map((product) => (
        <li key={product.id}>
          <ProductDetails id={product.id} /> {/* Server Component */}
          <AddToCartButton productId={product.id} /> {/* Client Component */}
        </li>
      ))}
    </ul>
  );
}

// Client Component (AddToCartButton.client.jsx)
'use client';
function AddToCartButton({ productId }) {
  const [isPending, startTransition] = useTransition();
  const handleClick = () => {
    startTransition(() => addToCart(productId)); // Server Action
  };
  return <button onClick={handleClick}>Add to Cart</button>;
}

// Server Action (actions.js)
'use server';
async function addToCart(productId) {
  await db.query('INSERT INTO cart (...) VALUES (...)');
}

Conclusion

React 19 fully supports Server Components, offering a server-first approach for performance and security. While the core feature is stable, developers should use frameworks like Next.js for seamless integration until React’s underlying tooling APIs mature.

Citations:


Compatibility Confirmed – No Changes Needed
The web query confirms that React Server Components are fully supported in React 19. With the dependency set to ^19.0.0 for @shakacode-tools/react-on-rails-rsc, everything aligns correctly with React 19 as specified in your devDependencies.

  • No changes to the package version are necessary at this time.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
CHANGELOG.md (1)

19-28: New React Server Components Support Entry

The new "#### Added" section clearly details the introduction of React Server Components support including key benefits such as reduced client bundle sizes and new data-fetching patterns. It also references the full tutorial and links to [PR 1644].

Please ensure that any new public APIs or configuration changes related to RSC support are consistently documented elsewhere (e.g. in the API docs or migration guides) to help users understand how to leverage this new feature.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 109293f and 233aefe.

📒 Files selected for processing (2)
  • CHANGELOG.md (1 hunks)
  • package.json (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • package.json
⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: dummy-app-integration-tests (newest)
  • GitHub Check: dummy-app-integration-tests (oldest)
  • GitHub Check: rspec-package-tests (newest)
  • GitHub Check: rspec-package-tests (oldest)
🔇 Additional comments (1)
CHANGELOG.md (1)

29-42: Hydration Improvements and Breaking Changes Notice

This section outlines important improvements to component and store hydration—such as immediate hydration without waiting for page load, support for async scripts, and the update of ReactOnRails.reactOnRailsPageLoaded to an async function—as well as a significant configuration change where force_load now defaults to true.

Because these are breaking changes, please double-check that the upgrade/migration documentation is updated to clearly instruct users on any necessary code adjustments or behavior changes. It might also help to point out any potential edge cases for users who previously relied on the old synchronous behavior.

@AbanoubGhadban AbanoubGhadban changed the title [WIP] Add support for RSC Add support for RSC Mar 6, 2025
- Add description for unreleased changes in CHANGELOG
- Remove unused entry from knip configuration
- Add jsdom as a development dependency in knip config
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
CHANGELOG.md (4)

20-28: Clarify the New RSC Feature Entry
The new “#### Added” section clearly lists the introduction of React Server Components support with concise bullet points. For improved clarity, consider adding brief migration instructions (or links to detailed docs) on any configuration changes that users might need to adopt.


30-42: Detail Breaking Changes and Hydration Improvements
The “#### Improved (Breaking)” section effectively explains the changes related to component/store hydration and specifies that ReactOnRails.reactOnRailsPageLoaded is now async and that force_load now defaults to true. It would be beneficial to include a note or link to migration context so that users understand how these breaking changes might affect their setup.


1-5: Version Bump Visibility
Although the AI summary mentions a new version (15.0.0‑alpha.2), the changelog currently shows an “Unreleased” section followed by older version sections (e.g. [14.2.0]). To avoid confusion, please ensure that the version bump (if it is indeed part of this release) is prominently noted once finalized.


43-44: Maintaining Changelog Readability
The changelog is very comprehensive and detailed. As ongoing changes accumulate, consider whether archiving older versions or summarizing them in a separate release-notes document might help new users focus more quickly on recent (and breaking) changes.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4eb472d and eb1daef.

📒 Files selected for processing (2)
  • CHANGELOG.md (1 hunks)
  • knip.ts (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • knip.ts
⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: dummy-app-integration-tests (newest)
  • GitHub Check: dummy-app-integration-tests (oldest)
  • GitHub Check: rspec-package-tests (oldest)
  • GitHub Check: rspec-package-tests (newest)

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
spec/dummy/spec/helpers/react_on_rails_helper_spec.rb (1)

333-333: Consider redux store hydration implications

Adding data-force-load="true" to redux store scripts changes how stores are initialized. This could affect applications that depend on explicit store initialization timing. Ensure this change is documented in your migration guide.

Consider adding a test case that explicitly tests the redux store with force_load: false to ensure both configurations work correctly.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between da1fa52 and 6339773.

📒 Files selected for processing (1)
  • spec/dummy/spec/helpers/react_on_rails_helper_spec.rb (8 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: dummy-app-integration-tests (newest)
  • GitHub Check: dummy-app-integration-tests (oldest)
  • GitHub Check: rspec-package-tests (newest)
  • GitHub Check: rspec-package-tests (oldest)
🔇 Additional comments (3)
spec/dummy/spec/helpers/react_on_rails_helper_spec.rb (3)

307-307:

❓ Verification inconclusive

Confirm the inverted force-load behavior is intentional

The tests now expect opposite behavior for the force_load option - components are force-loaded by default, and force_load: false disables this behavior. This is a significant change from the previous behavior and should be well-documented.

Also applies to: 311-315, 317-321


🏁 Script executed:

#!/bin/bash
# Search for implementation of force_load option to verify the behavior change
rg "force.?load" --type ruby | grep -v spec

Length of output: 1541


Inverted Force-load Behavior Verification

The updated tests now reflect that components are force-loaded by default—this is achieved by setting force_load: true in the configuration (see lib/react_on_rails/configuration.rb) and propagating this default in the helper (see lib/react_on_rails/helper.rb). Please confirm that this inversion (i.e., defaulting to force-loading unless explicitly disabled via force_load: false) is intentional and that the change is thoroughly documented given its impact on component hydration behavior.


53-53:

❓ Verification inconclusive

Consider the performance impact of disabling script deferrals

The change from defer: true to defer: false means JavaScript will execute immediately rather than waiting for document parsing to complete, which might impact page load performance. This change is likely related to supporting React Server Components (RSC), but consider documenting this change and its rationale.


🏁 Script executed:

#!/bin/bash
# Search for other instances of append_javascript_pack_tag to ensure consistent behavior
rg "append_javascript_pack_tag.*defer" --type ruby

Length of output: 224


Performance Impact & Documentation of defer Change

We've confirmed via the test that the helper invocation now uses { defer: false }:

expect(helper).to have_received(:append_javascript_pack_tag).with("generated/component_name", { defer: false })

Since disabling script deferral causes JavaScript to execute immediately instead of waiting for document parsing to complete, this may affect page load performance. Given that this change likely supports React Server Components, please document the rationale for switching to non-deferred execution and note any potential performance trade-offs.


146-148:

✅ Verification successful

Verify the new force-load behavior in documentation

The addition of data-force-load="true" to component scripts indicates a change in the default behavior for component loading. This appears to support React Server Components but should be properly documented.

Also applies to: 155-157


🏁 Script executed:

#!/bin/bash
# Check documentation for force-load behavior information
rg "force.?load" --type md

Length of output: 825


Ensure Documentation Consistency for force_load Behavior

The updated component code now uses data-force-load="true", which aligns with our recent default change—force_load now defaults to true (previously false). The CHANGELOG clearly documents this behavior change (including details on disabling it via force_load: false and referencing PR #1620). Please double-check that all user-facing documentation (e.g., README, guides, helper usage notes) also reflects this update, especially regarding any context around React Server Components. Note that this verification applies to changes at both lines 146–148 and 155–157.

- Add comprehensive release notes for version 15.0.0
- Highlight major features: React Server Components support and improved component hydration
- Document breaking changes related to component hydration and store dependencies
- Summarize key improvements in component and store hydration performance
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
docs/release-notes/15.0.0.md (2)

20-29: Breaking Changes Section: Minor Grammar and Style Adjustments Recommended

Several points need minor improvements for clarity and consistency:

  • Line 23: Consider hyphenating “full-page load” when used as a compound adjective. For example:
    -... without waiting for the full page load.
    +... without waiting for the full-page load.
  • Line 25: The verb should be “makes” instead of “make.”
    -The `force_load` configuration make `react-on-rails` hydrate...
    +The `force_load` configuration makes `react-on-rails` hydrate...
  • Line 28: Rephrase for better grammatical flow. A suggested rewrite:
    -Redux store support `force_load` option now and it uses `config.force_load` value as the default value. Which means that the redux store will hydrate immediately as soon as its server-side data reaches the client.
    +Redux store support for the `force_load` option now uses `config.force_load` as its default value, meaning that the Redux store hydrates immediately once its server-side data reaches the client.

These improvements will enhance readability and maintain consistency.

🧰 Tools
🪛 LanguageTool

[uncategorized] ~23-~23: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...l hydrate early without waiting for the full page load. This improves performance by elim...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[uncategorized] ~25-~25: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...ded. - The force_load configuration make react-on-rails hydrate components imm...

(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)


[uncategorized] ~25-~25: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...hes the client, without waiting for the full page load. - If you want to keep the previ...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[style] ~27-~27: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...zers/react_on_rails.rbfile. - If we want to keep the original behavior offorce_lo...

(REP_WANT_TO_VB)


[uncategorized] ~28-~28: The grammatical number of this noun doesn’t look right. Consider replacing it.
Context: ...ce_loadconfiguration. - Redux store supportforce_loadoption now and it usesco...

(AI_EN_LECTOR_REPLACEMENT_NOUN_NUMBER)


[uncategorized] ~28-~28: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...ux store support force_load option now and it uses config.force_load value as th...

(COMMA_COMPOUND_SENTENCE)


61-76: Code Example for Declaring Store Dependencies: Verify Inline Comment Style

The ERB code example is informative and includes inline comments (e.g., on lines 69 and 73) to clarify behavior. However, please verify that using HTML comments inside the JavaScript object literals within the ERB file does not inadvertently lead to rendering issues when users copy and paste the code. You might consider either removing these inline comments in the production example or formatting them in a way that does not affect the syntax.

CHANGELOG.md (1)

23-26: Added Features Section Clarity
The new features are clearly listed under "#### Added":

  • React Server Components Support (Pro Feature)
  • Improved component and store hydration performance

Consider adding or referencing a brief note about any migration details if these features require configuration adjustments or document updates in the API docs.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6339773 and 51e1341.

📒 Files selected for processing (2)
  • CHANGELOG.md (1 hunks)
  • docs/release-notes/15.0.0.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/release-notes/15.0.0.md

[uncategorized] ~23-~23: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...l hydrate early without waiting for the full page load. This improves performance by elim...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[uncategorized] ~25-~25: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...ded. - The force_load configuration make react-on-rails hydrate components imm...

(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)


[uncategorized] ~25-~25: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...hes the client, without waiting for the full page load. - If you want to keep the previ...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[style] ~27-~27: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...zers/react_on_rails.rbfile. - If we want to keep the original behavior offorce_lo...

(REP_WANT_TO_VB)


[uncategorized] ~28-~28: The grammatical number of this noun doesn’t look right. Consider replacing it.
Context: ...ce_loadconfiguration. - Redux store supportforce_loadoption now and it usesco...

(AI_EN_LECTOR_REPLACEMENT_NOUN_NUMBER)


[uncategorized] ~28-~28: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...ux store support force_load option now and it uses config.force_load value as th...

(COMMA_COMPOUND_SENTENCE)

⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: dummy-app-integration-tests (oldest)
  • GitHub Check: dummy-app-integration-tests (newest)
  • GitHub Check: rspec-package-tests (oldest)
  • GitHub Check: rspec-package-tests (newest)
🔇 Additional comments (8)
docs/release-notes/15.0.0.md (6)

1-2: Release Note Title and Version Declaration

The header clearly states the release version (15.0.0). This is important for tracking changes and communicating the update.


3-11: React Server Components (RSC) Feature Section is Well-Documented

The section introduces RSC support effectively and even provides a link to the full tutorial for React on Rails Pro. Ensure that any further documentation (for example, in configuration files or usage examples) matches this description.


12-19: Improved Component Hydration Section is Clear

The explanation regarding immediate hydration of components and stores is well-explained. The removal of the need for the defer attribute is a clear takeaway.


30-40: Async Function Update for reactOnRailsPageLoaded() is Effectively Communicated

The before-and-after sample code blocks clearly illustrate the change to an async function. Ensure that users update their calls accordingly by awaiting the promise.


42-60: Redux Store Dependencies Section Provides Clear Guidance

The section on explicitly declaring store dependencies is well-detailed. This clear explanation should help users optimize hydration behavior.


80-83: Pull Requests Section Accurately References Related Work

Listing associated PRs with direct links is very helpful for context. Confirm that all links are up to date and that the descriptions accurately reflect the changes.

CHANGELOG.md (2)

21-22: Release Notes Link Added – Verify Link Validity
A release notes link has been inserted:

See [Release Notes](docs/release-notes/15.0.0.md) for full details.

Please confirm that the linked file is published and the URL is correct once the RSC documentation merge is complete.


27-31:

❓ Verification inconclusive

Breaking Changes – Ensure Documentation and Migration Guidance
The "#### Breaking Changes" section highlights that:

  • ReactOnRails.reactOnRailsPageLoaded is now asynchronous.
  • The force_load configuration now defaults to true.
  • The defer_generated_component_packs configuration now defaults to false.

It is important to ensure that these breaking changes are also clearly communicated in the migration guide and relevant API documentation so that developers understand how to update their usage.


Could you please run the above script and share the output? This will help verify whether the breaking changes documented in the CHANGELOG are accompanied by updated migration guidance.


🏁 Script executed:

#!/bin/bash
# Search for any markdown files mentioning "migration guide" to verify if there's an existing migration guide.
rg -i "migration guide" -g "*.md"

Length of output: 382


Documentation Update: Verify Migration Guide and API Docs for Breaking Changes
The changelog now lists these critical updates:

  • ReactOnRails.reactOnRailsPageLoaded is now asynchronous,
  • force_load configuration defaults to true, and
  • defer_generated_component_packs configuration defaults to false.

Since the changelog already includes a reference to the migration guide, please ensure that the guide and any relevant API documentation are updated to clearly explain these changes and the necessary migration steps for developers.

@AbanoubGhadban AbanoubGhadban requested a review from justin808 March 7, 2025 14:29
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
docs/release-notes/15.0.0.md (1)

20-29: Detailed Breakdown of Breaking Changes for Component Hydration

This section provides a thorough explanation of the configuration changes:

  • The descriptions are clear about the new defaults for defer_generated_component_packs (now false) and force_load (now true).
  • On line 27, the phrasing is repetitive with nearby explanations. Consider varying the language to maintain reader engagement.
  • On line 28, the explanation is split into two sentences, where the second sentence ("Which means that…") reads like a fragment. It would be clearer to combine these sentences. For example:
-Redux store support `force_load` option now and it uses `config.force_load` value as the default value. Which means that the redux store will hydrate immediately as soon as its server-side data reaches the client. You can override this behavior for individual redux stores by setting `force_load: false` in the `redux_store` helper.
+Redux store support for the `force_load` option now uses `config.force_load` as its default, meaning that the Redux store will hydrate immediately when its server-side data reaches the client. You can override this behavior for individual redux stores by setting `force_load: false` in the `redux_store` helper.

Additionally, consider reviewing compound adjectives—e.g., if “full page load” is used as a modifier, hyphenating it as “full‑page load” may improve clarity (if it aligns with your style guidelines).

🧰 Tools
🪛 LanguageTool

[uncategorized] ~23-~23: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...l hydrate early without waiting for the full page load. This improves performance by elim...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[uncategorized] ~25-~25: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...hes the client, without waiting for the full page load. - If you want to keep the previ...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[style] ~27-~27: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...zers/react_on_rails.rbfile. - If we want to keep the original behavior offorce_lo...

(REP_WANT_TO_VB)


[uncategorized] ~28-~28: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...ux store support force_load option now and it uses config.force_load value as th...

(COMMA_COMPOUND_SENTENCE)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4c5a0f2 and 018f404.

📒 Files selected for processing (1)
  • docs/release-notes/15.0.0.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/release-notes/15.0.0.md

[uncategorized] ~23-~23: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...l hydrate early without waiting for the full page load. This improves performance by elim...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[uncategorized] ~25-~25: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...hes the client, without waiting for the full page load. - If you want to keep the previ...

(EN_COMPOUND_ADJECTIVE_INTERNAL)


[style] ~27-~27: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...zers/react_on_rails.rbfile. - If we want to keep the original behavior offorce_lo...

(REP_WANT_TO_VB)


[uncategorized] ~28-~28: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...ux store support force_load option now and it uses config.force_load value as th...

(COMMA_COMPOUND_SENTENCE)

⏰ Context from checks skipped due to timeout of 90000ms (4)
  • GitHub Check: dummy-app-integration-tests (newest)
  • GitHub Check: dummy-app-integration-tests (oldest)
  • GitHub Check: rspec-package-tests (newest)
  • GitHub Check: rspec-package-tests (oldest)
🔇 Additional comments (4)
docs/release-notes/15.0.0.md (4)

1-11: Clear Introduction for React Server Components Support

The release notes clearly introduce the new React Server Components feature with concise bullet points and a helpful link to the full tutorial. This section sets the right context for the major update.


12-19: Concise Overview of Improved Component Hydration

The bullet points effectively summarize the enhancements in component and store hydration. Consider explicitly noting how the removal of the defer requirement helps prevent race conditions during page load.


30-40: Clarification on Async Behavior of reactOnRailsPageLoaded()

The before-and-after code example is clear and does a good job of illustrating the move to an async function. Emphasize to users in the documentation that they must now use await with ReactOnRails.reactOnRailsPageLoaded() to ensure proper hydration timing.


42-79: Comprehensive Explanation of Store Dependencies for Components

The section excellently details the problem with deferred Redux store hydration and provides a step-by-step solution using clear ERB examples. This guidance should help users understand the need to explicitly declare store dependencies for optimized hydration.

@justin808 justin808 merged commit 4dee1ff into master Mar 7, 2025
11 checks passed
@justin808 justin808 deleted the abanoubghadban/pro362-add-support-for-RSC branch March 7, 2025 23:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants