React: Server-fetched instant field remains string type

[hide212131]

Overview of the issue

Related to #23769 (comment)

export interface IEmployee {
  hireDate?: dayjs.Dayjs | null;
}

export const EmployeeUpdate = () => {
  const employeeEntity = useAppSelector<IEmployee>(state => state.employee.entity);

  // If we write this expecting hireDate to be a dayjs type, we get an error at runtime. 
  // This is because hireDate can be a **string** type.
  const year = employeeEntity.hireDate?.year(); 

With the model as dayjs type, the results retrieved from the REST API must be converted.

Motivation for or Use Case

While this doesn't directly cause an error, it can lead to confusion during frontend development.

Reproduce the error

Related issues

#23769

Suggest a Fix

#23769 (comment)

JHipster Version(s)

https://github.com/jhipster/generator-jhipster/tree/3c5e8327f8909923a2411aeb20dcd0cbc1e96cfc

• Checking this box is mandatory (this is just to show you read everything)

[qmonmert]

@hide212131 I did what you suggested but I have a warning in the console

and it seems that it is not a good practice
https://redux.js.org/style-guide/#do-not-put-non-serializable-values-in-state-or-actions
https://redux.js.org/faq/organizing-state#can-i-put-functions-promises-or-other-non-serializable-items-in-my-store-state

cc @DanielFran

[hide212131]

@qmonmert (cc @DanielFran) You're absolutely right, and I apologize for overlooking that.
I've also gone through this discussion. Given that we are using React + Redux-toolkit, it's recommended that our models are Serializable/Immutable. Unfortunately (as it is less usable than Angular or Vue), this means it would be better to revert to using the string type, specifically in the ISO 8601 format.

Additionally, if we decide to use the string type, we will need to change the role of src/main/webapp/app/shared/util/date-utils.ts.

From:

export const convertDateTimeToServer = (date?: string): dayjs.Dayjs | null => (date ? dayjs(date) : null);

To:

// React components deal with local time, so it's necessary to convert them to UTC.
export const convertLocalToUTC = (date?: string): string | null => (date ? dayjs(date).toISOString() : null);

The same applies to convertDateTimeFromServer.

Could you please provide your thoughts on whether this approach is appropriate? There's also the option of overriding the isSerializable option in the serialization check middleware.

[github-actions]

This issue is stale because it has been open for too long without any activity.
Due to the moving nature of jhipster generated application, bugs can become invalid.
If this issue still applies please comment otherwise it will be closed in 7 days