Skip to content

Conversation

@maparent
Copy link
Collaborator

@maparent maparent commented Dec 11, 2025

Distinguish the onRefresh and forceRefresh function.
The cache bypass was not consistent, leading to too many calls.

  • Deleted a seemingly unused loadInBackground argument in the onRefresh signature
  • updateCount variable so we both benefit from caching and can break it.

Summary by CodeRabbit

  • Refactor
    • Improved refresh and cache-control interfaces so components can request fresh or cached data more explicitly.
    • Coordinated refresh timing tightened to deliver more consistent contextual results across views (including Kanban and results lists).
    • Minor UI markup cleanup in results table for more stable rendering.

✏️ Tip: You can customize this high-level summary in your review settings.

@linear
Copy link

linear bot commented Dec 11, 2025

@supabase
Copy link

supabase bot commented Dec 11, 2025

This pull request has been ignored for the connected project zytfjzqyijgagqxrzbmz because there are no changes detected in packages/database/supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

@maparent
Copy link
Collaborator Author

@CodeRabbit review

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 11, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 11, 2025

📝 Walkthrough

Walkthrough

Propagated an updated onRefresh signature that accepts an optional boolean ignoreCache through Roam components, updated usages to pass the flag, and widened ignoreCache type from literal true to boolean in the discourse-results utility.

Changes

Cohort / File(s) Summary
Discourse context / UI components
apps/roam/src/components/DiscourseContext.tsx
Updated ContextTab/ContextContent props: onRefresh now typed as (ignoreCache?: boolean) => void. ContextContent refactored to accept and forward ignoreCache, calls initial refresh with onRefresh(false), and uses delayed refresh with the new signature.
Results view & table
apps/roam/src/components/results-view/ResultsView.tsx, apps/roam/src/components/results-view/ResultsTable.tsx
Changed ResultsViewComponent and ResultsTable / ResultRowProps onRefresh prop types to (ignoreCache?: boolean) => void. Adjusted call sites to the new signature (some callers now call onRefresh() with no arg). Minor JSX formatting tweak in ResultsTable. Also updated a RoamBasicNode import path to roamjs-components/types/native.
Discourse results util / types
apps/roam/src/utils/getDiscourseContextResults.ts
Broadened ignoreCache type from true to boolean in BuildQueryConfig.args and getDiscourseContextResults function signature to accept ignoreCache?: boolean.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Verify all onRefresh prop type updates are consistent across components and callers.
  • Check places that previously relied on a true-only ignoreCache value still behave when passed false or omitted.
  • Inspect the initial onRefresh(false) call in ContextContent and delayed refresh timing (250ms) for intended behavior.
  • Review ResultsView/ResultsTable call sites to ensure no runtime parameter mismatch after the signature change.

Pre-merge checks

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title 'eng-1144: DiscourseContext UI disappears' describes the problem being addressed, while the actual changes involve refactoring the onRefresh/forceRefresh function signatures and cache bypass behavior. The title focuses on the symptom rather than the solution.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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 and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
apps/roam/src/components/DiscourseContext.tsx (1)

337-370: forceRefresh cannot bypass result cache because ignoreCache is hard-coded to false

In ContextContent, the intent appears to be:

  • onRefresh does a normal (cached) load.
  • forceRefresh triggers a refresh that bypasses the cache via the new ignoreCache plumbing and/or updateCount.

However, the current implementation prevents that:

const [updateCount, setUpdateCount] = useState(0);

const onRefresh = useCallback(
  (ignoreCache?: boolean) => {
    setRawQueryResults({});
    getDiscourseContextResults({
      uid,
      onResult: addLabels,
      ignoreCache: false,   // <- argument is ignored; always cached
    }).finally(() => setLoading(false));
  },
  [uid, setRawQueryResults, setLoading, addLabels, updateCount],
);

const forceRefresh = () => {
  setUpdateCount((prevCount) => prevCount + 1);
  onRefresh(true);
};

Issues:

  • ignoreCache parameter is unused; getDiscourseContextResults always receives ignoreCache: false, so forceRefresh never bypasses resultCache.
  • updateCount is only in the dependency array; it’s never read, so it doesn’t influence behavior beyond changing onRefresh’s identity.
  • delayedRefresh (and the toolbar Refresh button via forceRefresh) therefore do not achieve the “hard refresh” behavior described in the PR.

