Evaluate architectural impact of Rapid Diffs caching requirements on shared infrastructure
Context
In !222771 (merged), Rapid Diffs caching requirements drove changes to shared application infrastructure. Specifically, user-logged-in/user-logged-out CSS classes were added to the <html> element via page_class in application_helper.rb - affecting every page in the application - so that the "Viewed" checkbox could render identically for all users and be cacheable at the component level.
The specific UX concern (rendering a non-functional checkbox for unauthenticated users) was resolved cleanly: CSS hides the element for logged-out users, and a JS-side codeReviewEnabled flag prevents behavioral activation. No UX degradation occurs.
Problem
The architectural concern remains: Rapid Diffs caching requirements are driving changes to shared application infrastructure that are being decided inside individual feature MRs rather than as deliberate architectural decisions.
In this case, the change was small (one line in page_class following an existing pattern of 8+ similar conditional class additions). But the pattern it establishes is worth examining:
- Auth-state CSS classes on
<html>did not exist before this change. Now they do, on every page, for every user. - Future Rapid Diffs features that are user-specific (e.g., commenting, approvals, suggestions) will likely require similar adaptations to keep component HTML user-agnostic.
- Each of these adaptations may individually be small, but their cumulative effect on the application's global surface area is not being evaluated holistically.
Goal
Document and evaluate the full set of shared infrastructure changes that the Rapid Diffs caching strategy requires, so they can be reviewed as a cohesive architectural decision rather than discovered piecemeal across feature MRs.
Specific questions:
- What other user-specific UI elements in Rapid Diffs will need similar treatment?
- What is the complete set of global changes (CSS classes, data attributes, layout modifications) that the caching strategy will require?
- Should these changes be implemented in a dedicated infrastructure MR with architectural review, rather than embedded in feature work?
Examples
| MR | Change | Scope |
|---|---|---|
| !222771 (merged) | Added user-logged-in/user-logged-out to page_class
|
Every page, <html> element |
| !222771 (merged) | Added code_review_enabled to extra_app_data
|
Rapid Diffs MR pages only |
Stakeholders
This decision should involve engineering leads familiar with the application's shared infrastructure and the Rapid Diffs caching architecture.