docs: move type conversion and code generation to Flow by peholmst · Pull Request #6620 · vaadin/docs

peholmst · 2026-11-10T18:14:03Z

Review risk: two-way door. Docs only: three new pages, five removed pages with redirects, and link updates. Reverting brings the old pages back.

Summary

Moves type conversion, type nullability and code generation from the Hilla reference to the browser-callable services section of the Flow Reference (articles/flow/react-views/browser-callable-services/). This is the fourth step of dissolving the Hilla section, after #6611, #6616 and #6618. Form binding follows in the next pull request.

The pages are rewritten rather than moved: the old ones described Jackson 2, the OpenAPI-based generator and plugin setups that are no longer accurate. Every statement is checked against main of vaadin/hilla and vaadin/flow. The behavior was confirmed in a scratch 25.4.0-alpha5 application, and every example on the new pages was generated or type-checked there. This pull request targets main only, so it gets no target/v25.3 label.

What changed

New pages:
- type-conversion.adoc: the Java-to-TypeScript type mapping, null and undefined, numbers, dates and times, enums, objects and Jackson annotations, single-value and polymorphic types, and customizing the object mapper.
- type-nullability.adoc: the defaults, @NullMarked packages, the recognized annotations, and what the server checks at runtime.
- code-generation.adoc: when the code is generated, the generated files, how the services are found, explicit discovery (keeps the #endpoint-discovery anchor), and parameter names (keeps #java-compiler-options).
Corrections compared with the old pages, each confirmed in the scratch application:
- Jackson 3 rejects int and long arguments that are out of range. The old page said they roll over.
- Unknown properties are ignored. OffsetDateTime and ZonedDateTime arguments arrive in UTC. BigDecimal and BigInteger lose precision in the browser. Java NaN and infinity arrive as strings. The date formats are those of 25.4.
- The object mapper is customized with a JacksonObjectMapperFactory bean with the endpointMapperFactory qualifier, and the spring.jackson properties don't affect it. The generator doesn't use the custom mapper, so the page warns that changing the properties breaks the generated types. The old page named a bean qualifier that doesn't exist.
- The generator honors @NullMarked only on packages, not on classes or sub-packages. JPA @Id and @Version fields stay nullable. The server checks return values, but not arguments. The Spring and Hilla nullability annotations are deprecated, so the page leads with JSpecify.
- Explicit discovery is configured on vaadin-maven-plugin (its build-frontend and generate goals) and with project properties of the com.vaadin Gradle plugin, not on hilla-maven-plugin. It applies only to builds, not to development mode.
- -parameters isn't required: without it, the generated parameters are called arg0, arg1, and so on.
- In development mode and in production builds, generation runs only in projects that use React views. The generate goal and the hillaGenerate task don't check for them. No OpenAPI document is produced any longer, so the OpenAPI appendix and the architecture section are gone, along with the tsconfig.json dump and the list of core and Pro packages.
Removed pages, each with a redirect:
- hilla/reference/type-conversion → browser-callable-services/type-conversion
- hilla/reference/type-nullability → browser-callable-services/type-nullability
- hilla/reference/configuration and hilla/reference/typescript-generator → browser-callable-services/code-generation
- hilla/reference/gradle → flow/configuration/gradle. That page now lists hillaGenerate, and the Maven page lists the generate goal, both with a link to Code Generation.
Six existing redirects that led to these pages (endpoint-generator and the Lit ones) now point straight at the new pages.
Links: updates the links in Call Java Services, Domain Primitives, the upgrading guide, the FAQ and the browser-callable services page. The nullability tip in Call Java Services now recommends @NullMarked instead of the deprecated @NonNullApi.

Test summary

npm run check-redirects passes.
Every cross reference in the new and changed lines resolves to an existing page and anchor.
Vale: no errors or warnings on the added and changed lines.
Asciidoctor renders the new pages without errors.
The examples were generated by the 25.4.0-alpha5 generator in a scratch application, which produced the TypeScript shown on the pages. The ShapeUnion snippet type-checks against the generated code.
The Gradle behavior is checked against the plugin source and the published com.vaadin plugin jar, not by running a Gradle build. The Kotlin nullability support is checked against the source only.
No Java or TypeScript examples changed. I didn't run a full dspublisher build locally.

Three Hilla behaviors came up during testing:

The runtime null check rejects a null item even when the item type is @Nullable (Runtime null check rejects null items of a @Nullable item type hilla#7029). The nullability page describes this as it is.
@NullMarked is read only on packages (Support JSpecify @NullMarked and @NullUnmarked on modules, classes, methods and constructors hilla#6631, already open). The nullability page says so.
An invalid UUID argument fails with a plain 500 instead of an EndpointValidationError (Invalid UUID argument fails with a 500 instead of an EndpointValidationError hilla#7030). The pages don't mention it.

🤖 Generated with Claude Code

Rewrite the Hilla type conversion, type nullability, configuration, TypeScript generator and Gradle reference pages as three pages under flow/react-views/browser-callable-services: Type Conversion, Type Nullability and Code Generation. The old pages described Jackson 2, the OpenAPI-based generator and plugin setups that no longer apply. Every statement is checked against vaadin/hilla and vaadin/flow main and in a 25.4.0-alpha5 application. Add redirects for the removed pages, point the existing redirects that led to them at the new pages, list the generate goal and the hillaGenerate task on the Flow Maven and Gradle pages, and update the links. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

vaadin-review-bot

Reviewed the changes — left 2 comments.

	Finding
⚠️	The rule that code is generated "only in a project that has React views in `src/main/frontend/views`" is narrower than the source and conflicts with the On request entries on the same page.
🧩	The object mapper example has no imports, and the page doesn't say which packages the classes come from.

The generate goal and the hillaGenerate task generate the code without checking for React views, and the check in development mode and builds also accepts routes declared in index.ts or routes.tsx. Move the condition to the section about when the code is generated and state it for development mode and builds only. Add the imports to the object mapper example, since the Jackson 3 classes are in tools.jackson, not com.fasterxml.jackson. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

github-actions · 2026-11-10T18:47:08Z

Preview Deployment

This PR has been deployed for preview.

URL: https://docs-preview-pr-6620.fly.dev

Changed pages

Added content is highlighted in green; removed content is marked in red on each page.

building-apps/forms-data/consistency/domain-primitives — modified, +1/-1 lines, 1 removal marker(s)
building-apps/react/call-services — modified, +2/-2 lines, 2 removal marker(s)
flow/configuration/gradle — modified, +3/-0 lines
flow/configuration/maven — modified, +3/-0 lines
flow/react-views/browser-callable-services — modified, +2/-2 lines, 2 removal marker(s)
flow/react-views/browser-callable-services/code-generation — added, +136/-0 lines
flow/react-views/browser-callable-services/type-conversion — added, +329/-0 lines
flow/react-views/browser-callable-services/type-nullability — added, +134/-0 lines
hilla/faq — modified, +1/-1 lines, 1 removal marker(s)
upgrading — modified, +1/-1 lines, 1 removal marker(s)

Other changed files

articles/hilla/reference/configuration.adoc (deleted)
articles/hilla/reference/gradle.adoc (deleted)
articles/hilla/reference/type-conversion.adoc (deleted)
articles/hilla/reference/type-nullability.adoc (deleted)
articles/hilla/reference/typescript-generator.adoc (deleted)

Built from 6c8e211

**Review risk:** two-way door. Docs and examples only: six new pages, nine removed pages with redirects, new and rewritten form examples, and link updates. Reverting brings the old pages back. ## Summary Moves the React form binding reference from the Hilla section to the React Views section of the Flow Reference (`articles/flow/react-views/forms/`). This is the fifth step of dissolving the Hilla section, after #6611, #6616, #6618 and #6620. Security follows in the next pull request. The pages are rewritten for 25.4, where the generated form models are `@vaadin/hilla-models` builder constants (vaadin/hilla#6249) and the model classes are gone (vaadin/hilla#6635). The old pages showed `AbstractModel`, `ObjectModel` subclasses and `createEmptyValue()`, which no longer exist. Every statement is checked against `main` of vaadin/hilla, and every example ran in a scratch 25.4.0-alpha5 application with the models that the generator wrote for the example classes. This pull request targets `main` only, so it gets no `target/v25.3` label. ## What changed - **New pages** in `flow/react-views/forms/`: - `index.adoc`: form models, binding fields, loading a value, submitting, and server-side validation. - `validation.adoc`: the constraints that the browser checks, required fields, error messages, field and form validators, and errors that a service reports. - `form-state.adoc`: the state properties, and changing values from code. - `nested-objects-arrays.adoc`: nested objects with `useFormPart()`, and lists with `useFormArrayPart()`. - `field-components.adoc`: which Vaadin components `field()` binds, and the Java types they edit. - `api.adoc`: the hooks, their results, the validation types, and `$defaultValue`. - **Examples:** new compiled examples in `fusion/forms/person` (a person with an address and phone numbers) and `fusion/forms/signup` (field, form and server validators). The company office example now sets the city with `setValue()` of its part, instead of changing `form.value` directly, which the form doesn't notice. Its package uses `@NullMarked` instead of the deprecated `@NonNullApi`. The unused `Contact` example and the Lit-era GIFs are removed. - **Corrections** compared with the old pages, each confirmed in the scratch application: - `submit()` rejects with a `ValidationError` when the validation fails, so `onClick={submit}` gives an unhandled rejection. The examples catch it. - After a submit, the submitted value becomes the default value, even when the server rejects it, so the form is no longer dirty. - The browser checks only some constraints. `@PastOrPresent`, `@FutureOrPresent` and custom constraints are checked only on the server, and their errors appear after a submit. - Validators don't run on an empty field that isn't required. A message's `{min}` placeholders are shown literally unless `BinderRoot.interpolateMessageCallback` is set. - Server errors land on the field whose path matches. Errors on method parameters, and errors that match no field, are only in the `ValidationError`. - `List Box` can't be bound: `field()` throws. `Switch` doesn't update the form value. The old page listed List Box as supported. - `useFormArrayPart()` needs a non-nullable list, and new items come from `ItemModel[$defaultValue]`. - **Removed pages, each with a redirect:** the nine `hilla/guides/forms` pages go to the matching new pages. `binder` and `binder-load` both go to the forms index. `form-images` goes to the current uploads page, which pull request 9 replaces. The ten Lit redirects that led to these pages now point straight at the new pages. - **Links:** updates the links in Add a View, Add a Form, Validation, Domain Primitives, the Auto Form page, the date and time picker pages, the shared input field partial, Component Events, Code Generation, and the browser-callable services page. The Domain Primitives link pointed to an anchor that didn't exist. ## Test summary - `npm run check-redirects` passes. - `mvn spotless:apply` and `mvn compile` pass. `npm run lint` passes on the new and changed examples. - The examples ran in a scratch 25.4.0-alpha5 application, which type-checked them against the generated models. The binding of each component in the Field Components table was checked there, loading and editing values. - Every cross reference in the new and changed lines resolves to an existing page and anchor. - Vale: no errors or warnings on the added and changed lines. - Asciidoctor renders the new pages, with all includes and tags resolved. - I didn't run a full dspublisher build locally. Three Hilla behaviors came up during testing, and the pages describe them as they are: - `field()` doesn't read the state of a `Switch`, because there's no field strategy for `vaadin-switch` (vaadin/hilla#7043). - `useFormArrayPart()` doesn't accept the model of a nullable list (vaadin/hilla#7044). - `field()` rejects `List Box`, although lit-form has a strategy for it (vaadin/hilla#7045). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

**Review risk:** two-way door. Docs and examples only: five new reference pages, ten removed pages with redirects, merges into three Flow security pages, and link updates. Reverting brings the old pages back. ## Summary Moves the security reference for React views from the Hilla section to the Flow security reference. The new pages are under `articles/flow/security/react-views/`, including stateless authentication. This is the sixth step of dissolving the Hilla section, after #6611, #6616, #6618, #6620 and #6621. Full-stack signals follow in the next pull request. The new pages are reference only: what the access rules are, how Vaadin checks them, and what the APIs do. They link to other reference pages. The step-by-step setup stays in Building Apps > Secure React Views, which now links to the reference instead of the reference linking to it. Every statement is checked against `main` of vaadin/flow and vaadin/hilla. The behavior is also checked in a scratch 25.4.0-alpha5 application with Spring Security, using curl and a browser. This pull request targets `main` only, so it gets no `target/v25.3` label. ## What changed - **New pages** in `flow/security/react-views/`: - `index.adoc`: the security model, the default access of services, React views and Flow views, what `VaadinSecurityConfigurer` does for React views and services, and data kept in the browser. - `service-access-control.adoc`: the access annotations and their precedence, role checks, `401` versus `403`, the current user, auditing denied calls, and CSRF. - `authentication.adoc`: the React login view, the user information method, `configureAuth()`, `useAuth()`, `login()` and `logout()`, and expired sessions. - `view-access-control.adoc`: the three places where `loginRequired` and `rolesAllowed` are checked (the router, the menu, page loads), role names, `hasAccess()`, `protectRoutes()`, and Flow and React views together. - **Moved page:** `flow/security/react-views/stateless-authentication.adoc`, rewritten as a reference for `VaadinStatelessSecurityConfigurer`, its cookies, and the contents of the token. It states that stateless authentication is intended for React views only, and that its behavior with Flow views is undefined. - **Merges:** - `spring/security-configuration.adoc`: the static `getDefaultHttpSecurityPermitMatcher()` and `getDefaultWebSecurityIgnoreMatcher()` matchers. - `protections/vulnerabilities.adoc`: the double-submit cookie check that services use without Spring Security's CSRF protection, and its relation to `disable-xsrf-protection`. - **Examples:** the user information service now allows anonymous calls and returns `null` when nobody is logged in, using `AuthenticationContext`. Its record has a `roles` property, which `configureAuth()` reads by default. A new `ProjectService` shows the access annotations. The login view, the session-expiration overlay and the connect client are rewritten. The examples that only the removed pages used are deleted. - **Corrections and additions** compared with the old pages, each confirmed in the scratch application: - A service without annotations is denied to everyone. Controlling Service Access and Best Practices also said that it needs only a logged-in user. - The session-expiration example said that the failed call continues after the login. It doesn't: `login()` returns no `token`, so `InvalidSessionMiddleware` doesn't send the call again, and `login()` reloads the page at `/`. The new example reloads the current page. A user information method that allows only logged-in users also opened the overlay for every visitor who isn't logged in. - After a session expires, calls to anonymous methods fail with `401` as well, because the CSRF token belonged to the old session. - When Spring Security has already rejected an anonymous call, no `EndpointInvocation` event is published. Spring Security publishes its own event, with the request as its object. The Auditing section said that the anonymous user arrives in the `EndpointInvocation` event. - The old role example used `rolesAllowed: ['ROLE_USER']` with roles that never contained that name. - The old pages showed the removed `useRouteMetadata`, the deprecated `requiresLogin`, and `VaadinRequest.getCurrent().getUserPrincipal()`. - **Removed pages, each with a redirect:** the ten `hilla/guides/security` pages. Offline authentication, which was built on Lit-era APIs, and the best-practices, introduction and vulnerabilities pages go to the matching Flow pages. The nine Lit redirects that led to these pages now point straight at the new pages. - **Links:** Routing, Browser-Callable Services, Client and Security Configuration now link to the new reference pages instead of the Building Apps guide. Secure React Views links to the reference. The full-stack signals page linked to the removed introduction. ## Test summary - `npm run check-redirects` passes. - `mvn spotless:apply` and `mvn compile` pass. `npx eslint frontend/demo/auth` passes. - The frontend examples type-check in the scratch 25.4.0-alpha5 application against the generated services. The login view and the session-expiration overlay ran there. - Checked with curl and in the browser in the scratch application: - service calls as an anonymous user, a user, and an administrator; - page loads, client-side navigation and menus; - expired sessions; - audit events; - stateless authentication across a server restart; - the double-submit cookie without Spring Security. - Every cross reference in the new and changed lines resolves to an existing page and anchor. - Vale: no errors or warnings on the added and changed lines. - Asciidoctor renders the new and changed pages, with all includes and tags resolved. - I didn't run a full dspublisher build locally. Stateless authentication is documented as intended for applications whose views are all React views, with undefined behavior for Flow views. Flow views keep their UI state in the HTTP session in any case. Behaviors that came up during testing, which the pages describe as they are: - On a page load of a React view with `loginRequired: true`, Spring Security compares `rolesAllowed` with the granted authorities exactly. The menu and the browser compare differently. `rolesAllowed: ['ADMIN']` therefore answers `403` to an administrator who reloads the page. View Access Control documents the three comparisons, and recommends writing the full authority names, such as `ROLE_ADMIN` (vaadin/flow#26962). - `InvalidSessionMiddleware` retries a call only when the `LoginResult` has a `token`, which `login()` never returns (vaadin/hilla#7048). Not changed here: the role example in Building Apps > Secure React Views hits the `403` above on reload, and its `getRoles` code doesn't type-check. That guide gets a separate pull request. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

**Review risk:** two-way door. Docs and examples only: one new reference page, one removed page with a redirect, a new section on Shared Signals, and link updates. Reverting brings the old page back. ## Summary Moves full-stack signals from the Hilla guides to the Flow UI State section, as the new page Shared Signals in React Views (`flow/ui-state/full-stack-signals`). This is the seventh step of dissolving the Hilla section, after #6611, #6616, #6618, #6620, #6621 and #6622. The page is a reference: which shared signal types a service can return, the client API of the signals, how they connect and synchronize, and how the access annotations apply. It's rewritten for 25.4, because most of the old page described an API that no longer exists. Every statement is checked against `main` of vaadin/hilla and vaadin/flow, and the behavior is checked in a scratch 25.4.0-alpha5 application with two browser tabs. This pull request targets `main` only, so it gets no `target/v25.3` label. ## What changed - **New page** `flow/ui-state/full-stack-signals.adoc`, marked as a preview feature behind the `fullstackSignals` feature flag: - the supported types (`SharedValueSignal`, `SharedNumberSignal`, `SharedListSignal`) and their TypeScript counterparts; - returning one instance from the service, and service methods with parameters; - creating, connecting and reading the signals in a view, and default values; - the members of `ValueSignal`, `NumberSignal` and `ListSignal`, and operation results; - changes made on the server; - access control. - **Shared Signals:** a new Validating Changes section for `withValidator()` and `CommandValidator`, which the Flow page didn't cover. The UI State index links to the new page. - **Feature Flags:** `fullstackSignals` moves to the list of experimental flags, and the Hilla Feature Flags heading goes away. - **Examples:** a compiled `MeetingService` and a view that uses a value, number and list signal, replacing the inline examples. - **Removed page, with a redirect:** `hilla/guides/full-stack-signals` → `flow/ui-state/full-stack-signals`. - **Links:** Type Conversion now links to the new page. - **Corrections** compared with the old page, each checked in the scratch application: - `ValueSignal` has no `replace()` or `update()` anymore (vaadin/hilla#3500), and `ListSignal` has `insertFirst()` as well. - The operation-validator API (`withOperationValidator`, `ValidationResult`, `IncrementOperation`, …) no longer exists. Flow's shared signals use `withValidator(CommandValidator)`, which is now on the Shared Signals page. - `new SharedValueSignal<>(false, Boolean.class)` doesn't compile. The constructors take an initial value, a type, or both as a `TypeReference`. - The list example used the index as the React `key`. Each item signal has a stable `id`. - `SharedMapSignal` and `SharedNodeSignal` aren't supported. The generator produces a plain method for them. ## Test summary - `npm run check-redirects` passes. - `mvn spotless:apply` and `mvn compile` pass. `npx eslint frontend/demo/fusion/signals` passes. - The example service and view type-check in the scratch 25.4.0-alpha5 application. Two tabs share the topic, the votes, and the agenda items: adding, checking and removing items all sync. - Checked with the browser and the generated client: - the generated types and default values; - write before read; - access denied on connecting and on changing; - `result` and `error` of a failed change; - a server-side change, which the connected browsers don't get and a new connection does (vaadin/hilla#5722); - assigning the value of a list signal. - `withValidator()`, chained validators, child signals, transactions and `asReadonly()` checked with a small program against the 25.4.0-alpha5 classpath. - Every cross reference in the new and changed lines resolves. - Vale: no errors or warnings on the added and changed lines with the pull request configuration. - Asciidoctor renders the new and changed pages, with all includes and tags resolved. - I didn't run a full dspublisher build locally. Behaviors that came up during testing, which the page describes as they are: - Changes that server-side code makes to a shared signal don't reach the connected browsers, only new connections (vaadin/hilla#5722). - When a change fails, its `result` promise doesn't settle; the signal's `error` holds the error. Related to vaadin/hilla#3967. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

**Review risk:** two-way door. Docs and examples only: one new page, two rewritten or extended pages, five removed pages with redirects, and link and guideline updates. Reverting brings the old pages back. ## Summary Moves React i18n, the connection indicator and React styling from the Hilla section to the Flow Reference and the Styling section. This is the eighth step of dissolving the Hilla section, after #6611, #6616, #6618, #6620, #6621, #6622 and #6624. Every statement is checked against `main` of vaadin/hilla and vaadin/flow, and the behavior is checked in a scratch application on 25.4.0-alpha5 with Flow 25.4.0-alpha6, the first Flow release with vaadin/flow#26714. This pull request targets `main` only, so it gets no `target/v25.3` label. ## What changed - **New page** `flow/i18n/react-views.adoc`, Localization in React Views, rewritten from the Hilla i18n guide with compiled examples: - loading translations with `i18n.configure()`, and how the initial language is chosen; - `translate()` and the `key` tag, the missing-translation marker, and ICU parameters compared with Flow's `MessageFormat`; - translating view titles and menu items with `translateDynamic()`, including the `@Menu` titles of Flow views; - changing the language, the file fallback, and that the React language is separate from the Flow `UI` locale; - development and production loading, and what a custom `I18NProvider` must implement. - **Loading and Connection Indicator** (`flow/advanced/loading-indicator.adoc`) now also covers what the Hilla connection indicator page covered: - it covers Flow and React views, the loading bar stages, and the connection status messages; - configuration from Java, including `ReconnectDialogConfiguration`, which no page documented, with a compiled example; - configuration from TypeScript, with the `jar-resources` import that replaces `@vaadin/common-frontend` after vaadin/flow#26714; - styling, with the element structure and states. - **Stylesheets:** a new Stylesheets in React Views section: global `@StyleSheet` styles, importing CSS files and CSS modules from a view, and the type declarations these imports need. - **Localization and Custom I18N Provider** link to the new page. - **Removed pages, with redirects:** - `hilla/guides/i18n` → `flow/i18n/react-views` - `hilla/reference/connection-indicator` → `flow/advanced/loading-indicator` (the Lit redirect points there too) - `hilla/guides/styling` → `styling/stylesheets#react-views` - `hilla/reference`, now empty → `flow/react-views` (the Lit redirect points there too). This was planned for the last step. - The last partial in `articles/hilla/_shared` is removed. - **Links:** the Routing page links to the new i18n page. - **Guidelines:** the Hilla paragraph no longer mentions the `_shared` partials, and the feature flag guideline no longer names the Hilla Feature Flags section that #6624 removed. - **Corrections** compared with the old pages, each checked in the scratch application: - A missing translation shows as `!de: key`, not as the key. - The old guide wrapped `i18n.configure()` in an effect. It returns a `Promise`, and the page awaits it once in the layout. - The default first delay of the loading bar is 450 ms, not 300 ms. - The old CSS examples didn't show anything with the default theme turned off: the indicator's functional style, which is always present, comes after the application's stylesheets and sets `opacity: 0` and `pointer-events: none`. The examples now use `vaadin-connection-indicator .v-loading-indicator` and set `opacity`. - The `@vaadin/common-frontend` import no longer works after vaadin/flow#26714. ## Test summary - `npm run check-redirects` passes. - `mvn spotless:apply` and `mvn compile` pass. `npx eslint frontend/demo/fusion/i18n` passes. - The two TypeScript examples type-check and run in the scratch application, in English and German. - Checked with the browser: - translations, the ICU plural form, `{0}` placeholders, the missing-key marker, on-demand keys and their warning; - the cookie, the fallback from `de-DE` to `de` and the root file, and the separate Flow locale; - a custom provider without `getAllTranslations()` in development mode (no translations; `initialized` stays `false`); - the loading bar stages during a slow service call, the offline message after a failed call and after the browser's `offline` event, and the online message afterwards; - the reconnecting message of a Flow view with the server stopped; - the TypeScript configuration, the Java configuration overriding only the properties it sets, and the corrected curtain CSS; - global styles, a plain CSS import that stays loaded after navigating away, and a CSS module. - Every cross reference in the new and changed lines resolves. - Vale: no errors or warnings on the added and changed lines with the pull request configuration. - Asciidoctor renders the changed pages, with all includes and tags resolved. - I didn't run a full dspublisher build locally. The TypeScript configuration snippet for the indicator is inline: the docs build is on 25.4.0-alpha5, whose `Flow.js` still uses `@vaadin/common-frontend`, so a compiled example importing the new module wouldn't build yet. Product bugs found during testing, reported separately: - vaadin/flow#26970: `types.d.ts` doesn't declare CSS imports, so with TypeScript 6 the imports in React views fail the type check. The Stylesheets section documents the declarations to add. - vaadin/hilla#7050: after `setLanguage()`, a key that `translateDynamic()` loaded on demand stays empty. The page doesn't describe this behavior. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

vaadin-review-bot reviewed Nov 10, 2026

View reviewed changes

Comment thread articles/flow/react-views/browser-callable-services/code-generation.adoc Resolved

Comment thread articles/flow/react-views/browser-callable-services/type-conversion.adoc Resolved

peholmst merged commit 6200205 into main Nov 11, 2026
11 checks passed

peholmst deleted the claude/react-views-code-generation branch November 11, 2026 06:46

peholmst mentioned this pull request Nov 11, 2026

docs: move React form binding to Flow #6621

Merged

peholmst mentioned this pull request Nov 11, 2026

docs: move React view security to the Flow security reference #6622

Merged

peholmst mentioned this pull request Nov 11, 2026

docs: move full-stack signals to UI State #6624

Merged

peholmst mentioned this pull request Nov 11, 2026

docs: move React i18n, connection indicator and styling to Flow #6626

Merged

peholmst mentioned this pull request Nov 11, 2026

docs: move the React how-tos to Building Apps #6630

Open

Navigation Menu

Repository navigation

docs: move type conversion and code generation to Flow - #6620

docs: move type conversion and code generation to Flow#6620
peholmst merged 2 commits into
mainfrom
claude/react-views-code-generation

peholmst commented Nov 10, 2026 •

edited

Loading

Uh oh!

vaadin-review-bot left a comment

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Nov 10, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

peholmst commented Nov 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What changed

Test summary

Uh oh!

vaadin-review-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Nov 10, 2026

Preview Deployment

Changed pages

Other changed files

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

peholmst commented Nov 10, 2026 •

edited

Loading