OffsetDateTime support for the EndpointGenerator

Hilla
1

Documentation about how to change the behaviour of Endpoint Generator is basically nonexistent.

The documentation states

Designed to be flexible: all parts of the generator are pluggable, which allows you to alter the default behavior or add a new one.
Source: Endpoint Generator | Reference | React | Hilla Docs

I am using OffsetDateTime in a spring data projection and also have openapi generation running via springdoc-openapi. This api doc maps OffsetDateTime and also duration correctly:


"timestamp": {
  "type": "string",
  "format": "date-time"
}
"duration": {
  "type": "object",
  "properties": {
    "seconds": {
      "type": "integer",
      "format": "int64"
    },
    "zero": {
      "type": "boolean"
    },
    "nano": {
      "type": "integer",
      "format": "int32"
    },
    "negative": {
      "type": "boolean"
    },
    "positive": {
      "type": "boolean"
    },
    "units": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "durationEstimated": {
            "type": "boolean"
          },
          "timeBased": {
            "type": "boolean"
          },
          "dateBased": {
            "type": "boolean"
          }
        }
      }
    }
  }
}

But Hilla based its endpoint generation on this openapi json

"timestamp" : {
  "type" : "object",
  "x-java-type" : "java.time.OffsetDateTime"
},
"duration" : {
  "type" : "object",
  "x-java-type" : "java.time.Duration"
},

As far as I can tell the culprit is this code in ClassInfoModel.java

 private static final Class<?>[] DATE_TIME_CLASSES = { LocalDateTime.class,
            Instant.class, LocalTime.class };

But in an hour of searching I was not able to find how to change this “flexible” but very very lackingly documented architecture.

Can anyone here help me with this?

2

You mean the docs documented on the same page you linked? Endpoint Generator | Reference | React | Hilla Docs

3

Yes I mean that documentation
However, it is unfortunate that ClassInfoModel is not part of any plugin but part of the parser core so it is not clear to me how to change its behaviour when changes are restricted to plugins.

How a plugin interfaces with the generator is also not documented to my knowledge.
I would greatly appreciate any help here.

4

Let me break this one into pieces.

First of all, I think that the Offset* date types should be supported by the Hilla core just as the Local* types are. You shouldn’t need a plugin for that and I’m going to open an issue citing this thread. But let me know if you want to open the issue yourself. By the way, we already have two old issues (#234 and #235) that concern OffsetDateTime support.

In the meanwhile, given that all dates are transferred as strings in Hilla, as a workaround you can do the conversion yourself in a DTO while waiting for the support to be added at core level.

5

Concerning the documentation about writing plugins, they are supposed to work in sequence, so the idea is that you don’t change the core support, but rather customize the parsing process, like existing plugin do. For example, the TransferTypesPlugin replaces some classes with others, and you could do something similar in your plugin and replace OffsetDateTime with String in a similar plugin, for example.

1 Like
6

Thank you
Feel free to create an issue and maybe tag me in it (@deniz-frick)

I “solved” this in the meantime by just ignoring the ts types and parsing the string with type “unknown” as a date manually.

7

OK I created #2390, feel free to upvote and comment.