A minimal fix is to actually propagate ignoreCache and drop the unused updateCount indirection:

- const [updateCount, setUpdateCount] = useState(0);
-
- // never set ignoreCache to true directly,
- // as it may be negated by the useCallback cache.
- // go through forceRefresh when needed
- const onRefresh = useCallback(
-   (ignoreCache?: boolean) => {
-     setRawQueryResults({});
-     getDiscourseContextResults({
-       uid,
-       onResult: addLabels,
-       ignoreCache: false,
-     }).finally(() => setLoading(false));
-   },
-   [uid, setRawQueryResults, setLoading, addLabels, updateCount],
- );
-
- const forceRefresh = () => {
-   setUpdateCount((prevCount) => prevCount + 1);
-   onRefresh(true);
- };
+ // Standard refresh uses cached results; `forceRefresh` below opts out.
+ const onRefresh = useCallback(
+   (ignoreCache?: boolean) => {
+     setRawQueryResults({});
+     getDiscourseContextResults({
+       uid,
+       onResult: addLabels,
+       ignoreCache,
+     }).finally(() => setLoading(false));
+   },
+   [uid, addLabels],
+ );
+
+ const forceRefresh = () => {
+   onRefresh(true);
+ };

delayedRefresh will then correctly do a hard refresh:

const delayedRefresh = () => {
  window.setTimeout(forceRefresh, 250);
};

If you do want to retain updateCount as part of the cache-busting strategy (e.g., by folding it into the cacheKey inside getDiscourseContextResults), it needs to be incorporated into that key or into the ignoreCache value — right now it has no effect.

As-is, the new forceRefresh API doesn’t actually bypass the context results cache, which undermines the main goal of this PR.

Also applies to: 372-374

🧹 Nitpick comments (3)
apps/roam/src/utils/getDiscourseContextResults.ts (1)

14-26: ignoreCache boolean broadening looks correct and preserves cache semantics

Using ignoreCache?: boolean in both BuildQueryConfig and getDiscourseContextResults is consistent with the !ignoreCache check in buildQueryConfig and cleanly allows explicit cache bypass when needed, while keeping the default (undefined/false) behavior cached.

If you want to make the default explicit, you could also default the param:

const getDiscourseContextResults = async ({
  uid: targetUid,
  relations = getDiscourseRelations(),
  nodes = getDiscourseNodes(relations),
  ignoreCache = false,
  onResult,
}: { /* ... */ }) => {
  const args = { ignoreCache };
  // ...
};

Purely optional; current implementation is functionally sound.

Also applies to: 169-183

apps/roam/src/components/results-view/ResultsView.tsx (2)

231-243: ResultsView refresh API and forceRefresh fallback look good

The updated props (onRefresh: () => void plus optional forceRefresh?: () => void) and the refresh button logic that prefers forceRefresh() and falls back to onRefresh() align well with the new separation of “normal” vs. explicit refresh.

If you want to shave a little inline logic, you could simplify the button handler to:

<Button
  icon="refresh"
  minimal
  onClick={() => (forceRefresh ?? onRefresh)()}
/>

Functionally equivalent; just slightly tighter.

Also applies to: 274-286, 577-585


1367-1372: Kanban onQuery now calls plain onRefresh, which matches the new signature

Changing onQuery to () => onRefresh() is consistent with the updated onRefresh: () => void type and removes the now-defunct flag argument. Behavior-wise this means Kanban’s re-query uses the standard refresh path instead of any special background/flagged mode, which fits the new API.

You could also simplify to onQuery={onRefresh} since there’s no argument, but that’s purely stylistic.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9fbe00d and 6d71bbe.

📒 Files selected for processing (3)
  • apps/roam/src/components/DiscourseContext.tsx (5 hunks)
  • apps/roam/src/components/results-view/ResultsView.tsx (4 hunks)
  • apps/roam/src/utils/getDiscourseContextResults.ts (2 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/main.mdc)

**/*.{ts,tsx}: Use Tailwind CSS for styling where possible
When refactoring inline styles, use tailwind classes
Prefer type over interface in TypeScript
Use explicit return types for functions
Avoid any types when possible
Prefer arrow functions over regular function declarations
Use named parameters (object destructuring) when a function has more than 2 parameters
Use PascalCase for components and types
Use camelCase for variables and functions
Use UPPERCASE for constants
Function names should describe their purpose clearly
Prefer early returns over nested conditionals for better readability

Files:

  • apps/roam/src/components/results-view/ResultsView.tsx
  • apps/roam/src/utils/getDiscourseContextResults.ts
  • apps/roam/src/components/DiscourseContext.tsx
apps/roam/**/*.{js,ts,tsx,jsx,json}

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

