Refactor date conversion functions and improve the documentation

[paulgain]

Description of change

This refactor removes four functions, adds another and improves the documentation.

Added functions:

• isoStringToDateParts

Removed functions:

• convertDateToFieldShortDateObject
• convertUnparsedDateToFieldShortDateObject
• convertDateToFieldDateObject
• convertUnparsedDateToFieldDateObject

Checklist

• Has the branch been rebased to main?
• Automated tests (Any of the following when applicable: Unit, Functional or End-to-End)
• Manual compatibility testing (Browsers: Chrome, Firefox, Edge, Safari)

[cypress]

data-hub-frontend    Run #58600

Run Properties:   Passed #58600  •  96f748e5cb: Reorder functions and exports

Project	data-hub-frontend
Branch Review	refactor/date-conversion
Run status	Passed #58600
Run duration	01m 38s
Commit	96f748e5cb: Reorder functions and exports
Committer	Paul Gain
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	0
Skipped	0
Passing	15
View all changes introduced in this branch ↗︎

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.57%. Comparing base (45d2f60) to head (96f748e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7459      +/-   ##
==========================================
+ Coverage   88.36%   88.57%   +0.21%     
==========================================
  Files        1161     1161              
  Lines       18016    17998      -18     
  Branches     5127     5118       -9     
==========================================
+ Hits        15919    15941      +22     
+ Misses       2097     2057      -40     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[paulgain]

I realise that the estimated win date only has month and year, but we don't need to differentiate between this and a full date. For example, when posting to an endpoint just month and year and a subsequent GET request the response has the day set to 1.

[DeanElliott96]

Looks good, just a question on the change in values when the date value is undefined.

[DeanElliott96]

These changes and others were returning null or an empty string previously when there was no date. Now isoStringToDateParts returns { year: '', month: '', day: '' }.

Is that expected and do these components expect and handle values like this?

[paulgain]

@DeanElliott96 good point, thanks for bringing this up.

Yes, this is the expected behaviour. The isoStringToDateParts function consistently returns an object with the structure: { year: '', month: '', day: '' } when no valid date is provided. This approach ensures a consistent interface for the components consuming it, such as the FieldDate component.

Most calls to isoStringToDateParts set the initial value of FieldDate to an object with empty strings, so it aligns with the component's expectations. All the relevant tests are passing, which suggests the components are handling this as intended.

That said, if any issues arise or there's a preference to handle missing dates as null, it's straightforward to update the function to return null instead of { year: '', month: '', day: '' } for invalid or missing inputs.

So we can go from this:

function isoStringToDateParts(isoString) {
  const emptyDateParts = { year: '', month: '', day: '' }

  if (!isoString) {
    return emptyDateParts
  }

  const date = parseISO(isoString)

  return isValid(date)
    ? {
        year: date.getFullYear(),
        month: date.getMonth() + 1,
        day: date.getDate(),
      }
    : emptyDateParts
}

To this:

function isoStringToDateParts(isoString) {
  if (!isoString) {
    return null 
  }

  const date = parseISO(isoString)

  return isValid(date)
    ? {
        year: date.getFullYear(),
        month: date.getMonth() + 1,
        day: date.getDate(),
      }
    : null
}

[paulgain]

@peterhudec it would be good to get your thoughts on this, Dean has raised a good point.

[DeanElliott96]

I think I would prefer what you have and then it's up to each component whether they want to handle undefined dates first themself (and return what they want as a default) or let the function handle it and handle the return of that function.

But for the existing components as long as they are working as expected then I don't see problems with its current implementation.