Skip to content

fix: address Obsidian plugin review findings - #95

Merged
frostmute merged 1 commit into
mainfrom
fix/obsidian-plugin-review-findings
Sep 1, 2026
Merged

fix: address Obsidian plugin review findings#95
frostmute merged 1 commit into
mainfrom
fix/obsidian-plugin-review-findings

Conversation

@frostmute

Copy link
Copy Markdown
Owner

Addresses the verified Obsidian plugin review findings and updates the affected settings tests.

Copilot AI lite review requested due to automatic review settings September 1, 2026 16:46
@frostmute
frostmute merged commit c3346b1 into main Sep 1, 2026
4 checks passed
@frostmute
frostmute deleted the fix/obsidian-plugin-review-findings branch September 1, 2026 16:46

Copilot AI 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.

🟡 Changes recommended

The settings tab no longer overrides display(), which is the lifecycle entry point in Obsidian (and in this repo’s mocks), so the UI may not render unless display() delegates to update().

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the Obsidian settings/UI code to address plugin review findings (Obsidian 1.13+ API changes) and aligns unit tests with the updated settings-tab rendering flow.

Changes:

  • Refactors the settings tab rendering to focus on update() and documents the declarative settings API behavior.
  • Updates UI components for Obsidian 1.13+ (e.g., setDestructive()), and removes inline style toggling in favor of CSS classes in modals.
  • Adjusts settings unit tests to validate the updated rendering lifecycle.
File summaries
File Description
tests/unit/settings.test.ts Updates tests to exercise the new settings-tab rendering path.
src/settings.ts Refactors settings-tab lifecycle/rendering and updates button API usage for Obsidian 1.13+.
src/modals.ts Minor UI cleanup (dropdown loop style) and switches error visibility to class-based toggling.
Review details
  • Files reviewed: 3/3 changed files
  • Comments generated: 2
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread src/settings.ts
Comment on lines 381 to 386
/**
* Obsidian's settings-tab lifecycle entry point.
*
* Keep the actual renderer in update() so existing refreshes from setting
* controls continue to work, while ensuring Obsidian invokes the renderer
* when the tab is opened (including Obsidian 1.13+).
*/
display(): void {
this.update();
}

/**
* Imperative settings renderer shared by display() and in-tab refreshes.
* getSettingDefinitions() returns [] because this tab intentionally uses
* the richer imperative UI rather than declarative setting indexing.
* Obsidian's current settings-tab lifecycle renderer. Obsidian invokes
* update() when the tab opens, and controls can call it to refresh the
* imperative UI in place.
*/
update(): void {
Comment on lines +31 to 35
it('should render settings options during the current update lifecycle', () => {
const container = tab.containerEl;
tab.display();
tab.update();

expect(container.classList.contains('make-it-rain-settings-container')).toBe(true);
frostmute added a commit that referenced this pull request Sep 4, 2026
…update()

PR #95 dropped the PluginSettingTab.display() override while keeping
getSettingDefinitions() returning an empty array. Obsidian 1.13+ falls
back to display() to render the tab imperatively when the definitions
list is empty; update() alone stores definitions for the declarative
path and the search index. With display() removed, the framework
falls through to the base no-op, leaving the pane blank (Issue #87
regression reported in 2.1.3).

display() is kept as a one-line bridge to the existing imperative
renderer. update() remains the refresh entry point for in-tab state
changes. Both delegate to the same renderer, so the DOM shape is
unchanged.
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.

2 participants