Walkthrough

Clarifies that railsContext.rorPro signals the React on Rails Pro gem is installed (not that a Pro license is validated). Changes update docs, type defs, client variable naming and warnings, Ruby utils/messages, and tests; no runtime control-flow or license-validation behavior changed.

Changes

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I hopped through docs and code so spry,
"Pro installed" I whisper, not a license lie.
A tiny rename, a clearer sign,
Signals snug as carrots in a line,
I thump for clarity — bright and spry 🥕

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR is a pure semantics/documentation clarification: railsContext.rorPro signals that the React on Rails Pro gem is installed, not that a license token is valid. The change is propagated consistently across Ruby source comments, TypeScript type definitions, a local variable rename in ClientSideRenderer.ts, and two documentation files.

Key changes:

• react_on_rails/lib/react_on_rails/utils.rb: Consolidates a confusingly duplicated (and partially contradictory) comment on react_on_rails_pro? into a single, accurate description.
• packages/react-on-rails/src/types/index.ts: Adds a two-line clarifying comment above rorPro: boolean in RailsContext.
• packages/react-on-rails-pro/src/ClientSideRenderer.ts: Renames local variable hasProLicense → hasProInstalled; however, the adjacent comment on line 105 still reads "without Pro license" and was not updated to match the new semantics.
• react_on_rails_pro/LICENSE_SETUP.md: Updates the "License Validation" list to state the browser package receives a Pro-installed signal — but the section heading still implies all three items perform license validation, creating a minor inconsistency.

Confidence Score: 5/5

• This PR is safe to merge — it contains no logic changes, only comment/documentation clarifications and a local variable rename.
• All changes are non-functional: comments, documentation, and a local variable rename with no exported API impact. No tests need updating, no behavior is altered. Two minor style inconsistencies remain (a stale comment and a misleading section heading in the docs) but neither blocks correctness.
• No files require special attention; minor wording follow-ups in packages/react-on-rails-pro/src/ClientSideRenderer.ts (line 105) and react_on_rails_pro/LICENSE_SETUP.md (line 84) are the only items worth addressing before merge.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Rails Server] -->|"react_on_rails_pro? (gem presence check)"| B{Pro gem installed?}
    B -- Yes --> C["rorPro: true\n(installation signal only)"]
    B -- No --> D["rorPro: false"]
    C --> E[railsContext serialized to client]
    D --> E
    E --> F[Browser: ClientSideRenderer]
    F --> G{isImmediateHydrationRequested\n&& !hasProInstalled?}
    G -- Yes --> H[console.warn + fallback to standard hydration]
    G -- No --> I[Normal hydration / rendering flow]

    style C fill:#d4edda,stroke:#28a745
    style D fill:#f8d7da,stroke:#dc3545
    style H fill:#fff3cd,stroke:#ffc107

_{Last reviewed commit: 15978ab}

Overall this is a clean, well-scoped clarification. The rename of hasProLicense → hasProInstalled and the comment consolidation in utils.rb are the most valuable changes. A couple of small nits:

1. Stale comment in ClientSideRenderer.ts (inline): The // Handle immediate_hydration feature usage without Pro license comment on line 105 wasn't updated alongside the variable rename, so it still says "license" instead of "installed."

2. Slight ambiguity in types/index.ts (inline): // This is not a signal that the current license token is valid can be read as "rorPro carries no meaningful signal" rather than "it signals installation, not license state." Suggested rewording in the inline comment.

3. LICENSE_SETUP.md section context (nit, no inline needed): The entry sits under a ## License Validation heading but now explicitly calls out that rorPro is not a license-validation mechanism. Worth keeping in mind — if the section is ever restructured, this bullet would fit better under a "Pro detection" heading. Not a blocker.

Otherwise LGTM — no runtime behaviour is changed, and the semantics are now accurately documented across Ruby, TypeScript, and docs.

size-limit report 📦

