Soroosh Taefi

> I suspect `isReactEnabled()` is wrongly named. It should actually be `isLitDisabled()` instead. > > I wonder if the logic should be such that if `@vaadin/react-components` is present in `package.json`,...

@rbrki07 it is great that you're interested in working on this! :ok_hand: Some considerations I can think of from the top of my mind: * Apart from the use cases...

The following issue is going to make the path clear for doing the fetch: https://github.com/vaadin/hilla/issues/1731

I believe the views with optional parameters should have chance of appearing in the menu. Maybe, the `createMenuItems` can include them and let the users filter them out on demand?

> I followed your recommendation @taefi and made the suggested change. Unfortunately, my knowledge about the Hilla project-, build- and test-setup is not sufficient, which means, that I don't know...

The `AvailableViewInfo` from Hilla is replaced with `com.vaadin.flow.server.menu.AvailableViewInfo` so we probably need to register that instead. Also, instead of `ClientViewMenuConfig` we should register `com.vaadin.flow.router.MenuData`.

> Have we changed how endpoints are being called? I don't recall any change in that zone. The stacktrace points to [this](https://github.com/vaadin/hilla/blob/main/packages/java/endpoint/src/main/java/com/vaadin/hilla/EndpointInvoker.java#L439) method invocation that uses the reflection API, but...

Well, looking at the above code, it tries to read the open api json from `/hilla-openapi.json` which means the root of `target/classes`, and while reading it from this location works...

It seems that the `-` in the file name of `hilla-openapi.json` was somehow making it inaccessible to the class/resource loader at the time of native build, even though, it is...

Nope :( It is happening again (though I had a successful native build earlier):  I suspected that timing might be the issue, for instance...