No endpoints.ts generated for @BrowserCallable to be used in ReactAdapterComponent/ReactAdapterElement

[sveinnetnordic]

Description of the bug

We have 120+ Flow views currently. Currently two as ReactAdapterElement. When developing React vaadin.frontend.hotdeploy=true

For Flow development vaadin.frontend.hotdeploy=false is default because restart/reload is much faster with dev.bundle.

No main/frontend/generated/endpoints.ts is created. Not even with vaadin:build-frontend

All routes is defined in Flow @route

Expected behavior

Endpoints should be generated

Minimal reproducible example

NA

Versions

Hilla: 24.5.0
Flow: 24.5.0
Vaadin: 24.5.0

[mshabarov]

While this is a bug and, moreover, a regression in 24.5 comparing to 24.4, I'm curious how have you noticed this bug? Have you moved your ReactAdapterElement extensions outside of src/main/frontend/views folder?

Because this issue #20290 basically prevents this to happen if you use standard views folder.

[sveinnetnordic]

I had just created a src/main/frontend/views/HelloReact.tsx to try copilot, and checked that in. At the same time a was working on ReactAdapterElement with @BrowserCallable use. The team reported slow Flow development because of #20290. When I removed the only file in views folder HelloReact.tsx, my ReactAdapterElement stopped working because of missing endpoints. ReactAdapterElement is not in the view folder: "All routes is defined in Flow @route"

[sveinnetnordic]

Just to be clear: I would like @BrowserCallable/@endpoint also without the views folder (routing/hilla). It is multiple ways to communicate with backend for ReactAdapterElement (hooks.useState, hooks.useCustomEvent,@ClientCallable, props/attributes). Some need manual serialization and/or manual interface creation.

I find @BrowserCallable/endpoints as the best way for @service operation. It is also reusable for other part of the code without any extra communication to the backend and wrappers to services.

[caalador]

BrowserCallable is a Hilla feature and having it generated outside of routing would probably need some changes on that side.
Flow has the ClientCallable annotation that opens up a method for calling from the client, but this again doesn't generate any endpoint script file.

[sveinnetnordic]

BrowserCallable is a Hilla feature and having it generated outside of routing would probably need some changes on that side. Flow has the ClientCallable annotation that opens up a method for calling from the client, but this again doesn't generate any endpoint script file.

Yes, it is many ways to communicate - but BrowserCallable is the one that generates interface and callbacks. For refactoring and easy use: @BrowserCallable is the one! I am curious of why it is bound to the routing? I have used @endpoint since it came in Fusion, never with any frontend routing. I am fan of ReactAdapterElement an will have routing backend for simplicity - as the default.

[mshabarov]

It's not a regression, my bad.
This is an enhancement, because we haven't taken this use case into account when designed ReactAdapter API.
In the same time, it's a valid and interesting use case.

The expected Vaadin's behaviour in this case should be, in my opinion, that the compilation of a new custom dev bundle (and custom prod bundle as well) starts once you add the BrowserCallable/Endpoint to your project and rerun. The custom dev bundle compilation then should trigger npm installation, including installing Hilla packages for endpoints generator.

All the Hilla dependencies are not needed in this case, but just what is needed for endpoints.
Also, I believe the bundle is better than hot-deploy in cases like yours because of reasons that you mentioned: Flow is a main part of application.

We have to investigate the effort and our priorities for this. Even if we aren't leaning towards this enhancement, we need to mention this case in our docs.

[sveinnetnordic]

I understand that there will be some challenges when Hilla and Flow are merged. I think that frontend modules should be fairly independent and consist of components, translations, endpoints, interfaces, and auto-routing. If Vaadin detects React code in frontend/views or within ReactAdapterComponent, a Node module for translation is installed. If @FrontendInterface is detected, a generator is installed, and for @BrowserCallable, an addition to @FrontendInterface is installed. If there are files in frontend/views, handling of frontend routing is installed.

I find the Kinder Surprise ReactAdapterComponent very useful. I am rewriting an application from React to Flow, with some components remaining in React. The routing will be handled by a thin ReactAdapterComponent, with the majority of the React code in the ReactAdapterElement.

In some cases, ReactAdapterElement can be thin, with most of the UI implemented in ReactAdapterComponent.

We have another React application that we might rewrite, where we may begin by setting up routing in frontend/views and using @BrowserCallable. Over time, we may rewrite it step-by-step to Flow, incorporating ReactAdapterComponent. The advantage is that I can make this decision along the way, as Vaadin can support all these hybrid situations.

[Legioth]

Since @BrowserCallable itself is most distinctively a Hilla feature, it would still be reasonable that Hilla itself needs to be explicitly "enabled" e.g. using the workaround of adding a dummy Hilla view. But it should still be possible to use Hilla even with vaadin.frontend.hotdeploy=false.

What's missing is probably "only" that the Hilla generator is not run when creating a new frontend bundle. We already have the code for running the generator when starting the Vite dev mode and for creating a production build so it would probably be a relatively simple change to also make sure it's run when creating a bundle.

[sveinnetnordic]

That would be very nice, and the only missing part for me now.

What about enabling Hilla if @BrowserCallable is found? I know about the magic trick adding a dummy view, but... .

[Legioth]

What about enabling Hilla if @BrowserCallable is found?

That could also be a good option as long as it can be done efficiently (which I suspect won't be a problem since those classes should already be picked up as Spring beans).

[mshabarov]

Related issue #18800

[tepi]

Related issue #18800

I would even say this is duplicate of the older issue

[tepi]

Reverted due to the changes causing test failures in Hilla. For now, the workaround of adding a dummy view should be used, and the issue will be revisited in the future.

[tepi]

When revisiting this issue, #20959 should be considered.