Prefer existing dependencies from package.json when working on the Roam Research extension

Files:

  • apps/roam/src/components/results-view/ResultsView.tsx
  • apps/roam/src/utils/getDiscourseContextResults.ts
  • apps/roam/src/components/DiscourseContext.tsx
apps/roam/**/*.{ts,tsx,jsx,js,css,scss}

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

Use BlueprintJS 3 components and Tailwind CSS for platform-native UI in the Roam Research extension

Files:

  • apps/roam/src/components/results-view/ResultsView.tsx
  • apps/roam/src/utils/getDiscourseContextResults.ts
  • apps/roam/src/components/DiscourseContext.tsx
apps/roam/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

apps/roam/**/*.{ts,tsx,js,jsx}: Use the roamAlphaApi docs from https://roamresearch.com/#/app/developer-documentation/page/tIaOPdXCj when implementing Roam functionality
Use Roam Depot/Extension API docs from https://roamresearch.com/#/app/developer-documentation/page/y31lhjIqU when implementing extension functionality

Files:

  • apps/roam/src/components/results-view/ResultsView.tsx
  • apps/roam/src/utils/getDiscourseContextResults.ts
  • apps/roam/src/components/DiscourseContext.tsx
apps/roam/**

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

Implement the Discourse Graph protocol in the Roam Research extension

Files:

  • apps/roam/src/components/results-view/ResultsView.tsx
  • apps/roam/src/utils/getDiscourseContextResults.ts
  • apps/roam/src/components/DiscourseContext.tsx
🧠 Learnings (1)
📚 Learning: 2025-11-25T00:52:41.934Z
Learnt from: CR
Repo: DiscourseGraphs/discourse-graph PR: 0
File: .cursor/rules/roam.mdc:0-0
Timestamp: 2025-11-25T00:52:41.934Z
Learning: Applies to apps/roam/**/*.{ts,tsx,js,jsx} : Use the roamAlphaApi docs from https://roamresearch.com/#/app/developer-documentation/page/tIaOPdXCj when implementing Roam functionality

Applied to files:

  • apps/roam/src/components/DiscourseContext.tsx
🧬 Code graph analysis (1)
apps/roam/src/components/DiscourseContext.tsx (1)
apps/roam/src/components/CreateRelationDialog.tsx (1)
  • CreateRelationButton (360-383)
🔇 Additional comments (1)
apps/roam/src/components/DiscourseContext.tsx (1)

220-234: forceRefresh is correctly threaded through ContextTab and into ResultsView

The addition of forceRefresh: () => void on ContextTab and its propagation down to <ResultsView ... forceRefresh={forceRefresh} /> matches the new ResultsView API and cleanly distinguishes external “hard” refreshes from standard onRefresh calls.

The use in the bottom Tabs (<ContextTab ... onRefresh={onRefresh} forceRefresh={forceRefresh} />) also looks consistent with how ContextContent defines those two responsibilities.

No changes needed here.

Also applies to: 269-281, 408-416

@maparent maparent marked this pull request as ready for review December 11, 2025 17:08
@maparent maparent requested a review from mdroidian December 11, 2025 17:08
Copy link
Contributor

@mdroidian mdroidian left a comment

Choose a reason for hiding this comment

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

useCallback shouldn't be the issue here.

Let's try to go back and identify what line of code introduced this regression. From there, let's identify why that line of code is causing this behavior. Then, let's find the solution.

I do not believe introducing another refresh function is the correct solution for this problem.

}).finally(() => setLoading(false));
}, [uid, setRawQueryResults, setLoading, addLabels]);
// never set ignoreCache to true directly,
// as it may be negated by the useCallback cache.
Copy link
Contributor

Choose a reason for hiding this comment

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

useCallback does not “cache” results or arguments. It only memoizes the function reference (identity).

ignoreCache,
}).finally(() => setLoading(false));
},
[uid, setRawQueryResults, setLoading, addLabels, updateCount],
Copy link
Contributor

Choose a reason for hiding this comment

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

