Skip to content

Migrate admin topics to React on Rails#975

Open
justin808 wants to merge 6 commits into
EFForg:mainfrom
justin808:codex/react-on-rails-admin-topics-slice
Open

Migrate admin topics to React on Rails#975
justin808 wants to merge 6 commits into
EFForg:mainfrom
justin808:codex/react-on-rails-admin-topics-slice

Conversation

@justin808

@justin808 justin808 commented Apr 12, 2026

Copy link
Copy Markdown

What changed

  • migrated the /admin/topics mount from react-rails to react_on_rails
  • moved the Rails-side prop building into Admin::TopicsHelper and mounted the component with explicit props:
  • narrowed the JS setup to a page-scoped admin_topics pack instead of a broader layout-wide bundle assumption
  • removed the unused SSR bundle and extra generator dev-helper files from the first pass
  • updated the repo Dockerfile to provide Node 20 plus Yarn 1.22.22 in the app image so the repo-supported container path works with shakapacker@10
  • refreshed the test setup so request specs do not silently reuse a stale packs-test manifest when the migrated entrypoint changes

Why

I maintain both react-rails and react_on_rails, and for actively maintained Rails + React apps we recommend moving to React on Rails because it is the better-supported path for modern Rails/React integration and incremental migrations.

For this repo, the main value is maintainability and operational clarity rather than a wholesale frontend rewrite:

  • the admin topics page now has an explicit Rails-owned prop boundary instead of relying on the older react-rails mount contract
  • the React on Rails entrypoint is route-scoped, which makes the migrated slice easier to reason about and test in isolation
  • the branch no longer carries the extra SSR/dev scaffolding from the initial generator-heavy pass, so the PR is closer to the actual page migration
  • the repo-supported Docker path now validates the same modern JS runtime the branch depends on, instead of leaving the migration in a "works on one machine" state

Relevant docs:

Validation

  • env NODE_ENV=production ./node_modules/.bin/webpack --config config/webpack/webpack.config.js
  • docker compose --progress plain -f docker-compose.yml.example build app
  • docker compose -f docker-compose.yml.example run --rm -e RAILS_ENV=test app bundle exec rails db:test:prepare
  • docker compose -f docker-compose.yml.example run --rm -e RAILS_ENV=test app bundle exec rspec spec/requests/admin/topics_spec.rb spec/helpers/admin/topics_helper_spec.rb

A browser-level pass would still strengthen the public proof story, but the focused Docker-backed build and test loop now passes cleanly, so this is ready for maintainer review.

@justin808
justin808 force-pushed the codex/react-on-rails-admin-topics-slice branch from 6e28d6c to d4a4a99 Compare May 22, 2026 01:25
@justin808

Copy link
Copy Markdown
Author

Dependency finalization

Commit bbe0899 pins React on Rails to 17.0.0 in both Ruby and npm manifests, and React plus React DOM to 19.2.1. ShakaPacker remains at 10.1.0.

Lockfile evidence

  • Gemfile.lock changes only react_on_rails from 17.0.0.rc.1 to 17.0.0.
  • yarn.lock changes only react, react-dom, and react-on-rails to the exact requested versions.
  • package-lock.json is a legacy npm lock; the declared package manager is Yarn 1.22.22, and no package-lock update is needed for this Yarn-managed change.

Validation

  • bundle install and bundle check: passed.
  • yarn install --frozen-lockfile and yarn check --integrity: passed.
  • bundle exec rubocop Gemfile: passed.
  • bundle exec rspec spec/requests/admin/topics_spec.rb: the React on Rails test asset build completed, then the spec failed before its assertion because shared act_test already contains an admin email. I did not reset that shared database.

Coordinated review closeout

  • COORDINATED_AUTOFIX=1 review inventory at the current head: zero review summaries, inline comments, issue comments before this summary, and unresolved threads; action f had no review work to apply.
  • The repository workflow is push-triggered. No current-head workflow run or PR check has appeared yet, and there is no repository-specific manual hosted-CI trigger configured.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

@justin808

Copy link
Copy Markdown
Author

Batch QA Evidence — ROR-Mig-coord-orbit

  • QA lane: ror-mig-qa-final, independent gpt-5.6-sol/xhigh; claim acquired and released by handoff.
  • Scope checked: dependency manifests and locks at ACP PR 975.
  • Tested at: PR Migrate admin topics to React on Rails #975 head bbe08995e2f56301bebc530af4f488a41da856cc.
  • Automated checks: maker Bundler and Yarn install plus focused build and request spec attempt; current-head CI inventory empty.
  • Manual checks: exact manifest and lock version audit.
  • Findings: CI evidence missing; shared database prevented focused spec completion.
  • QA required: yes.
  • QA required rationale: seven-repository React on Rails 17 and React 19 migration.
  • QA lane status: blocked.
  • Release-blocking status: blocked.
  • Process-gap disposition: checklist+replay.
  • Canonical state: waiting-on-checks-or-review.
  • Next action: establish or run current-head CI and refresh readiness.

@justin808

Copy link
Copy Markdown
Author

Coordinator gate update for current head bbe0899: no Actions run exists for this SHA in either EFForg/action-center-platform or the justin808/action-center-platform head fork. The repository Ruby on Rails CI workflow is configured for push only, so the cross-repository PR did not receive a pull_request check. Local validation evidence remains recorded above. Maintainer next step: establish or explicitly waive current-head hosted CI; status remains waiting-on-checks-or-review. No merge was attempted.

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.

1 participant