This is a clean, well-scoped documentation and naming clarification with no runtime behavior changes. Critical fix in utils.rb: the old comment block was self-contradictory — the first line said 'Checks if React on Rails Pro is installed and licensed' while the next two lines contradicted it. The new consolidated comment is accurate. The variable rename (hasProLicense to hasProInstalled) is semantically correct, and the TypeScript type comment clearly states both what the field means and what it does not mean. Changes are consistent across Ruby, TypeScript, and docs. Minor nit: the comment added in render-functions-and-railscontext.md uses terse phrasing ('Pro package installed (not license-valid state)') — something like 'True if the React on Rails Pro gem is installed (not a license-validity check)' would be slightly clearer for docs readers. Overall, worthwhile fix for a genuine semantic confusion.

Review

Overall this is a clean, low-risk documentation/naming clarification. One issue will break CI and a few minor nits are worth addressing.

Bug: test spec regex no longer matches the renamed warning message

react_on_rails/spec/react_on_rails/utils_spec.rb line 1050 still expects the old text:

.with(/immediate_hydration: true requires a React on Rails Pro license/)

But the renamed method in utils.rb now produces:

immediate_hydration: true requires the React on Rails Pro gem to be installed

These strings do not match, so this spec will fail on CI. The fix is to update the matcher to:

.with(/immediate_hydration: true requires the React on Rails Pro gem to be installed/)

Minor: spec context labels are semantically stale

The two describe blocks at lines 1014 and 1043 of utils_spec.rb are still labelled "with Pro license" and "without Pro license". Updating them to "with Pro installed" / "without Pro installed" would keep them consistent with the rest of the PR.

Minor: comment placement in helper.rb

The new comment was inserted before the existing TODO, separating the TODO from the field it refers to. Suggest placing it after the TODO, or consolidating both into a single comment block.

The rename itself and all docs/type updates look accurate and consistent.

PR Review: docs: clarify railsContext.rorPro semantics

Overall Assessment: This is a well-scoped, low-risk documentation and naming clarification. The intent — distinguishing "Pro is installed" from "license is valid" — is correct and the changes are consistently applied across Ruby, TypeScript types, tests, and documentation.

What's done well:

• The old immediate_hydration_pro_license_warning method name is fully replaced by immediate_hydration_pro_install_warning with no missed references in the codebase.
• Test expectations are updated to match the new warning text string.
• The TypeScript type comment addition in RailsContext is clear and accurate.
• LICENSE_SETUP.md section update correctly clarifies the browser package behavior.

One inconsistency to address:
The IMMEDIATE_HYDRATION_PRO_WARNING constant in ClientSideRenderer.ts (lines 31–33) still uses "license" language — "requires a React on Rails Pro license" and "to get a license". This constant is emitted precisely when hasProInstalled is false (i.e., Pro is not installed), so the message directly contradicts the semantic clarification introduced elsewhere in this PR. The message should be updated to say something like "requires the React on Rails Pro package to be installed" for consistency.

No other issues found.

Updated to align with package-install semantics (no license-validity wording).

Updated the immediate_hydration warning text to describe Pro package installation requirements (instead of license-validity wording).

Review

The intent of this PR is clear and the direction is correct. The test updates are thorough and consistent. A couple of things worth addressing:

1. Potentially confusing warning message in ClientSideRenderer.ts

The updated warning says the 'immediate_hydration' feature requires the React on Rails Pro package to be installed. But this warning fires when railsContext.rorPro is false, meaning the server-side Ruby gem is not installed. The file emitting the warning is itself inside the react-on-rails-pro JS package, so the package clearly IS installed from the user's perspective. The Ruby-side warning in utils.rb correctly says 'gem'. The TS message should be aligned, e.g.: 'requires the React on Rails Pro gem to be installed on the server.'

2. Comment ordering in helper.rb

The new comment is inserted between the rorVersion line and an existing TODO. The TODO is specifically about rorPro (replace boolean with version string in v13). Having the new explanatory comment sandwiched between them makes the TODO look like a continuation of the new comment. Moving the new comment after the TODO, or merging them, would read more naturally.

3. CHANGELOG