React Hook useCallback has an unnecessary dependency: 'updateCount'. Either exclude it or remove the dependency array.eslintreact-hooks/exhaustive-deps

@maparent maparent force-pushed the eng-1144-discourse-context-ui-disappears branch 2 times, most recently from c225b5c to b9ba045 Compare December 14, 2025 20:56
@maparent
Copy link
Collaborator Author

@CodeRabbit review

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 14, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@maparent maparent changed the title eng-1144: Separate the forceRefresh function eng-1144: DiscourseContext UI disappears Dec 14, 2025
@maparent
Copy link
Collaborator Author

Ok, replaced the previous implementation by a different one.
The root cause (introduced in ENG-1019) was adding the ignoreCache to the refreshButton; without which the refresh button was not working earlier. But onRefresh was also used at initial load, in the useEffect, and forcing a reload there is what made the UX glitch. So I still add ignoreCache as an optional parameter, I made the types consistent with that, and I set it to false in the useEffect.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (2)
apps/roam/src/components/DiscourseContext.tsx (1)

364-371: Refactor useEffect dependencies to avoid potential issues.

The dependency array includes loading (unused in the effect body) and onRefresh (which itself depends on addLabels, creating a circular dependency chain). This could cause unnecessary re-runs.

Consider restructuring:

  useEffect(() => {
    if (!results) {
      onRefresh(false);
    } else {
      results.forEach(addLabels);
      setLoading(false);
    }
- }, [onRefresh, results, setLoading, loading, addLabels]);
+ }, [results, addLabels]);

Then ensure onRefresh is called with the current addLabels by wrapping the call:

  useEffect(() => {
    if (!results) {
-     onRefresh(false);
+     setRawQueryResults({});
+     void getDiscourseContextResults({
+       uid,
+       onResult: addLabels,
+       ignoreCache: false,
+     }).finally(() => setLoading(false));
    } else {
      results.forEach(addLabels);
      setLoading(false);
    }
- }, [results, addLabels]);
+ }, [results, addLabels, uid]);

This eliminates the circular dependency while maintaining the same behavior.

apps/roam/src/components/results-view/ResultsTable.tsx (1)

177-177: Minor formatting change unrelated to PR objectives.

The CellEmbed JSX was reformatted to a single line. While this is fine, it appears unrelated to the core PR objective of separating cache control in the onRefresh function.

Consider keeping formatting changes separate from functional changes in future PRs for clearer change tracking.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6d71bbe and b9ba045.

📒 Files selected for processing (4)
  • apps/roam/src/components/DiscourseContext.tsx (2 hunks)
  • apps/roam/src/components/results-view/ResultsTable.tsx (3 hunks)
  • apps/roam/src/components/results-view/ResultsView.tsx (3 hunks)
  • apps/roam/src/utils/getDiscourseContextResults.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • apps/roam/src/utils/getDiscourseContextResults.ts
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/main.mdc)

**/*.{ts,tsx}: Use Tailwind CSS for styling where possible
When refactoring inline styles, use tailwind classes
Prefer type over interface in TypeScript
Use explicit return types for functions
Avoid any types when possible
Prefer arrow functions over regular function declarations
Use named parameters (object destructuring) when a function has more than 2 parameters
Use PascalCase for components and types
Use camelCase for variables and functions
Use UPPERCASE for constants
Function names should describe their purpose clearly
Prefer early returns over nested conditionals for better readability

Files:

  • apps/roam/src/components/DiscourseContext.tsx
  • apps/roam/src/components/results-view/ResultsTable.tsx
  • apps/roam/src/components/results-view/ResultsView.tsx
apps/roam/**/*.{js,ts,tsx,jsx,json}

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

Prefer existing dependencies from package.json when working on the Roam Research extension

Files:

  • apps/roam/src/components/DiscourseContext.tsx
  • apps/roam/src/components/results-view/ResultsTable.tsx
  • apps/roam/src/components/results-view/ResultsView.tsx
apps/roam/**/*.{ts,tsx,jsx,js,css,scss}

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

Use BlueprintJS 3 components and Tailwind CSS for platform-native UI in the Roam Research extension

Files:

  • apps/roam/src/components/DiscourseContext.tsx
  • apps/roam/src/components/results-view/ResultsTable.tsx
  • apps/roam/src/components/results-view/ResultsView.tsx
apps/roam/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

