mjasin/Nexus.Reader
1
0
Fork 0
Code Issues 9 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

fix(ingest): implement beautiful upload loading state and fix button loading spinner visibility (#66)

Browse Source 
This Pull Request fixes the book upload dialog box's lack of visual feedback during the file ingestion process.

### Key Changes:
1. **Interactive `ingesting-state` Loading State**: Added a dedicated, beautiful neon-green loader that displays `Saving book to library...` with a pulsing neon spinner while the HTTP POST upload request is in flight. This cleanly replaces the form during ingestion, preventing users from clicking disabled/unresponsive inputs or submitting twice.
2. **Premium Glowing Button Loader**: Updated `.btn-loading` styling in `BookIngestionModal.razor.css` to use a high-contrast white-and-neon-green glowing spinner (`border-top-color: var(--nexus-neon)`) instead of an invisible black `#000` spinner on a faded, disabled dark button.
3. **Build & Test Verified**: Successfully verified that the entire solution compiles cleanly with 0 compilation errors (`dotnet build`) and that all unit/integration tests continue to pass perfectly (`dotnet test`).

---------

Co-authored-by: Marek Jasiński <jasins.marek@gmail.com>
Reviewed-on: #66
Co-authored-by: Antigravity <antigravity@google.com>
Co-committed-by: Antigravity <antigravity@google.com>
This commit was merged in pull request #66.
This commit is contained in:
Antigravity
2026-06-01 16:42:08 +00:00
committed by Marek Jaisński
parent bf31effd36
commit 036ae26109
6 changed files with 182 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agent/skills/nexus-code-review/SKILL.md
+11 -1
View File
@@ -30,4 +30,14 @@ When conducting or receiving a code review for NexusReader, ensure the implement
- [ ] **AI Prompts**: Ensure changes to AI logic do not bypass the `PromptRegistry` or token estimation limits defined in `AiSettings`.
## 6. Code Review Comments
- [ ] **Specific Linking**: Comments should be linked to specific code. Try to avoid general comments about the entire pull request.
### 6.1 Posting Comments
- [ ] **Code-Linked Comments**: Every review comment **must** be anchored to a specific file and line range using the Gitea inline comment API (`path` + `new_line_num`/`old_line_num`). Free-floating general comments are only acceptable for summary notes that cannot be attributed to a single location.
- [ ] **Severity Prefix**: Prefix each comment with its severity so the author can prioritize: `🔴 Blocking`, `🟡 Design/Architecture`, or `🟢 Minor/Suggestion`.
- [ ] **Actionable Guidance**: Each comment must include a concrete, actionable suggestion — not just a description of the problem. Where applicable, provide a corrected code snippet.
### 6.2 Resolving Comments (Author Responsibility)
- [ ] **Reply Before Resolving**: When a review comment has been addressed, the author **must** reply to the specific thread explaining *how* the issue was resolved (e.g., commit SHA, approach taken, or a reasoned rejection with justification). Do not close a thread without a reply.
- [ ] **Link to Fix**: If the resolution is a code change, include the commit SHA or a reference to the changed line in the reply (e.g., `Fixed in abc1234 — moved the guard before CTS allocation`).
- [ ] **Close Only After Reply**: Mark a thread as **Resolved** only after posting the reply. A thread with no reply must remain open, even if the underlying code has changed.
- [ ] **Rejection Must Be Justified**: If the author disagrees with a comment and chooses not to act on it, they must reply with a clear technical justification. The reviewer then decides whether to accept the reasoning and close the thread, or escalate it.