Skip to content

refactor: datetime to ant [ENG-175]#7059

Merged
speaker-ender merged 3 commits intomainfrom
refactor/datetime-to-ant--ENG-175
Dec 11, 2025
Merged

refactor: datetime to ant [ENG-175]#7059
speaker-ender merged 3 commits intomainfrom
refactor/datetime-to-ant--ENG-175

Conversation

@speaker-ender
Copy link
Contributor

@speaker-ender speaker-ender commented Dec 3, 2025

Ticket ENG-175

Description Of Changes

Updates the Configure Monitor form to use the ant DatePicker input.
This also updates the form to use the ant Form component, useForm hook, and all of the other ant input components.

Code Changes

  • Refactors the ConfigureMonitorForm component to use the ant DatePicker input.

Steps to Confirm

  1. Visit the integrations screen
  2. Select a monitor and navigate to the Data Discovery tab
  3. Click the Add Monitor button
  4. Confirm that the new components have the correct styles and functions correctly
  5. Fill out the form successfully
  6. Click the Edit button next to your newly created monitor
  7. Confirm that you can still edit the monitor

Pre-Merge Checklist

  • Issue requirements met
  • All CI pipelines succeeded
  • CHANGELOG.md updated
    • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
    • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
    • Updates unreleased work already in Changelog, no new entry necessary
  • UX feedback:
    • All UX related changes have been reviewed by a designer
    • No UX review needed
  • Followup issues:
    • Followup issues created
    • No followup issues
  • Database migrations:
    • Ensure that your downrev is up to date with the latest revision on main
    • Ensure that your downgrade() migration is correct and works
      • If a downgrade migration is not possible for this change, please call this out in the PR description!
    • No migrations
  • Documentation:
    • Documentation complete, PR opened in fidesdocs
    • Documentation issue created in fidesdocs
    • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
    • No documentation updates required

@vercel
Copy link
Contributor

vercel bot commented Dec 3, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
fides-plus-nightly Ready Ready Preview Comment Dec 11, 2025 4:54pm
1 Skipped Deployment
Project Deployment Preview Comments Updated (UTC)
fides-privacy-center Ignored Ignored Dec 11, 2025 4:54pm

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Dec 3, 2025

Greptile Overview

Greptile Summary

This PR refactors the ConfigureMonitorForm component to migrate from the legacy Formik/Chakra form implementation to Ant Design's Form component and DatePicker.

Key changes:

  • Migrated from Formik to Ant Form with useForm hook and native Ant validation
  • Replaced CustomDateTimeInput with Ant DatePicker component
  • Updated date handling from date-fns to dayjs library
  • Replaced custom form components with Ant equivalents (Input, Select, Switch)
  • Updated Cypress test to match new datetime format output

Issues found:

  • Critical bug: dayjs(undefined) on line 188 creates an invalid date when creating a new monitor (when monitor?.execution_start_date is undefined)
  • Architectural inconsistency: mixing FormikSharedConfigSelect (a Formik component) within an Ant Form, creating mixed form management patterns

Confidence Score: 2/5

  • This PR has critical bugs that will cause issues when creating new monitors
  • Score reflects a critical logical error with date initialization that will break the form when creating new monitors (undefined date value), plus architectural inconsistency mixing Formik and Ant Form patterns
  • Pay close attention to ConfigureMonitorForm.tsx - the date initialization bug must be fixed before merging

Important Files Changed

File Analysis

Filename Score Overview
CHANGELOG.md 5/5 Added changelog entry for DatePicker migration - straightforward documentation update
clients/admin-ui/cypress/e2e/integration-management.cy.ts 5/5 Updated regex pattern to match new datetime format from Ant DatePicker
clients/admin-ui/src/features/integrations/configure-monitor/ConfigureMonitorForm.tsx 2/5 Refactored from Formik to Ant Form but has critical issues: invalid date initialization when creating new monitors, and mixing Formik components with Ant Form
clients/admin-ui/src/features/integrations/configure-monitor/ConfigureWebsiteMonitorForm.tsx 5/5 Exported constant for reuse - minimal, safe change

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4 files reviewed, 2 comments

Edit Code Review Agent Settings | Greptile

