Inertia Migration: Edit Product Pages

[sm17p]

Closes: #3030

• Migrate Edit Product page to Inertia #3030

Description

This PR migrates the product edit flow to Inertia. The main product edit tab (edit/update), content edit tab, receipt edit tab, and share edit tab are now Inertia pages backed by Products::MainController, Products::ContentController, Products::ReceiptController, and Products::ShareController

Solution

Frontend Changes

1. Product edit pages and shared components no longer depend on React context for sharing data. Each component now receives exactly the props it needs to work.

2. Product edit pages use Inertia's useForm helper to manage form state

3. Follows Bundles Inertia migration pattern for consistency and keeps page state in sync with the server when moving between product edit tabs. If the form is in dirty state, navigation triggers a request so that common data is synced before the next page load.

Backend Changes

1. Each tab gets only the product fields and metadata it needs (e.g. receipt tab: receipt text and view-content button; content tab: files and content settings).

   • Controllers/presenters build these per-tab payloads.
   • Some tabs support partial reloads so they can refresh specific fields without reloading the whole page.

2. Centralized update logic in Product::UpdateService. All product-tab updates (main, content, receipt, share) go through Product::UpdateService, which updates, publish/unpublish, in one place.

3. Few of the internal API endpoints, used to load tab specific data are now passed as props like receipt_preview_html (receipt tab), and existing_files (content tab).

4. For failed form submissions we use status: :found (302) inertia to populate error props (required by inertia, 303 sends empty error object), which is then automatically converted to 303 by Inertia

5. Backend now supports two new flash cases,

   • Flash messages that are HTML (message starts with <and ends with >) are passed through with html: true in the shared flash props so the client can render them as HTML. Used in Product::UpdateService when publish fails (e.g. empty seller email), it sets flash[:alert] to an HTML string with a link (e.g. “Set an email”).
   • Complex client-side alerts – When flash[:inertia] is set with a status that starts with "frontend_alert" and optional data, the backend sends { status, data } in the shared flash. The client can branch on status and data to show custom UI (e.g. toasts, modals, or inline messages). After saving the content tab, the backend sends a “contents updated” alert with a link so the seller can notify buyers; the content edit page reads that flash and shows the alert with the link.

Before/After

---

Test Results

Request Specs

Other Specs

One flaky elastic search spec

bundle exec rspec spec/controllers/links_controller_spec.rb spec/controllers/products/content_controller_spec.rb spec/controllers/products/main_controller_spec.rb spec/controllers/products/receipt_controller_spec.rb spec/controllers/products/share_controller_spec.rb spec/mailers/contacting_creator_mailer_spec.rb spec/presenters/collab_products_page_presenter_spec.rb spec/presenters/dashboard_products_page_presenter_spec.rb spec/presenters/product_presenter_spec.rb spec/services/product/rich_content_updater_service_spec.rb spec/services/product/variant_category_updater_service_spec.rb spec/services/product/variants_updater_service_spec.rb

---

Checklist

• I have read the contributing guidelines
• I have watched Gumroad PR review livestreams
• I have performed a self-review and left review comments on my PR
• I have added/updated tests for my changes

---

AI Disclosure

Cursor Auto was used for drafting a plan, edits, debugging and documentation checks