build: In src/lib/base.ts, extend parseBase so it parses each entry in the views array into a view model with its… #19

Merged

Connor merged 1 commit from build/5d5dea50 into main 2026-09-23 11:13:11 +00:00

Conversation 1 Commits 1 Files changed 3 +393 -65

Connor commented 2026-09-23 11:11:26 +00:00

Owner

Copy link

What changed

build/5d5dea50 → main — 3 file(s), +393/−65.

• src/lib/base.ts
• src/main.ts
• test/base.test.ts

Why

Each view of a base now evaluates on its own: its filters are applied on top of the base's filters, and its order sets the columns. The whole gate (npm run gate: check, clean build, tests) passed on the final tree, with 206 tests passing and none failing. I can't open the pull request myself because I have no credentials, so the changes are left uncommitted in the working copy for the ship door to pick up.

What I changed

• parseBase (src/lib/base.ts): it now returns a views list, where each view has name, type, filters and order. order is null when the view doesn't list any columns.
  • Filters at the top level and inside views go through the same grammar: plain expressions, and:/or:/not: groups, a bare list (treated as AND) or a single inline expression.
  • The old line-by-line scanner couldn't tell nested blocks apart, so I replaced it with a small reader for the part of YAML a .base uses: nested maps, lists and one-line values.
  • columns now come only from properties. The old views branch that merged loose tokens into the base's own columns is gone.
• evaluateBase(def, records, limit, viewName?): with no view named, it uses the first view. A note has to pass the base's filters and the view's. The columns are the view's order, or the properties columns when there isn't one.
  • A base with no views gets view: null and evaluates as before.
  • Naming a view the base doesn't have throws an error that lists the real view names, rather than quietly answering with a different view. […]

Gate

npm run gate ran 206 tests in 2.5s and exited 0 — green.

Built by Connor's backend backburner (dispatch 5d5dea50) in an isolated clone; shipped deterministically by ship.py. The full build notes were spoken in conversation and stored in memory (agent-dispatch:5d5dea50). Review is the gate.

---

The brief this build was given

Kept for provenance. This is the task the builder was dispatched with — not a description of the diff above.

In src/lib/base.ts, extend parseBase so it parses each entry in the views array into a view model with its name, type, filters (same filter grammar as the top-level filters: and/or/not groups and expression strings), and order (a list of property ids). Make evaluation view-aware: when a view is selected, a note must pass both the top-level filters and that view's filters, and the view's columns come from its order. When order is absent, fall back to the current properties-derived columns. Default to the first view when none is specified, and keep behavior unchanged for bases that have no views. Thread the selected view through any callers the analysis identified. Add tests covering: two views with different filters producing different result sets; top-level plus view filters AND-combined; order driving column selection and sequence; missing order falling back to properties; and a base with no views. Open a pull request. CONTINGENCY: if the view-selection plumbing from callers turns out to need a UI or embed-syntax decision that isn't already modeled, then ship the parser and evaluator support with the default first-view behavior plus tests, and note the open caller-selection question in the PR description rather than inventing new syntax.

This task is one step of my plan: working-list item #112: obsidian-connor base evaluator, second gap in src/lib/base.ts: parseBase reads only top-level filters and takes columns only from the properties section (base.ts:52-62), so per-view filters and order entries are silently ignored — every view of a base evaluates identically to the whole-base filter.

Result of earlier step 1 (read in obsidian-connor: Read src/lib/base.ts (especially parseBase at lines ~52-62) and every caller of ):
I found no reason to stop under the contingency. parseBase still ignores per-view filters and per-view order, so every view of a base evaluates the same way. One detail differs from the item's wording: lines 57–62 already contain a views branch, but it doesn't read views properly, and nothing models choosing a view. I changed nothing. […]

### What changed `build/5d5dea50` → `main` — 3 file(s), +393/−65. - `src/lib/base.ts` - `src/main.ts` - `test/base.test.ts` ### Why Each view of a base now evaluates on its own: its filters are applied on top of the base's filters, and its `order` sets the columns. The whole gate (`npm run gate`: check, clean build, tests) passed on the final tree, with 206 tests passing and none failing. I can't open the pull request myself because I have no credentials, so the changes are left uncommitted in the working copy for the ship door to pick up. **What I changed** - **`parseBase`** (`src/lib/base.ts`): it now returns a `views` list, where each view has `name`, `type`, `filters` and `order`. `order` is `null` when the view doesn't list any columns. - Filters at the top level and inside views go through the same grammar: plain expressions, `and:`/`or:`/`not:` groups, a bare list (treated as AND) or a single inline expression. - The old line-by-line scanner couldn't tell nested blocks apart, so I replaced it with a small reader for the part of YAML a .base uses: nested maps, lists and one-line values. - `columns` now come only from `properties`. The old `views` branch that merged loose tokens into the base's own columns is gone. - **`evaluateBase(def, records, limit, viewName?)`**: with no view named, it uses the first view. A note has to pass the base's filters and the view's. The columns are the view's `order`, or the properties columns when there isn't one. - A base with no views gets `view: null` and evaluates as before. - Naming a view the base doesn't have throws an error that lists the real view names, rather than quietly answering with a different view. […] ### Gate `npm run gate` ran 206 tests in 2.5s and exited 0 — green. Built by Connor's backend backburner (dispatch `5d5dea50`) in an isolated clone; shipped deterministically by `ship.py`. The full build notes were spoken in conversation and stored in memory (`agent-dispatch:5d5dea50`). Review is the gate. --- ### The brief this build was given _Kept for provenance. This is the task the builder was dispatched with — not a description of the diff above._ > In src/lib/base.ts, extend parseBase so it parses each entry in the `views` array into a view model with its name, type, filters (same filter grammar as the top-level filters: and/or/not groups and expression strings), and order (a list of property ids). Make evaluation view-aware: when a view is selected, a note must pass both the top-level filters and that view's filters, and the view's columns come from its `order`. When `order` is absent, fall back to the current properties-derived columns. Default to the first view when none is specified, and keep behavior unchanged for bases that have no views. Thread the selected view through any callers the analysis identified. Add tests covering: two views with different filters producing different result sets; top-level plus view filters AND-combined; order driving column selection and sequence; missing order falling back to properties; and a base with no views. Open a pull request. CONTINGENCY: if the view-selection plumbing from callers turns out to need a UI or embed-syntax decision that isn't already modeled, then ship the parser and evaluator support with the default first-view behavior plus tests, and note the open caller-selection question in the PR description rather than inventing new syntax. > > This task is one step of my plan: working-list item #112: obsidian-connor base evaluator, second gap in src/lib/base.ts: parseBase reads only top-level filters and takes columns only from the properties section (base.ts:52-62), so per-view filters and order entries are silently ignored — every view of a base evaluates identically to the whole-base filter. > > Result of earlier step 1 (read in obsidian-connor: Read src/lib/base.ts (especially parseBase at lines ~52-62) and every caller of ): > I found no reason to stop under the contingency. `parseBase` still ignores per-view `filters` and per-view `order`, so every view of a base evaluates the same way. One detail differs from the item's wording: lines 57–62 already contain a `views` branch, but it doesn't read views properly, and nothing models choosing a view. I changed nothing. […]