cy.getByTestId("input-execution_start_date")
.should("have.prop", "value")
.should("match", /2024-06-04T[0-9][0-9]:11/);
.should("match", /2024-06-04 [0-9][0-9]:[0-9][0-9]:11/);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Format change of internal value used by ant component.
This does not represent change in value submitted to api.
Changing the format prop would also change the value displayed to the user.

Comment on lines +178 to +188
useEffect(() => {
form
.validateFields({ validateOnly: true })
.then(() => setSubmittable(true))
.catch(() => setSubmittable(false));
}, [form, formValues]);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pattern used in ant documentation, however I think this could be improved in the future.

Copy link
Contributor

@lucanovera lucanovera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice update, thanks for updating the Form too!

@speaker-ender It looks like there's an issue where the date string isn't being loaded correctly when editing monitors created before this refactor.

Captura de pantalla 2025-12-04 a la(s) 2 14 31 p  m

I am comparing the preview branch with nightly, and I see that after the refactor we're using milliseconds, I would try to keep the strings the same for consistency and preventing bugs:
Preview branch after refactor: 2025-12-04T17:16:45.163000Z
Nightly: 2025-12-04T17:17:00Z

Reference:

@speaker-ender
Copy link
Contributor Author

@speaker-ender It looks like there's an issue where the date string isn't being loaded correctly when editing monitors created before this refactor.

I think this has to do with null values being returned. Fixed by resolving to undefined

I am comparing the preview branch with nightly, and I see that after the refactor we're using milliseconds, I would try to keep the strings the same for consistency and preventing bugs: Preview branch after refactor: 2025-12-04T17:16:45.163000Z Nightly: 2025-12-04T17:17:00Z

Good catch! This should now send the value without milliseconds

Copy link
Contributor

@lucanovera lucanovera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@speaker-ender Thanks for the updates! I no longer see the issue editing old monitors.
I found one more small issue though. After creating the monitor if I go to edit I see the date has moved back by 3 hours (I live in a UTC-3 timezone).
Creating:
Captura de pantalla 2025-12-11 a la(s) 1 07 39 p  m
Editing:
Captura de pantalla 2025-12-11 a la(s) 1 07 51 p  m

I did some initial debugging and I think the issue is that when the monitor is created the datetime is passed exactly as it was selected, but it really should be converted to UTC:
In this case I selected 13:08, it should save as 16:08 in utc.
Captura de pantalla 2025-12-11 a la(s) 1 11 27 p  m

The behavior on edit looks right to me, it's loading the utc value from the server and then applying the local timezone, so shifting it by 3 hours.

ps: sorry for the delay in my re-review. I missed you previous message.

chore: wip

chore: more wip

feat: nearly done

chore: fixes

fix: show time

chore: update changelog

fix: test id

fix: inline date format
@speaker-ender speaker-ender force-pushed the refactor/datetime-to-ant--ENG-175 branch from 87b2481 to 00c0ed7 Compare December 11, 2025 16:50
@speaker-ender
Copy link
Contributor Author

I did some initial debugging and I think the issue is that when the monitor is created the datetime is passed exactly as it was selected, but it really should be converted to UTC: In this case I selected 13:08, it should save as 16:08 in utc.
The behavior on edit looks right to me, it's loading the utc value from the server and then applying the local timezone, so shifting it by 3 hours.

@lucanovera Good catch! I think this should convert to utc correctly now.

Copy link
Contributor

@lucanovera lucanovera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks and works great now! Code changes look good, approved!

A small comment on date formats: While I prefer the standardized date format used here, usually we use 12hs because that's more natural for customer in the US.
But anyways that should be something that we configure at the fidesui level, not in the implementation.
Captura de pantalla 2025-12-11 a la(s) 2 27 14 p  m

Captura de pantalla 2025-12-11 a la(s) 2 23 57 p  m

@speaker-ender speaker-ender added this pull request to the merge queue Dec 11, 2025
Merged via the queue into main with commit 3bc11c8 Dec 11, 2025
47 checks passed
@speaker-ender speaker-ender deleted the refactor/datetime-to-ant--ENG-175 branch December 11, 2025 17:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants