Docs

Docs

Configuration

Customizing a Hilla application configuration for both the development environment and for execution.

Configure the TypeScript Generator

To allow the TypeScript generator to use the correct parameter names when building TypeScript files, you need to configure the Java compiler not to omit them by using the javac -parameters option. For example, the following shows how to configure the Maven plugin to include this compiler option:

Source code
pom.xml
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.10.1</version>
            <configuration>
                <encoding>UTF-8</encoding>
                <parameters>true</parameters>
            </configuration>
        </plugin>
    </plugins>
</build>

Multi-Module Projects or External Dependency Services

Hilla searches for browser-callable services among the Spring beans that are available in the application. Services therefore don’t have to be in the application’s own package: those in another module of your project, or in a dependency such as the SSO Kit, are found as well, as long as Spring instantiates them as beans.

Note
Services & Spring Dependencies
If services outside the main application package aren’t picked up, make sure that Spring finds them: either component scanning reaches their packages, or a configuration class declares them as beans.

The discovery needs the Spring Boot application class on the module’s classpath. When that class is in another module, configure the discovery explicitly, as described in Explicit Discovery of Browser-Callable Classes.

Explicit Discovery of Browser-Callable Classes

During code generation, Hilla discovers browser-callable classes — classes annotated with @BrowserCallable or @Endpoint — automatically. The discovery relies on detecting the Spring Boot application class on the module’s classpath. In some setups, such as multi-module projects where the application class resides in a different module, this auto-detection fails.

In these cases, you can configure the discovery explicitly with the mainClass and sourceClasses plugin parameters. They are available on the prepare-frontend, build-frontend, and generate goals of the Hilla Maven plugin:

mainClass

The fully qualified name of the Spring Boot application class to use for discovering browser-callable classes.

sourceClasses

A list of fully qualified names of Spring configuration classes that declare the browser-callable beans. The classes are passed to the Spring AOT processor as --spring.main.sources, and are used when no Spring Boot application class is found on the classpath.

For example, to set the application class explicitly:

Source code
XML
<plugin>
    <groupId>com.vaadin.hilla</groupId>
    <artifactId>hilla-maven-plugin</artifactId>
    <version>${hilla.version}</version>
    <configuration>
        <mainClass>com.example.application.Application</mainClass>
    </configuration>
</plugin>

Alternatively, if there is no Spring Boot application class available, list the Spring configuration classes that declare the browser-callable beans:

Source code
XML
<plugin>
    <groupId>com.vaadin.hilla</groupId>
    <artifactId>hilla-maven-plugin</artifactId>
    <version>${hilla.version}</version>
    <configuration>
        <sourceClasses>
            <sourceClass>com.example.application.ApplicationConfiguration</sourceClass>
            <sourceClass>com.example.module.ModuleConfiguration</sourceClass>
        </sourceClasses>
    </configuration>
</plugin>
Note
 When either mainClass or sourceClasses is set, Hilla discovers browser-callable classes with the Spring AOT-based finder, and skips the default lookup-based auto-detection.

TypeScript Compiler Options

The TypeScript compiler requires a tsconfig.json file. If there is no tsconfig.json in the project root, the vaadin-maven-plugin generates one.

The default configuration looks similar to the following:

Source code
tsconfig.json
{
  "compilerOptions": {
    "sourceMap": true,
    "inlineSources": true,
    "module": "esNext",
    "target": "es2017",
    "moduleResolution": "node",
    "strict": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "experimentalDecorators": true,
    "baseUrl": "frontend",
    "paths": {
      "Frontend/*": [
        "*"
      ]
    }
  },
  "include": [
    "frontend/**/*.ts",
    "frontend/index.js",
    "types.d.ts"
  ],
  "exclude": []
}

Core & Pro Vaadin React Components

Vaadin React components include free core components and Pro (commercial) components. They’re shipped in separate npm packages: @vaadin/react-components, which contains only free components; and @vaadin/react-components-pro, which contains only commercial components. Vaadin adds both of these packages to package.json if the com.vaadin:vaadin artifact is used in the Java project configuration. By default, this is done in the Maven pom.xml.

Source code
pom.xml
<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin</artifactId>
</dependency>

If the com.vaadin:vaadin-core dependency is used, only the free @vaadin/react-components package is added:

Source code
pom.xml
<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin-core</artifactId>
</dependency>

Updated –