Hello,
I created a small project that makes it easier to manage translations in Hilla React 24.4. (And also for Flow)
This uses Hilla endpoints for communication with the backend as well as some custom React Hooks.
Now I would like to turn this project into a library that we could integrate into our other projects.
I’ve seen some examples with Hilla multi-module projects. These showed how to reuse Hilla endpoints from other modules so I already have a good idea of how to do it for the Java part. On the other hand, I don’t know in which direction to go to be able to reuse the frontend code.
Create two libraries? One on a maven repo, the other with npm? If so, I need to decouple my frontend code from Hilla-generated endpoints and add boilerplate code in client projects to reconnect them.
If I package everything in my Java library, how do I access TypeScript files from my other projects?
Do I need to include the files generated by Hilla for endpoint use?
If anyone has an idea of the direction to follow… or better, an example project?
I think if you want other people to import your frontend code, you pretty much need to ship an NPM package. You can’t really import resources that are bundled in a JAR file in TS code.
You can make installation of both the Java module and NPM package a bit easier by adding a Java class that is annotated with @NpmPackage, and reference your NPM module there. That way Hilla should automatically install your NPM module when it detects the annotation. That’s how Hilla’s own modules used to work: hilla/packages/java/hilla-react/src/main/java/dev/hilla/HillaReactCrud.java at f466575fb2f3972ff5813a917ce31bff1699376a · vaadin/hilla · GitHub.
Then I think you don’t want to include generated TS (endpoints, data model) in your NPM package. If I remember correctly, Hilla does support multi module projects and as such will generate TS files for endpoints and models into an app when adding your library as a dependency. If you would also ship generated files in your NPM package the app would end up with duplicates, which could lead to confusion if users need to import one of those types somewhere.
Of course the challenge is then how to connect your React hooks with the endpoint that will only be generated once users add your library to their project. I guess you would still need to define some types in your NPM package that are compatible with what Hilla generates, so that users can pass their generated endpoint to your hooks.
1 Like
Apart from that we have started working on an I18n solution for Hilla. It is currently marked as experimental and requires enabling a feature flag, but people can try it out and give feedback. The basic idea is to reuse the Vaadin translations resource bundle that is also used by Vaadin Flow, and load translations for a specific language from there when the frontend app initializes or the language is changed.
Some links from the integration test project in the Hilla codebase:
Here is the implementation of the frontend module that shows what APIs are available: hilla/packages/ts/react-i18n/src/index.ts at main · vaadin/hilla · GitHub
1 Like
Thank you Sascha.
I have created two libraries. Thansk to the @NpmPackage annotation, we need to add the dependency only in Maven and Vaadin takes care of adding the necessary npm dependencies.
For the reconnection, I also did as you suggested. I created an interface matching the signature of the Endpoint generated by Hilla and then I simply added something like this in index.ts (I don’t know if there is a better way to initialize a service globally in Hilla) .
document.addEventListener('DOMContentLoaded', () => {
initializeTranslationService(HillaTranslateEndPoint);
});
I still need to set up a maven configuration to build and publish both libraries in a single command but it doesn’t seem too difficult to achieve.
I’ll take a look at your I18N solution for Hilla. In any case this approach can be reused for several projects with a similar configuration (We really like being able to mix Vaadin and Hilla!)