apps/roam/**/*.{ts,tsx,js,jsx}: Use the roamAlphaApi docs from https://roamresearch.com/#/app/developer-documentation/page/tIaOPdXCj when implementing Roam functionality
Use Roam Depot/Extension API docs from https://roamresearch.com/#/app/developer-documentation/page/y31lhjIqU when implementing extension functionality

Files:

  • apps/roam/src/components/DiscourseContext.tsx
  • apps/roam/src/components/results-view/ResultsTable.tsx
  • apps/roam/src/components/results-view/ResultsView.tsx
apps/roam/**

📄 CodeRabbit inference engine (.cursor/rules/roam.mdc)

Implement the Discourse Graph protocol in the Roam Research extension

Files:

  • apps/roam/src/components/DiscourseContext.tsx
  • apps/roam/src/components/results-view/ResultsTable.tsx
  • apps/roam/src/components/results-view/ResultsView.tsx
🧠 Learnings (3)
📚 Learning: 2025-11-25T00:52:41.934Z
Learnt from: CR
Repo: DiscourseGraphs/discourse-graph PR: 0
File: .cursor/rules/roam.mdc:0-0
Timestamp: 2025-11-25T00:52:41.934Z
Learning: Applies to apps/roam/**/*.{ts,tsx,js,jsx} : Use the roamAlphaApi docs from https://roamresearch.com/#/app/developer-documentation/page/tIaOPdXCj when implementing Roam functionality

Applied to files:

  • apps/roam/src/components/results-view/ResultsTable.tsx
  • apps/roam/src/components/results-view/ResultsView.tsx
📚 Learning: 2025-11-25T00:52:41.934Z
Learnt from: CR
Repo: DiscourseGraphs/discourse-graph PR: 0
File: .cursor/rules/roam.mdc:0-0
Timestamp: 2025-11-25T00:52:41.934Z
Learning: Applies to apps/roam/**/*.{ts,tsx,jsx,js,css,scss} : Use BlueprintJS 3 components and Tailwind CSS for platform-native UI in the Roam Research extension

Applied to files:

  • apps/roam/src/components/results-view/ResultsTable.tsx
  • apps/roam/src/components/results-view/ResultsView.tsx
📚 Learning: 2025-08-11T19:09:58.252Z
Learnt from: maparent
Repo: DiscourseGraphs/discourse-graph PR: 337
File: apps/roam/src/components/DiscourseFloatingMenu.tsx:43-43
Timestamp: 2025-08-11T19:09:58.252Z
Learning: The roam subdirectory (apps/roam) is constrained to React 17 and cannot use React 18+ features like createRoot API. ReactDOM.render should be used instead of createRoot in this subdirectory.

Applied to files:

  • apps/roam/src/components/results-view/ResultsView.tsx
🔇 Additional comments (7)
apps/roam/src/components/DiscourseContext.tsx (3)

231-231: LGTM! Prop signature correctly updated.

The onRefresh prop type now accepts an optional ignoreCache boolean parameter, aligning with the PR's goal to enable cache control.


348-358: Verify the default ignoreCache = true parameter.

The default parameter causes all calls without an explicit argument to bypass the cache. While line 366 explicitly passes false for the initial load, user-triggered refreshes (lines 284, 361) will use the default true.

Confirm this is the intended behavior: initial loads benefit from caching, while user actions always force fresh data.

Based on the PR objectives, this appears correct, but verification ensures the caching strategy aligns with the intended fix for excessive calls.


284-284: Past setTimeout issue resolved.

The previous bug where setTimeout(() => forceRefresh, 250) didn't invoke the function has been fixed. The current implementation correctly passes onRefresh directly to setTimeout, which will execute it after the delay.

Calling onRefresh without arguments uses the default ignoreCache = true, appropriately forcing a refresh after creating a relation.

apps/roam/src/components/results-view/ResultsTable.tsx (1)

191-191: LGTM! Type signatures correctly updated.

The onRefresh prop types in both ResultRowProps and ResultsTable are now consistent with the updated signature across the codebase, enabling cache control via the optional ignoreCache parameter.

Also applies to: 394-394

apps/roam/src/components/results-view/ResultsView.tsx (3)

241-241: LGTM! Parameter renamed for clarity.

The loadInBackground parameter has been renamed to ignoreCache, which more clearly expresses its purpose. This directly addresses the PR objective to remove the apparently unused loadInBackground argument and replace it with explicit cache control semantics.


