Skip to content

fix: cache location rules responses client-side (#29)#35

Open
bfintal wants to merge 1 commit into
developfrom
fix/29-cache-location-rules
Open

fix: cache location rules responses client-side (#29)#35
bfintal wants to merge 1 commit into
developfrom
fix/29-cache-location-rules

Conversation

@bfintal

@bfintal bfintal commented Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Summary

Fixes #29 — the location rules fetch can be a PHP performance bottleneck.

The /interact/v1/get_location_rules/{type} endpoint runs unbounded get_posts( [ 'posts_per_page' => -1 ] ) queries for post/page rules. On the client it was fired per LocationRule instance, on mount and on every param change, with no caching or dedup — so multiple rules meant multiple parallel unbounded queries and large repeated payloads that scale badly with site size.

This applies the recommended client-side fix:

  • Adds a module-level cache keyed by param that memoizes each response.
  • Shares in-flight requests across all LocationRule instances (dedup), so simultaneous mounts trigger a single request per param.
  • Clones the cached response before injecting the "Current Post/Page" option, so the shared cache is never mutated.
  • Does not cache failed requests, so they can be retried.
  • Guards the effect against setState after unmount and resets the busy state on error.

No server-side or API changes; behavior is identical from the user's perspective, just without the redundant repeated queries.

Test plan

  • Open the interaction editor and add multiple location rules using the same param (e.g. several post rules) — verify only one network request per param in the Network tab.
  • Switch a rule's param back and forth (e.g. post -> page -> post) — verify the second visit to a param serves from cache with no new request.
  • Confirm the "Current Post"/"Current Page" option still appears correctly and is not duplicated.
  • Simulate a failed request and confirm it retries on next mount (not cached).

Made with Cursor

Summary by CodeRabbit

  • Bug Fixes
    • Improved location-rule loading reliability by reusing requests and allowing failed requests to retry.
    • Prevented errors when navigating away before location rules finish loading.
    • Ensured dynamically added options do not affect shared data.

The `/interact/v1/get_location_rules/{type}` endpoint runs unbounded
`get_posts()` queries and was fetched per LocationRule, on mount and on
every param change, with no caching or dedup. This memoizes responses in
a module-level cache keyed by param and shares in-flight requests across
all LocationRule instances, avoiding redundant parallel queries and large
repeated payloads.

Responses are cloned before adding the "Current Post/Page" option so the
shared cache is never mutated, failed requests are not cached (so they can
retry), and the effect now guards against setState after unmount.

Co-authored-by: Cursor <cursoragent@cursor.com>
@cursor

cursor Bot commented Jul 10, 2026

Copy link
Copy Markdown

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

@coderabbitai

coderabbitai Bot commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Location rule fetching now caches shared API promises by parameter, removes failed requests for retry, clones responses before modification, and prevents asynchronous state updates after unmount.

Changes

Location rule fetching

Layer / File(s) Summary
Cached fetch and effect lifecycle
src/editor/components/location-rules/index.js
Adds parameter-keyed promise caching, removes failed requests from the cache, deep-clones successful responses before adding current post/page options, and guards state updates with an unmount flag.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly states the main change: client-side caching of location rule responses.
Linked Issues check ✅ Passed The PR adds a module-level cache keyed by param, reuses in-flight requests, and avoids mutating cached responses, matching #29.
Out of Scope Changes check ✅ Passed The changes stay focused on client-side caching and request deduplication for location rules, with no unrelated behavior introduced.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/29-cache-location-rules

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

github-actions Bot added a commit that referenced this pull request Jul 10, 2026
@github-actions

Copy link
Copy Markdown

🤖 Pull request artifacts

file commit
pr35-interactions-35-merge.zip e15ae40

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🧹 Nitpick comments (1)
src/editor/components/location-rules/index.js (1)

176-178: 🚀 Performance & Scalability | 🔵 Trivial | ⚖️ Poor tradeoff

Optional: scope the clone to avoid deep-copying large payloads.

cloneDeep(response) runs unconditionally, but only the post/page branch mutates options (the unshift at line 196) — and those are precisely the unbounded payloads called out in issue #29. Non-post/page params never mutate, and the post/page case only needs the matched group's options array copied. A full deep clone per LocationRule instance duplicates the whole (potentially huge) post list each render.

Consider cloning only when needed, and shallowly at the mutation site, keeping the shared cache immutable while avoiding the O(n) deep copy of every option object.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/editor/components/location-rules/index.js` around lines 176 - 178, Limit
cloning in the location-rule option handling to the post/page branch that
performs the unshift in the relevant rule-building logic. Avoid unconditional
cloneDeep(response); preserve cached data by shallow-copying only the matched
group and its options array immediately before adding “Current Post/Page,” while
leaving non-post/page responses unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/editor/components/location-rules/index.js`:
- Around line 176-178: Limit cloning in the location-rule option handling to the
post/page branch that performs the unshift in the relevant rule-building logic.
Avoid unconditional cloneDeep(response); preserve cached data by shallow-copying
only the matched group and its options array immediately before adding “Current
Post/Page,” while leaving non-post/page responses unchanged.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4c8658d5-7539-4256-8005-5a2468f1bb0f

📥 Commits

Reviewing files that changed from the base of the PR and between e5dfb32 and e15ae40.

📒 Files selected for processing (1)
  • src/editor/components/location-rules/index.js

@bfintal bfintal self-assigned this Jul 10, 2026
@bfintal bfintal requested a review from Arukuen July 10, 2026 10:10
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.

Location fetch can be a PHP performance bottleneck

1 participant