-
Notifications
You must be signed in to change notification settings - Fork 0
Feature/show precomputed results tweaks #146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the state management to ensure a single source of truth by consolidating data storage and introducing composed selectors. The main focus is on renaming PackingInputs to RecipeManifest, restructuring how packing results are stored, and preventing redundant state storage.
Key changes:
- Renamed
PackingInputstype toRecipeManifestandresult_pathfield todefaultResultPath - Introduced
PackingResultstype and consolidated result-related state into a single object - Refactored
useResultUrlselector to derive the result URL from either packing results or default paths
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/utils/firebase.ts | Updated type references from PackingInputs to RecipeManifest and changed field name to defaultResultPath |
| src/types/index.ts | Renamed PackingInputs to RecipeManifest, added new PackingResults type |
| src/state/store.ts | Replaced setResultUrl with setPackingResults, added compound selectors for deriving result URLs |
| src/components/Viewer/index.tsx | Removed props, now uses useResultUrl hook and constructs full URL internally |
| src/components/Dropdown/index.tsx | Updated type reference from PackingInputs to RecipeManifest |
| src/App.tsx | Updated to use setPackingResults instead of setResultUrl, constructs PackingResults objects |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…computed-results-tweaks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| inputOptions: Record<string, PackingInputs>; | ||
| inputOptions: Record<string, RecipeManifest>; | ||
| recipes: Record<string, RecipeData>; | ||
| packingResults: PackingResults; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think ideally we want packingResults to be a Record<string, PackingResults>, with recipeId as the key, so that when a user navigates back to a recipe that they previously ran, the results of that last run are displayed rather than the pre-computed results
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I was thinking about that, maybe good to have in a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 9 out of 9 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
…hub.com/AllenCell/cellpack-client into feature/show-precomputed-results-tweaks
…nto feature/show-precomputed-results-tweaks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| setPackingResults({ | ||
| jobId: id, | ||
| jobLogs: `Packing job failed: ${localJobStatus.error_message}`, | ||
| resultUrl: "", | ||
| runTime: range, | ||
| outputDir: "", | ||
| }); |
Copilot
AI
Nov 10, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The jobLogs field is being set in the FAILED case but left empty in the DONE case (line 148). This inconsistency means successful jobs lose their logs. Consider preserving the existing jobLogs value or fetching/storing logs for successful jobs as well.
|
@meganrm I'm going to review this now and FYI I made a new branch, pointing at this one to handle the single source of turth issue. The old branch was too different from this, and from main, and was doing too much given how many active lines of development there are. It is here: #150 That is what I hope to merge into this. I will delete: #134 once it isn't relevant for context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good.
I appreciate bringing in some of the changes from the original SSOT branch.
I think https://github.com/AllenCell/cellpack-client/pull/150/files will be a more targeted next PR and in subsequent PRs we can address things like
- final shape of
RecipeManifest/RecipeData - when to load recipes vs recipe metadata
- testing
| }, | ||
|
|
||
| selectRecipe: async (recipeId) => { | ||
| get().setPackingResults({ ...EMPTY_PACKING_RESULTS }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: part of why I froze this object was so avoid triggering re-renders if we use EMPTY_PACKING_RESULTS when that's already in state.
Won't be a big deal either way, but in a case like this the spread creates a new object, so subscribers will re-render, even if packing results were already empty before calling selectRecipe. At least I think so.
| recipe: string; | ||
| result_path?: string; | ||
| defaultResultPath?: string; | ||
| editable_fields?: EditableField[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use camel case here?
Problem
I made some changes to how you were storing things in the store.
The main things I was trying to address is