feat(visualization): add protein viewer - #31
Merged
Conversation
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
Reviewer's GuideImplements a reusable Protein Viewer atop the existing GenomeAI visualization stack, including typed protein models, pure sequence/viewport/geometry utilities, a React SVG viewer, shared pan/zoom/row-packing helpers, and documentation/tests, while keeping navigation and geometry consistent with the genome viewers and maintaining API boundaries. Sequence diagram for Protein Viewer zoom/pan navigation reusesequenceDiagram
actor User
participant ProteinViewer
participant useProteinViewer
participant protein_viewport as zoomProteinViewport
participant genome_viewport as zoomViewport
User->>ProteinViewer: Click Zoom in
ProteinViewer->>useProteinViewer: zoomIn()
useProteinViewer->>protein_viewport: zoomProteinViewport(viewport, 1 / ZOOM_FACTOR)
protein_viewport->>genome_viewport: zoomViewport(viewport, factor)
genome_viewport-->>protein_viewport: updated IntervalWindow
protein_viewport-->>useProteinViewer: updated ProteinViewport
useProteinViewer-->>ProteinViewer: result.viewport
User->>ProteinViewer: Click Scroll right
ProteinViewer->>useProteinViewer: panRight()
useProteinViewer->>protein_viewport: panProteinViewport(viewport, panFraction(viewport, 1))
protein_viewport->>genome_viewport: panViewport(viewport, delta)
genome_viewport-->>protein_viewport: updated IntervalWindow
protein_viewport-->>useProteinViewer: updated ProteinViewport
useProteinViewer-->>ProteinViewer: result.viewport
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
Next review available in: 47 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (30)
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. Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- There are now two
IntervalWindowtypes (ingenome/viewport.tsandgenome/geometry.ts) with slightly different shapes; consider consolidating to a single shared definition to avoid semantic drift between window math and interval clipping. - The interactive feature selection rect in
ProteinVieweruses a very small minimum hit-target width (FEATURE_HIT_MIN_PX = 6); increasing this to a more accessible size (e.g., ~24px or using a larger overlay) would improve keyboard and pointer usability on densely packed features.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- There are now two `IntervalWindow` types (in `genome/viewport.ts` and `genome/geometry.ts`) with slightly different shapes; consider consolidating to a single shared definition to avoid semantic drift between window math and interval clipping.
- The interactive feature selection rect in `ProteinViewer` uses a very small minimum hit-target width (`FEATURE_HIT_MIN_PX = 6`); increasing this to a more accessible size (e.g., ~24px or using a larger overlay) would improve keyboard and pointer usability on densely packed features.
## Individual Comments
### Comment 1
<location path="apps/web/src/lib/protein/api.ts" line_range="193-195" />
<code_context>
+ .filter((value): value is RawProteinRecord => typeof value === 'object' && value !== null)
+ .map((record) => toProtein(record))
+ .filter(isValidProtein)
+ .map((protein) => ({
+ ...protein,
+ features:
+ protein.features.length > 0 ? protein.features : prepareFeatures(featureSource(protein)),
+ }))
</code_context>
<issue_to_address>
**issue (bug_risk):** Pass protein length into `prepareFeatures` so out-of-range feature spans are rejected consistently.
Because `prepareFeatures` is called without the protein length, `isValidFeature` never runs the upper-bound check, so features with `end` beyond the sequence length are still accepted. In `fetchProteins`, please call `prepareFeatures(featureSource(protein), protein.length)` so all synthetic or API-provided features are consistently validated and cannot render outside the protein window.
</issue_to_address>
### Comment 2
<location path="docs/visualization/roadmap.md" line_range="23-24" />
<code_context>
+ navigation
+- Pure geometry (`lib/protein/geometry.ts`) — residue/feature pixel mapping and
+ axis-critical ticks via the shared genome scale, stable row packing
+- Feature presentation helpers (`lib/protein/features.ts`) — type
+ normalization, colors, labels, accessible labels, detail rows
+- Thin typed adapter (`lib/protein/api.ts`) over the existing protein endpoint
+ (`GET /proteins/{id}`, no backend changes) with injectable feature source
</code_context>
<issue_to_address>
**nitpick (typo):** Consider aligning spelling of "colors/colours" across related documentation sections.
This roadmap entry uses "colors" for the feature presentation helpers, while `protein-viewer.md` uses "colours" for the same concept. Please standardize on one spelling (US or UK) across the visualization docs for consistency.
Suggested implementation:
```
- Feature presentation helpers (`lib/protein/features.ts`) — type
normalization, colours, labels, accessible labels, detail rows
```
To fully implement the suggestion, you should also:
1. Verify other visualization-related docs (e.g. `docs/visualization/protein-viewer.md` and any related files) for mixed "color/colour" usage and standardize them on "colours".
2. Optionally add a short style note to your documentation guidelines indicating that UK spelling ("colour/colours") is preferred for visualization terminology, to prevent future inconsistency.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Address the Sourcery review on #31: - Pass the protein length into prepareFeatures so feature spans that extend past the sequence end are rejected (bug fix + regression test) - Consolidate the duplicate IntervalWindow shapes into the shared genome types; viewport math and interval clipping now import one definition - Enlarge the feature selection hit target from 6px to 24px for keyboard/pointer accessibility - Standardize "colors" -> "colours" wording in the roadmap doc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements Phase 6.5 — Protein Viewer of the GenomeAI Visualization Platform.
This PR adds a reusable protein sequence and annotation visualization layer on top of the existing GenomeAI visualization architecture.
The implementation builds on the existing Genome Browser, Gene/Transcript Viewer, Variant Viewer, visualization utilities, and API boundaries.
Features
Protein Viewer
Protein Data Model
Introduces strongly typed models for:
The viewer uses a consistent biological coordinate convention and keeps coordinate/geometry logic separate from UI rendering.
Visualization Architecture
The implementation follows the existing GenomeAI visualization architecture:
Reusable sequence, feature, viewport, geometry, and API utilities are separated from the React components.
API Boundary
The Protein Viewer uses the GenomeAI API/data abstraction rather than making direct browser requests to external scientific databases.
No direct client-side integration with:
is introduced by this PR.
External scientific data ingestion and synchronization remain outside the scope of Phase 6.5.
Rendering Scope
This phase intentionally focuses on:
It does not implement 3D molecular structure rendering.
No C++, WebAssembly, WebGPU, or new 3D rendering dependency is introduced.
Testing
Added/updated tests covering:
Existing GenomeAI tests remain unchanged and must continue to pass.
Verification
Run:
Also manually verify the visualization application and existing visualization routes.
Compatibility
Roadmap Progress
Phase 6 — Visualization Platform
Next
Phase 6.6 — Biological Network Viewer
Planned capabilities include:
Scope Boundary
This PR does not implement:
Those capabilities will be implemented only in their designated future phases.
Summary by Sourcery
Add a new Phase 6.5 protein sequence and annotation viewer to the GenomeAI visualization platform, including its React component, typed protein data/viewport/geometry utilities shared with existing genome viewers, API adapters, fixtures, and tests, while updating roadmap and visualization docs and demos to integrate the new module and generalizing common geometry, viewport, and row layout helpers.
New Features:
useProteinViewerhook that reuse and extend existing visualization infrastructure.Enhancements:
IntervalWindowabstraction), and row-packing utilities so genomic and protein visualizations share consistent interval and layout logic.asString,asNumber,idOf) into the genome API module for reuse across gene/transcript and protein adapters.Documentation:
Tests:
useProteinViewerhook, and the Protein Viewer component states and interactions, while keeping existing genome visualization tests passing.