Page response type ignored

Happy Holidays!

Today I realized that Hilla is ignoring Page as response type.

@Nonnull
public Page<@Nonnull Person> list(String filter, Pageable pageable) {

generates

function _list(
 filter: string | undefined,
 pageable: Pageable | undefined,
 __init?: EndpointRequestInit
): Promise<Array<Person>>
{
 return client.call('PersonEndpoint', 'list', {filter, pageable}, __init);
}

Why is that? If I would like the result as Page I cannot do that and have to create my own result type

Hm. That’s odd. I recall using it at some point.

Does the new TS generator (hillaEngine feature flag) also have the same issue?

When turning on the new TS generator the project doesn’t even compile!

  ERROR(TypeScript)  Expression expected.
  FILE  C:/Users/simon/Workspace/hilla/hilla-master-detail-with-filter/frontend/generated/dev/hilla/runtime/transfertypes/OrderModel.ts:17:102
 
     15 |     }
     16 |     get property(): StringModel_1 {
> 17 |         return this[_getPropertyModel_1]("property", StringModel_1, [true, new NotBlank_1({ payload: , groups: , message: "{javax.validation.constraints.NotBlank.message}" })]) as StringModel_1;
        |                                                                                                      ^
     18 |     }
     19 | }
     20 | export default OrderModel;
 
  ERROR(TypeScript)  Expression expected.
  FILE  C:/Users/simon/Workspace/hilla/hilla-master-detail-with-filter/frontend/generated/dev/hilla/runtime/transfertypes/OrderModel.ts:17:112
 
     15 |     }
     16 |     get property(): StringModel_1 {
> 17 |         return this[_getPropertyModel_1]("property", StringModel_1, [true, new NotBlank_1({ payload: , groups: , message: "{javax.validation.constraints.NotBlank.message}" })]) as StringModel_1;
        |                                                                                                                ^
     18 |     }
     19 | }
     20 | export default OrderModel;
 
 [TypeScript] Found 2 errors. Watching for file changes.

You can try yourself with this project: https://github.com/simasch/hilla-master-detail-with-filter

Thanks, I’ll take a look

There is a bug in the generator which tries to parse the @NotBlank annotation and generates invalid code. I can file an issue unless you prefer to do that yourself.

I will do that. Thanks

@adaptable-uakari Can you post the github issue? I’m also interested in a solution since i stumbled across this problem some days ago.

Will do after I’m back from skiing :skier:

@adaptable-uakari Oh, i’m jealous :slightly_smiling_face: Have fun and don’t break a leg

What do you mean by this?

ignoring Page as response type

It sends the page content and makes it available as an array, assuming this is what you want most always

@winsome-wombat when i have Page as the response type i expect to get two things: all the elements for the requested page and the total count. Thats simply the reason i use Page instead of List

I could also use a Slice.

Which would be better because the count can be a performance issue

All the Iterables are treated like arrays in Hilla. Anyway, as the original type is carried out in the generated OpenApi, a custom plugin could remap things differently. But providing a custom return type is the easiest solution here, since tweaking the mappings would still create a mismatch with the data returned by the endpoint calls. A custom return type ensures consistency.
The bug about @NotBlank still stands and is a separate issue.

I don’t understand. Page and Slice are types with state other than the data. So IMO it must be translated by Hilla correctly like any other custom type.

A custom return type is just not clear and produces unnecessary code