Use model generation only

Hi everyone,

currently I’m using a spring boot 3.1.x backend and a react 18.0.x frontend. We use a custom approach to generate typescript models using the output schema of our swagger.json.

I want to migrate to hilla react step by step, starting with the model generation. Is it possible to use the model generation process without using the rest of hilla?

Greetings,
Klemens

1 Like

Hilla will generate TypeScript files for whatever it detects is used in communications. The easiest way to get it to generate TS for selected types is to add a browser callable method that takes the type as a parameter. The method itself can have @DenyAll so nobody can actually call it but TS files will then be generated, e.g.

@BrowserCallable
@DenyAll
public class Dummy {
    public void dummy(SomeType a, AnotherType b) {

    }
}
1 Like

Hi @info.159,

I assume you already read Endpoint Generator | Reference | React | Hilla Docs? I think the last section could be interesting for you: Endpoint Generator | Reference | React | Hilla Docs.

Generating the TypeScript client and model can be executed as a separate action. If you use Gradle it would be gradlew hillaGenerate (see Using Gradle in Hilla applications for more details). If you use Maven the corresponding goal is probably mvn generate-sources?

Update: It should be mvn hilla:generate for Hilla 2.x and mvn vaadin:generate starting with Hilla 24.4.

1 Like

It depends what you mean by “rest of hilla” here.

But assuming that you mean by Vaadin’s Lumo Design System, i.e. our components, I would answer basically yes.

You can start by model generation. Then you have two ways to access the data. Your legacy views will use the your existing way and alongside that you have generated TypeScript facade to access the data.

Then you can refactor the views one by one to use generated data access facades and Vaadin’s Lumo Design System.

1 Like

Thanks a lot, nice input!

The generation works fine, but I encountered a problem.

My dependencies are in a special repository, which works fine fetching them thanks to my configured settings.xml. When i run my maven build, I pass the file using “-s path/to/settings.xml” argument. But once i use the production profile, it ignores my settings file entirely. Is this a known bug?

I know that my repositories in the settings file rely on a profile as well. I am aware of it and maven is capable of resolving all dependencies, even if i delete them in my local .m2 location it is able to fetch them, but as soon as it comes to the build-frontend goal of my plugin, it looks for the settings file in my default location and not the one specified with “-s”. How come?

I haven’t heard of anyone with that kind of setup before so I wouldn’t be surprised if there’s some condition that isn’t take care of in the Maven plugin. Please file a ticket at Issues · vaadin/hilla · GitHub.

It’s pretty common in enterprise applications to have your own dependencies not in public repositories. I’ll open a ticket. Thanks.