logseq / logseq/db-test

Allow queries to opt into eager result block loading

Open
#1,138 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
28
Forks
2
PR merge metrics
No merged PRs in 30d

Description

### What happened?

DB graph queries return block UUIDs first and hydrate the result blocks independently as rows render. For result blocks with positioned properties, such as the built-in Status property shown to the left of a task, the control may not be available on the initial query render and can appear only after that row has been hydrated through interaction.

This is especially noticeable for expanded journal default queries that act as task dashboards.

### Reproduce the behavior

1. Configure an expanded journal default query that returns task blocks.
2. Open today's journal in a DB graph.
3. Observe that the result titles can render before their positioned Status controls are available.
4. Interact with individual result rows; the controls then appear as those blocks are loaded.

### Proposed behavior

Allow an advanced/default query map to opt into eager block hydration:

```clojure
{:title "NEXT"
:query [:find (pull ?b [*])
:where
(task ?b #{"Todo"})]
:collapsed? false
:query/eager-load-results? true}
```

When the option is exactly `true` and the normalized result consists only of block UUIDs, return canonical block snapshots with the query result so block content and positioned-property metadata are ready together.

Queries without the option, queries with `false`, and non-block/scalar query results should keep the current lazy behavior.

### Trade-off

Eager hydration should share the renderer's existing 1,000-root block snapshot limit. All query rows are still returned, while rows beyond that limit retain normal lazy loading. The option remains explicit because even bounded eager hydration does more up-front work than the default. DOM virtualization can remain unchanged.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing DB graph query result rendering and the renderer's existing 1,000-root block snapshot limit. Check how expanded journal default queries normalize UUID-only results and hydrate blocks. Done means the explicit true option eagerly returns canonical block snapshots within the limit, while other and non-block results retain lazy loading.

Written by the indexing model from the issue text.

Assessment

Tech stack
clojure
Domain
database, frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.