This PR renames a public-facing Ruby method (immediate_hydration_pro_license_warning to immediate_hydration_pro_install_warning) and changes warning message strings that third-party code might match against. A brief entry under [Unreleased] > Changed would be helpful.

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Overall: Clean, low-risk docs/naming clarification — no behavior change, all call sites updated, tests aligned. Three minor points: (1) URL inconsistency — Ruby warning uses www.shakacode.com/react-on-rails-pro/ while TypeScript uses shakacode.com/react-on-rails-pro (both touched in this PR, easy to align). (2) immediate_hydration_pro_install_warning is a module-level self. method so technically public — consider private_class_method since it is an internal helper. (3) No CHANGELOG entry — the renamed public Ruby method and updated user-visible warning text arguably merit a short Unreleased entry per project conventions.

Review: docs: clarify railsContext.rorPro semantics

Overall: This is a clean, well-scoped documentation and semantic-clarity PR. The changes are low-risk (no behavioral changes, only comment/warning-text/local-variable updates), and the naming alignment across Ruby and TypeScript is a clear improvement.

A few small observations:

Backward-compatible alias (immediate_hydration_pro_license_warning)

The alias is preserved in utils.rb, which is a good safety net — but a quick search shows the old method name has no external callers in the codebase (only the alias definition itself and the new test for it). If this method is considered internal API, the alias adds maintenance surface without real benefit. If it is kept (e.g. for downstream gems or private forks), a @deprecated YARD tag would guide callers toward the new name before it's eventually removed.

rorProVersion comment placement

The new comment on rorProVersion in types/index.ts is helpful and accurate. One micro-nit: the comment sits between two closely related fields (rorPro / rorProVersion), so placing both comments above rorPro (and making the relationship explicit there) would read more naturally — though this is purely stylistic.

Tests

The new test for the backward-compat alias (utils_spec.rb:1013–1020) validates the return-value equality, which is correct. It would be marginally stronger to verify the delegation with expect(described_class).to receive(:immediate_hydration_pro_install_warning)..., but given the simplicity of the alias the current approach is fine.

All CI test updates match the new warning text correctly. No security, performance, or correctness issues found.

PR Review: docs: clarify railsContext.rorPro semantics

Overall this is a clean, well-scoped documentation/naming PR. The semantic distinction between "Pro gem installed" vs. "Pro license valid" is important and the changes accurately reflect it across Ruby, TypeScript, docs, and tests.

One factual inaccuracy in CHANGELOG.md that needs correction (see inline comment):

The changelog entry claims: "added a backward-compatible alias for the previous warning helper method name", but no alias was added. The method immediate_hydration_pro_license_warning was simply renamed to immediate_hydration_pro_install_warning with no backward-compatible shim. Since the method is a public self. method on ReactOnRails::Utils, any external caller using the old name would get a NoMethodError.

A quick grep confirms no external callers exist within this repo (neither OSS nor Pro), so there is no actual breakage here — but the CHANGELOG entry should be corrected to remove the alias claim to avoid confusion.

Everything else looks good:

• Variable rename hasProLicense → hasProGemInstalled in ClientSideRenderer.ts is accurate.
• Warning messages are updated consistently in both Ruby and TypeScript.
• Test descriptions and expected strings all match the renamed method's output.
• LICENSE_SETUP.md clarification adds useful context for users wondering why the browser package doesn't independently validate licenses.
• No runtime behavior changes — this is purely documentation and naming.

PR Review: railsContext.rorPro semantics clarification

Clean, low-risk PR. Changes are internally consistent and semantically correct. A few minor observations (two posted as inline comments).

No issues found:

• No stale references to old method/variable names in the codebase
• No backward-compat concerns (renamed Ruby method has no external callers)
• All tests updated to match new warning text
• Runtime behaviour unchanged

Minor observations:

1. Wording inconsistency between Ruby and TS warnings (inline): The TS warning says 'on the server' but the Ruby warning does not. Helpful context in client-side code, but aligning them would be consistent. Not blocking.

2. rorProVersion comment phrasing (inline): 'Present when rorPro is true' implies the field is always defined when rorPro is true, but it is optional. 'Set when the Pro gem is installed' is slightly more precise. Not blocking.

3. CHANGELOG placement: The entry is under Changed (OSS section) above the Pro section. Since this also touches Pro-specific code, a cross-reference in the Pro section could help Pro users. Not blocking.

Overall: LGTM with the above as optional polish.