Implement calendar-aware date handling for forms and date pickers#495
Merged
Conversation
…ased on the selected calendar year
…ers, like uploading files
…ear to current year
… back to rotation
Contributor
|
👋 Hotfix Branch PR Detected! Before merging this Pull Request into This will:
You can trigger the workflow from the 'Actions' tab, selecting the 'Release' workflow, and choosing this |
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe changes implement calendar-year-aware date parsing and contextual default date initialization across forms and date picker components. Date inputs are now parsed using the active cultivation year from the calendar store for disambiguation, and form defaults leverage domain-specific dates aligned with the calendar year rather than the current system date. Navigation progress metrics are enhanced with Sentry instrumentation and route-level opt-out support, and nitrogen balance calculation is refined to use ammonia-specific emissions. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant DatePicker as DatePicker Component
participant Calendar as useCalendarStore
participant Parser as parseDateString / parseDutchNumericDate
participant Form as Form Component
User->>DatePicker: Input date text (e.g., "15 april")
DatePicker->>Calendar: Read active calendar year
Calendar-->>DatePicker: Return calendar year (e.g., 2023)
DatePicker->>Parser: parseDateString(input, calendarYear)
alt Dutch Numeric Format
Parser->>Parser: parseDutchNumericDate("15-04", 2023)
Parser-->>DatePicker: Date(2023-04-15)
else Chrono Parsing
Parser->>Parser: Chrono parse with referenceDate in calendar year
Parser-->>DatePicker: Date(2023-04-15)
else ISO Format
Parser->>Parser: Parse ISO string YYYY-MM-DD
Parser-->>DatePicker: Date parsed
end
DatePicker->>Form: Set field value
Form-->>User: Display parsed date with calendar context
sequenceDiagram
participant Form as Form Component
participant Calendar as useCalendarStore
participant Lib as getContextualDate()
participant Store as FieldFertilizerFormStore
Form->>Calendar: Read active calendar year
Calendar-->>Form: Return calendar (e.g., "2023")
alt Creating New Record
Form->>Lib: getContextualDate(calendar, month, day)
Lib->>Lib: Check if calendar year == current year
alt Calendar Year is Current Year
Lib-->>Form: Today's date
else Calendar Year is Different
Lib-->>Form: month/day in calendar year
end
Form->>Form: Use contextual date as defaultValue
else Loading Existing Record
Form->>Store: load(b_id_farm, b_id, calendar)
Store-->>Form: Saved form data
Form->>Form: Use loaded values
end
Form-->>User: Display form with contextual default date
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Collaborator
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
coderabbitai
Bot
changed the title
Contributor
|
✅ Created PR with unit tests: #496 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
fdm-app/app/components/blocks/fertilizer-applications/form.tsx (1)
83-100:⚠️ Potential issue | 🟠 MajorMake the saved fertilizer draft calendar-aware.
The new default now depends on
calendar, but the persisted draft still keys only on(b_id_farm, b_id_or_b_lu_catalogue). A draft saved in one cultivation year will therefore be reloaded unchanged in another for the same farm/catalogue, overridinggetContextualDate(calendar, 3, 1)with the wrongp_app_date. Includecalendarin the save/load/delete key, or drop a restored date whose year no longer matches the active calendar.🧭 Call-site changes needed here
- const savedFormValues = fieldFertilizerFormStore.load( - b_id_farm, - b_id_or_b_lu_catalogue, - ) + const savedFormValues = fieldFertilizerFormStore.load( + b_id_farm, + b_id_or_b_lu_catalogue, + calendar, + ) ... - fieldFertilizerFormStore.delete(b_id_farm, b_id_or_b_lu_catalogue) + fieldFertilizerFormStore.delete( + b_id_farm, + b_id_or_b_lu_catalogue, + calendar, + ) ... - fieldFertilizerFormStore.save( - b_id_farm, - b_id_or_b_lu_catalogue, - form.getValues(), - ) + fieldFertilizerFormStore.save( + b_id_farm, + b_id_or_b_lu_catalogue, + calendar, + form.getValues(), + )This needs the corresponding store API update as well.
Also applies to: 121-143, 160-177
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fdm-app/app/components/blocks/fertilizer-applications/form.tsx` around lines 83 - 100, The draft save/load/delete logic for fertilizer applications is not calendar-aware: when building defaultValues (notably p_app_date computed via getContextualDate(calendar, 3, 1)) you must either include the active calendar value from useCalendarStore() in the draft storage key OR, on restore, discard any restored p_app_date whose year doesn't match the active calendar; update the code paths that persist and read drafts (the store API used by this component) to accept the calendar identifier and use it in the key (or implement the year-check/drop behavior) so restored drafts don't override the contextual date; ensure changes touch the save, load and delete call sites mentioned in this file (and the store API) so keys remain consistent across cultivation years.fdm-app/app/components/custom/navigation-progress.tsx (1)
29-55:⚠️ Potential issue | 🟡 MinorAdd
hideProgressto the effect's dependency array.The effect reads
hideProgressto conditionally start the timer (line 30), but it's not included in the dependency array (line 55). IfhideProgresschanges during navigation (e.g., user navigates between routes with differenthandleconfigurations), the effect won't re-run, potentially showing the indicator when it should be hidden.🛠️ Proposed fix
- }, [state, show]) + }, [state, show, hideProgress])🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fdm-app/app/components/custom/navigation-progress.tsx` around lines 29 - 55, The useEffect reading hideProgress (used in the conditional that starts the timer) must include hideProgress in its dependency array so the effect re-runs when it changes; update the dependency list for the useEffect that references state, show, startTimeRef, setShow and clientConfig/Sentry.metrics to also include hideProgress so the timer is started or cancelled correctly when hideProgress toggles during navigation.
🧹 Nitpick comments (3)
fdm-app/app/lib/calendar.ts (1)
52-64: HardengetContextualDateagainst invalid year strings.
Number(calendar)can becomeNaN, andnew Date(NaN, ...)then feeds anInvalid Dateinto the form defaults. A small guard here would make the helper safe if it gets reused outside the store-backed path.🛡️ Suggested guard
export function getContextualDate( calendar: string | undefined, defaultMonth: number, defaultDay: number, ): Date { const currentYear = new Date().getFullYear() - const calendarYear = calendar ? Number(calendar) : currentYear + const parsedYear = calendar ? Number(calendar) : currentYear + const calendarYear = Number.isInteger(parsedYear) + ? parsedYear + : currentYear if (calendarYear === currentYear) { return new Date() }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fdm-app/app/lib/calendar.ts` around lines 52 - 64, The getContextualDate function can produce NaN when parsing calendar with Number(calendar); change the guard in getContextualDate to validate parsed year (e.g., const parsed = Number(calendar)) and if parsed is NaN or not an integer within a sane range, fall back to currentYear; keep the existing behavior of returning new Date() when year equals currentYear and otherwise returning new Date(parsed, defaultMonth - 1, defaultDay) so callers never receive Invalid Date.fdm-app/app/components/custom/date-picker-v2.tsx (1)
188-260: Consider extracting shared date parsing logic to a utility module.Both
date-picker.tsxanddate-picker-v2.tsxnow have nearly identical implementations ofparseDutchNumericDateand similar calendar-aware parsing logic. Extracting these to a shared utility (e.g.,~/lib/date-utils.ts) would reduce duplication and ensure consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fdm-app/app/components/custom/date-picker-v2.tsx` around lines 188 - 260, Duplicate date parsing logic exists in parseDateText and parseDutchNumericDate across date-picker.tsx and date-picker-v2.tsx; extract the shared functions into a new utility module (e.g., ~/lib/date-utils.ts) that exports parseDutchNumericDate and a calendar-aware parseDateText (or smaller helpers used by parseDateText), update both components to import those functions, remove the duplicated implementations from both components, and ensure exports/imports preserve signatures (parseDateText(date: string|Date|undefined, calendarYear?: number) and parseDutchNumericDate(text: string, targetYear: number)) so behavior remains identical.fdm-app/app/routes/farm.$b_id_farm.$calendar.rotation_.harvest._index.tsx (1)
329-333: Consider simplifying redundant catalogue lookup.
targetCultivationis already found fromcultivationCatalogueDataat line 176-178. Searching the same array again for the sameb_lu_cataloguewill return the same object.♻️ Suggested simplification
- const b_date_harvest_default = - cultivationCatalogueData.find( - (item) => - item.b_lu_catalogue === targetCultivation.b_lu_catalogue, - )?.b_date_harvest_default ?? null + const b_date_harvest_default = + targetCultivation.b_date_harvest_default ?? null🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fdm-app/app/routes/farm`.$b_id_farm.$calendar.rotation_.harvest._index.tsx around lines 329 - 333, The code redundantly re-searches cultivationCatalogueData to derive b_date_harvest_default; instead use the already-found targetCultivation. Replace the find-based lookup with reading targetCultivation?.b_date_harvest_default ?? null so b_date_harvest_default comes directly from targetCultivation (references: b_date_harvest_default, cultivationCatalogueData, targetCultivation).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.changeset/fifty-frogs-float.md:
- Line 5: Update the release note in .changeset/fifty-frogs-float.md to correct
the harvest example: remove the fixed “August 1st” wording and state that the
harvest flow uses the cultivation's configured b_date_harvest_default for
non-current years while harvest dates remain empty for the current calendar
year; also keep the DatePicker behavior note about resolving partial text to the
active calendar year unchanged.
In @.changeset/seven-days-nail.md:
- Line 5: Update the changelog entry string that contains the typo "calender" to
the correct spelling "calendar" in the .changeset/seven-days-nail.md file;
specifically replace the phrase "Fix that going to Fertilizers page does not
reset the selected calender year to current year" with the corrected phrase "Fix
that going to Fertilizers page does not reset the selected calendar year to
current year" so the change description reads correctly.
In `@fdm-app/app/components/blocks/harvest/form.tsx`:
- Around line 84-86: The code converts calendar from useCalendarStore() with
Number(calendar) which can produce NaN for non-numeric values like "all"; change
the logic that sets calendarYear so it parses calendar into a number (e.g.,
const parsed = Number(calendar)) and uses Number.isNaN(parsed) to fall back to
currentYear when parsed is NaN, ensuring calendarYear is always a valid number
before later comparisons and before constructing dates (the new Date(...) call)
so you never pass NaN into Date.
---
Outside diff comments:
In `@fdm-app/app/components/blocks/fertilizer-applications/form.tsx`:
- Around line 83-100: The draft save/load/delete logic for fertilizer
applications is not calendar-aware: when building defaultValues (notably
p_app_date computed via getContextualDate(calendar, 3, 1)) you must either
include the active calendar value from useCalendarStore() in the draft storage
key OR, on restore, discard any restored p_app_date whose year doesn't match the
active calendar; update the code paths that persist and read drafts (the store
API used by this component) to accept the calendar identifier and use it in the
key (or implement the year-check/drop behavior) so restored drafts don't
override the contextual date; ensure changes touch the save, load and delete
call sites mentioned in this file (and the store API) so keys remain consistent
across cultivation years.
In `@fdm-app/app/components/custom/navigation-progress.tsx`:
- Around line 29-55: The useEffect reading hideProgress (used in the conditional
that starts the timer) must include hideProgress in its dependency array so the
effect re-runs when it changes; update the dependency list for the useEffect
that references state, show, startTimeRef, setShow and
clientConfig/Sentry.metrics to also include hideProgress so the timer is started
or cancelled correctly when hideProgress toggles during navigation.
---
Nitpick comments:
In `@fdm-app/app/components/custom/date-picker-v2.tsx`:
- Around line 188-260: Duplicate date parsing logic exists in parseDateText and
parseDutchNumericDate across date-picker.tsx and date-picker-v2.tsx; extract the
shared functions into a new utility module (e.g., ~/lib/date-utils.ts) that
exports parseDutchNumericDate and a calendar-aware parseDateText (or smaller
helpers used by parseDateText), update both components to import those
functions, remove the duplicated implementations from both components, and
ensure exports/imports preserve signatures (parseDateText(date:
string|Date|undefined, calendarYear?: number) and parseDutchNumericDate(text:
string, targetYear: number)) so behavior remains identical.
In `@fdm-app/app/lib/calendar.ts`:
- Around line 52-64: The getContextualDate function can produce NaN when parsing
calendar with Number(calendar); change the guard in getContextualDate to
validate parsed year (e.g., const parsed = Number(calendar)) and if parsed is
NaN or not an integer within a sane range, fall back to currentYear; keep the
existing behavior of returning new Date() when year equals currentYear and
otherwise returning new Date(parsed, defaultMonth - 1, defaultDay) so callers
never receive Invalid Date.
In `@fdm-app/app/routes/farm`.$b_id_farm.$calendar.rotation_.harvest._index.tsx:
- Around line 329-333: The code redundantly re-searches cultivationCatalogueData
to derive b_date_harvest_default; instead use the already-found
targetCultivation. Replace the find-based lookup with reading
targetCultivation?.b_date_harvest_default ?? null so b_date_harvest_default
comes directly from targetCultivation (references: b_date_harvest_default,
cultivationCatalogueData, targetCultivation).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ce7d834f-9350-47c9-95c4-bf45f6a01ed5
📒 Files selected for processing (19)
.changeset/brave-eagles-hide.md.changeset/dirty-rooms-doubt.md.changeset/fifty-frogs-float.md.changeset/nine-cups-start.md.changeset/seven-days-nail.mdfdm-app/app/components/blocks/fertilizer-applications/form.tsxfdm-app/app/components/blocks/harvest/form.tsxfdm-app/app/components/blocks/soil/form.tsxfdm-app/app/components/custom/date-picker-v2.tsxfdm-app/app/components/custom/date-picker.tsxfdm-app/app/components/custom/navigation-progress.tsxfdm-app/app/lib/calendar.tsfdm-app/app/routes/farm.$b_id_farm.$calendar.field.$b_id.cultivation.$b_lu.harvest.new.tsxfdm-app/app/routes/farm.$b_id_farm.$calendar.field.fertilizer._index.tsxfdm-app/app/routes/farm.$b_id_farm.$calendar.rotation_.harvest._index.tsxfdm-app/app/routes/farm.$b_id_farm.soil-analysis.bulk.tsxfdm-app/app/routes/farm.create.$b_id_farm.$calendar.soil-analysis.bulk.tsxfdm-app/app/routes/farm.create.$b_id_farm.$calendar.upload.tsxfdm-app/app/routes/farm.tsx
Collaborator
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
fdm-app/app/components/blocks/fertilizer-applications/form.tsx (1)
83-100:⚠️ Potential issue | 🟠 MajorThe fertilizer default date still races the route calendar.
useCalendarStore()starts with the real current year, andfdm-app/app/routes/farm.tsx:103-112only syncs the URL calendar in an effect. That means Line 100 can still seedp_app_datewith today's date on the first render of a non-current-year route, and the load effect at Lines 121-145 does nothing when there is no saved draft for that key. BecauseuseRemixFormdoes not re-applydefaultValues, this form can still open with the wrong year. Please resetp_app_datewhencalendarchanges, or derive the route calendar before callinguseRemixForm.Also applies to: 121-145
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fdm-app/app/components/blocks/fertilizer-applications/form.tsx` around lines 83 - 100, The form can seed p_app_date with the wrong year because useCalendarStore() starts with the real current year and useRemixForm's defaultValues aren't re-applied; fix by deriving the route/calendar value before calling useRemixForm or by adding an effect that updates the form value when calendar changes: compute the correct calendar (the same logic used in the route) prior to invoking useRemixForm so getContextualDate(calendar, 3, 1) uses the route calendar, or after form creation add a useEffect watching calendar that calls the form API (e.g., setValue or reset) to set FieldFertilizerFormValues.p_app_date via getContextualDate when calendar changes (also apply same fix to the load/draft effect area around the existing load logic).
🧹 Nitpick comments (1)
fdm-app/app/components/custom/navigation-progress.tsx (1)
56-66: Inconsistent indentation in Sentry scope block.The
Sentry.withScopeblock on lines 56-65 has extra indentation compared to the similar block on lines 40-46. This appears to be a formatting inconsistency.🧹 Suggested fix for consistent indentation
if (clientConfig.analytics.sentry) { - Sentry.withScope((scope) => { - scope.setTag( - "page", - startPathnameRef.current ?? pathname, - ) - Sentry.metrics.distribution( - "navigation_progress.duration_ms", - duration, - ) - }) - } + Sentry.withScope((scope) => { + scope.setTag( + "page", + startPathnameRef.current ?? pathname, + ) + Sentry.metrics.distribution( + "navigation_progress.duration_ms", + duration, + ) + }) + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fdm-app/app/components/custom/navigation-progress.tsx` around lines 56 - 66, The Sentry.withScope block is indented inconsistently compared to the earlier similar block; update the indentation of the Sentry.withScope callback so its lines (Sentry.withScope, scope.setTag(...), and Sentry.metrics.distribution(...)) align with the other Sentry.withScope usage in the file, keeping the same nesting level and spacing and preserving references to startPathnameRef.current, pathname, and duration.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@fdm-app/app/components/blocks/harvest/form.tsx`:
- Around line 84-89: The form's defaultValues are built before
useCalendarStore() is populated, so getDefaultHarvestDate() can return undefined
and useRemixForm will keep that initial value; update the logic to reset or
rebuild the form when calendar changes (or accept the route calendar before
computing defaults). Specifically, after calling useRemixForm (or wherever
defaultValues are passed), call the form's reset method (or re-invoke
useRemixForm with new defaultValues) inside an effect that depends on calendar
from useCalendarStore(), and ensure getDefaultHarvestDate(...) is re-evaluated
using the updated calendar value (reference useCalendarStore,
getDefaultHarvestDate, useRemixForm, defaultValues, and reset) so the catalogue
default date for the active cultivation year is applied when the route-provided
calendar arrives.
---
Outside diff comments:
In `@fdm-app/app/components/blocks/fertilizer-applications/form.tsx`:
- Around line 83-100: The form can seed p_app_date with the wrong year because
useCalendarStore() starts with the real current year and useRemixForm's
defaultValues aren't re-applied; fix by deriving the route/calendar value before
calling useRemixForm or by adding an effect that updates the form value when
calendar changes: compute the correct calendar (the same logic used in the
route) prior to invoking useRemixForm so getContextualDate(calendar, 3, 1) uses
the route calendar, or after form creation add a useEffect watching calendar
that calls the form API (e.g., setValue or reset) to set
FieldFertilizerFormValues.p_app_date via getContextualDate when calendar changes
(also apply same fix to the load/draft effect area around the existing load
logic).
---
Nitpick comments:
In `@fdm-app/app/components/custom/navigation-progress.tsx`:
- Around line 56-66: The Sentry.withScope block is indented inconsistently
compared to the earlier similar block; update the indentation of the
Sentry.withScope callback so its lines (Sentry.withScope, scope.setTag(...), and
Sentry.metrics.distribution(...)) align with the other Sentry.withScope usage in
the file, keeping the same nesting level and spacing and preserving references
to startPathnameRef.current, pathname, and duration.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 13a2d89d-6ef4-46a7-8b75-01e72f85b08a
📒 Files selected for processing (8)
.changeset/fifty-frogs-float.md.changeset/seven-days-nail.md.changeset/social-cycles-stare.mdfdm-app/app/components/blocks/fertilizer-applications/form.tsxfdm-app/app/components/blocks/harvest/form.tsxfdm-app/app/components/custom/navigation-progress.tsxfdm-app/app/lib/calendar.tsfdm-app/app/store/field-fertilizer-form.tsx
🚧 Files skipped from review as they are similar to previous changes (3)
- .changeset/seven-days-nail.md
- fdm-app/app/lib/calendar.ts
- .changeset/fifty-frogs-float.md
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@fdm-app/app/components/blocks/fertilizer-applications/form.tsx`:
- Around line 119-131: The effect that backfills p_app_date (inside the
useEffect block) currently calls form.setValue unconditionally when calendar
loads and can overwrite a user-picked date; change the guard to only call
setValue when the form field is still empty and not dirty: inside the same
useEffect that references getContextualDate(calendar, 3, 1), read the current
field state/value via form.getFieldState("p_app_date")?.isDirty or
form.getValues("p_app_date") and only invoke form.setValue("p_app_date", ...) if
there is no exampleFertilizerApplication and the field value is falsy and
isDirty is false (or undefined).
- Around line 137-140: The calendar-scoped draft keys are half-migrated:
form.tsx now calls fieldFertilizerFormStore.load(b_id_farm,
b_id_or_b_lu_catalogue, calendar) but fertilizer-applications/card.tsx still
uses the legacy key shape (calls to fieldFertilizerFormStore.load and
fieldFertilizerFormStore.delete without calendar), causing drafts to be
orphaned; fix by either updating the calls in card.tsx to pass the calendar
argument wherever load/delete are invoked (the load calls around the previous
Lines 77-84 and delete calls around 98-101 and 139-142 and the other occurrences
at 178-198), or modify the store implementation (fieldFertilizerFormStore.load
and .delete) to try the new calendar-aware key first and fall back to the legacy
key (and migrate/clear the legacy entry when found) so both callers remain
compatible during rollout.
In `@fdm-app/app/components/blocks/harvest/form.tsx`:
- Around line 187-200: The effect is resetting the entire form via form.reset
when the calendar loads, which can overwrite a user-entered b_lu_harvest_date
and clear touched/dirty state; change the logic in the useEffect so that when
calendar updates you only set the harvest date if it’s currently empty (check
b_lu_harvest_date and example_b_lu_harvest_date) by calling
form.setValue('b_lu_harvest_date', getDefaultHarvestDate()) or, if you must call
form.reset, pass the option to preserve user edits (e.g., keepDirtyValues: true)
and avoid touching other fields; update the useEffect body around
form.reset/getDefaultHarvestDate accordingly to preserve dirty/touched state and
not overwrite an existing user value.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 4bb00a25-2f8f-4382-804f-53f26958ee9b
📒 Files selected for processing (2)
fdm-app/app/components/blocks/fertilizer-applications/form.tsxfdm-app/app/components/blocks/harvest/form.tsx
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@fdm-calculator/CHANGELOG.md`:
- Line 7: The CHANGELOG entry for PR `#495` is incorrect: it mentions "Fixes for
farm nitrogen balance to exclude nitrate leaching" while the PR implements
calendar-aware date handling for DatePicker, DatePicker-v2 and form components
using the calendar store; update the CHANGELOG entry to accurately summarize the
date/calendar changes (or, if this PR actually includes the nitrogen-balance
changes too, document both features), referencing the affected components
DatePicker, DatePicker-v2 and the calendar store so reviewers can verify the
described changes match the code in PR `#495`.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 4a73142f-517e-4363-86c8-f4facbb7ceda
📒 Files selected for processing (4)
fdm-app/CHANGELOG.mdfdm-app/package.jsonfdm-calculator/CHANGELOG.mdfdm-calculator/package.json
✅ Files skipped from review due to trivial changes (3)
- fdm-app/CHANGELOG.md
- fdm-app/package.json
- fdm-calculator/package.json
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
2 participants
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 by CodeRabbit
Release Notes
New Features
Improvements
Bug Fixes
Closes #494