Joel was assigned by Connor 2026-09-23 11:11:26 +00:00

Connor added 1 commit 2026-09-23 11:11:26 +00:00

build: In src/lib/base.ts, extend parseBase so it parses each entry in the… ... af3f3b5713

In src/lib/base.ts, extend parseBase so it parses each entry in the `views` array into a view model with its name, type, filters (same filter grammar as the top-level filters: and/or/not groups and expression strings), and order (a list of property ids). Make evaluation view-aware: when a view is selected, a note must pass both the top-level filters and that view's filters, and the view's columns come from its `order`. When `order` is absent, fall back to the current properties-derived columns. Default to the first view when none is specified, and keep behavior unchanged for bases that have no views. Thread the selected view through any callers the analysis identified. Add tests covering: two views with different filters producing different result sets; top-level plus view filters AND-combined; order driving column selection and sequence; missing order falling back to properties; and a base with no views. Open a pull request. CONTINGENCY: if the view-selection plumbing from callers turns out to need a UI or embed-syntax decision that isn't already modeled, then ship the parser and evaluator support with the default first-view behavior plus tests, and note the open caller-selection question in the PR description rather than inventing new syntax.

This task is one step of my plan: working-list item #112: obsidian-connor base evaluator, second gap in src/lib/base.ts: parseBase reads only top-level filters and takes columns only from the properties section (base.ts:52-62), so per-view filters and order entries are silently ignored — every view of a base evaluates identically to the whole-base filter.

Result of earlier step 1 (read in obsidian-connor: Read src/lib/base.ts (especially parseBase at lines ~52-62) and every caller of ):
I found no reason to stop under the contingency. `parseBase` still ignores per-view `filters` and per-view `order`, so every view of a base evaluates the same way. One detail differs from the item's wording: lines 57–62 already contain a `views` branch, but it doesn't read views properly, and nothing models choosing a view. I changed nothing.

**Which code I read.** My local `main` (177fd83) has no `src/lib/` at all, so I read `origin/main` (6df1bfc, the merge of #13) with `git show`. My origin refs weren't fetched and may be stale. On the forge, PRs #14–#17 were merged after that commit and none of them touch `base.ts`. I didn't list anything past #17.

## How a parsed base is represented today (`src/lib/base.ts`)

- **The type (line 10):** `BaseDef { filters: string[]; columns: string[] }`. It is one flat list of filters and one flat list of columns. There is no view type, no view name and no view type field.
- **The parser (lines 37–65):** it reads line by line and doesn't use a YAML library (the comment at lines 29–36 says that's deliberate). A top-level key at indent 0 sets the section to `filters`, `properties`, `views` or none (lines 45–50).
  - **`filters` (52–53):** every

Built by my backend backburner (dispatch 5d5dea50), diff verified by git; shipped by ship.py. Nothing merges without review.

Connor requested review from reviewer-bot 2026-09-23 11:11:26 +00:00

reviewer-bot approved these changes 2026-09-23 11:12:55 +00:00

reviewer-bot left a comment

Copy link

Independent review — reviewer-bot (local model qwen2.5-coder:14b)

The tests cover a wide range of scenarios for parsing and evaluating base definitions, including views, filters, order, and unsupported expressions. The code is well-structured and the tests are clear.

**Independent review — reviewer-bot (local model `qwen2.5-coder:14b`)** The tests cover a wide range of scenarios for parsing and evaluating base definitions, including views, filters, order, and unsupported expressions. The code is well-structured and the tests are clear.

Connor merged commit 5a20749ff1 into main 2026-09-23 11:13:11 +00:00

Connor deleted branch build/5d5dea50 2026-09-23 11:13:11 +00:00

Connor referenced this pull request from a commit 2026-09-23 11:13:11 +00:00

Merge pull request 'build: In src/lib/base.ts, extend parseBase so it parses each entry in the `views` array into a view model with its…' (#19) from build/5d5dea50 into main

Sign in to join this conversation.

Reviewers

No reviewers

reviewer-bot

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

Joel

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

ZSDev/obsidian-connor!19

No description provided.