[ResourceApp][Frontend][REFACTOR] Resource Feature Extraction#73
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request implements a significant refactoring of the frontend application by extracting all resource-related logic into a self-contained feature module. This change enhances modularity, improves separation of concerns, and streamlines the global application context, making the codebase more maintainable and scalable. The primary impact is a cleaner architecture where resource management is isolated and independently manageable. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request does a great job of refactoring the resource management logic into its own dedicated feature module, following DDD principles. The code is well-structured, and the separation of concerns between the AppContext and the new ResourceContext is clear. I've identified a few areas for improvement regarding type safety, key generation, and code maintainability. My detailed comments are below.
- Default new resources to isActive true on creation - Replace Date.now() with a stable ref counter for form field IDs - Replace color ternary chains with lookup maps in catalog and creation views
- Align submit button disabled state with form validation logic - Surface resource loading and error states in the global app shell - Add safe fallback for specs to prevent crash on missing data - Make reschedule inputs controlled and reset state on modal close - Clear reschedule time state when opening the propose time modal
…eedback - Replace ref counter with crypto.randomUUID() for globally unique field IDs - Add MutationResult type to addResource and updateResource for typed error propagation - Surface submit errors to the user via an inline error banner in the form footer - update useCalendar to get resources from resource context
3 participants
Context
Part of the incremental Domain-Driven Design (DDD) refactoring of the frontend.
What changed
Why
The resource entity is the core of this application. Giving it a dedicated feature module with owned views and business logic keeps all resource concerns co-located, naturally prevents unstable dependency looping, and dramatically reduces the bloat of the global context array.
Acceptance Criteria
features/resource/exists with all subfoldersuseResourceContext()returns{ resources, stats, addResource, ... }useResourceFormimports from resource domain onlyViews use
useResourceContext()instead ofuseApp()AppContext.tsxno longer manages resource statenpm run buildpasses with 0 TypeScript errorsCloses [ResourceApp][Frontend][REFACTOR] Introduce Resource domain with context, API layer, and owned views #59
Closes [ResourceApp][Frontend][BUG]: Analytics Stats Fetch Loops Infinitely on Analytics Tab #80