1364-1364: LGTM! Simplified to rely on default parameter.

The call changed from onRefresh(true) to onRefresh(), relying on the default parameter value. Since the default in ContextContent.onRefresh is ignoreCache = true, the behavior remains the same while the code is more concise.


41-41: The import path roamjs-components/types/native is valid and follows the codebase's established pattern for native Roam types.

The codebase uses both roamjs-components/types and roamjs-components/types/native imports. The /native path is consistently used for core native Roam types like RoamBasicNode, OnloadArgs, PullBlock, DatalogClause, and InputTextNode. This change aligns with how similar types are imported elsewhere (e.g., isFlagEnabled.ts, parseQuery.ts, parseResultSettings.ts).

However, this import standardization appears unrelated to the PR's primary cache control objectives. Consider documenting this refactoring separately or consolidating it with other import path standardization changes across the codebase.

@maparent
Copy link
Collaborator Author

@mdroidian A bit puzzled by the coderabbit suggestion here. TBH, I don't understand why static functions have to be in the arguments of useCallback or useEffect; but removing them (as coderabbit suggest) leads to an eslint complaint (react-hooks/exhaustive-deps). (Maybe because they're memoized functions and not functions?) Anyhow I think coderabbit is wrong, but there are react constraints I don't grok deeply enough, would appreciate your insight.

@maparent maparent requested a review from mdroidian December 14, 2025 21:20
Copy link
Contributor

@mdroidian mdroidian left a comment

Choose a reason for hiding this comment

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

re: deps
React’s exhaustive-deps rule wants every reactive value used inside an effect — including functions — in the dependency array so React can re-run the effect with up-to-date values and avoid stale closures. ref

Taking a quick look, with the addition of ignoreCache, the useEffect/onRefresh could probably use a restructure. Some thought should be put into the different scenarios and what the ramifications are.

If this PR fixes the error and multiple scenarios in the UI have been tested (a loom video would really be great here), then this can probably be deffered.

preventSavingSettings?: boolean;
onEdit?: () => void;
onDeleteQuery?: () => void;
onRefresh: (loadInBackground?: boolean) => void;
Copy link
Contributor

Choose a reason for hiding this comment

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

loadInBackground is 'used' in QueryBuilder.tsx. If we are changing this, should probably remove the loadInBackground reference.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, I missed that one, thanks. And I agree with the quotation marks around 'used'.
Two things I could do: Remove the loadInBackground reference, since it does so little; (and probably just not call setLoading, but also a decision);
OR add the parameter back, and have a signature with two parameters on the type everywhere.
Which do you prefer?

Copy link
Contributor

Choose a reason for hiding this comment

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

Remove. But keep the same behavior (which is setLoading(true) I believe)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

(the linear comment did not carry, copying) Done. onRefresh is called twice, this time with true (hence setLoading(true) as you say, which amounts to load in background being statically false, not true as you say in the other comment.) and in the DiscourseContext.tsx:366 useEffect, where it used to be false. I think this was to avoid a "loading" flicker on first display. I think this flicker is very short, accurately represents processing, and not worth another parameter to suppress.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done. onRefresh is called twice, this time with true (hence setLoading(true) as you say, which amounts to load in background being statically false, not true as you say in the other comment.) and in the DiscourseContext.tsx:366 useEffect, where it used to be false. I think this was to avoid a "loading" flicker on first display. I think this flicker is very short, accurately represents processing, and not worth another parameter to suppress.

data={allProcessedResults}
layout={layout}
onQuery={() => onRefresh(true)}
onQuery={() => onRefresh()}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you add some context as to why this change was made, please? Kanban quite seems unrelated to discourse context UI.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That is because I removed the loadInBackground flag, so I removed the one call instance which seemed to be using it. So it depends on what we decide to do with that flag, above.

Copy link
Contributor

Choose a reason for hiding this comment

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

ok, well "load in background" can be statically true , so this line can stay the way it is if we change setLoading(true) where loadInBackground was being used.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

statically false, but otherwise agreed.

@maparent
Copy link
Collaborator Author

@maparent maparent force-pushed the eng-1144-discourse-context-ui-disappears branch from 4018ed7 to 7a44b37 Compare December 16, 2025 14:23
@maparent maparent requested a review from mdroidian December 16, 2025 14:51
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.

3 participants