Port the Flow client engine from GWT/Java to TypeScript and delete the GWT client - #25216
Open
totally-not-ai[bot] wants to merge 1 commit into
Open
Conversation
Follow-up to #25210. The port comments described work in progress -- "built alongside the Java version", "not ported yet", "contracts satisfied at cutover", constraints imposed by the HtmlUnit-based GwtTests, and $entry wrappers on the Java side -- none of which is true now that the GWT client is gone. publishClient still claimed it was "not yet wired into the bootstrap", pointing at a MIGRATION_STRATEGY.md that does not exist in the repository, and SimpleElementBindingStrategy said its functions would be assembled into a class that it already defines. Reword them to describe the code as it is, keeping the references to the GWT original where they explain why something looks the way it does. The "Slice N:" section headers, which numbered the migration steps, lose the numbering and keep their titles. Also remove what the GWT deletion left behind: the com/google/gwt/dev/js/globals resource, the gwt.version property and the gwt-elemental dependencyManagement entry in the root pom (no module depends on GWT any more), and ApplicationConstants.CLIENT_ENGINE_PATH, which named a folder that is no longer served or referenced. SessionCloseLogoutIT no longer allows console errors from the removed client engine path.
|
Contributor
Test Results 1 424 files - 26 1 509 suites +58 1h 29m 5s ⏱️ + 1m 37s For more details on these errors, see this check. Results for commit a5ba6fc. ± Comparison against base commit dc167bc. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



The Flow client engine — the code that runs in the browser, applies the server's state-tree changes to the DOM, and carries the client half of the UIDL protocol — was written in Java and compiled to JavaScript with GWT. This change replaces it with a hand-written TypeScript implementation under
flow-client/src/main/frontend/internal, bundled with esbuild, and removes the GWT client engine and its build machinery entirely.What changed
New TypeScript engine (79 modules). The port follows the Java sources one-to-one so the two can be diffed against each other: bootstrap (
Bootstrapper,ApplicationConfiguration,ApplicationConnection), the reactive state tree (StateNode,StateTree,TreeChangeProcessor, node features,Reactive), the binding layer (SimpleElementBindingStrategy,TextBindingStrategy,ServerEventObject,Debouncer), networking (MessageSender,MessageHandler,XhrConnection,AtmospherePushConnection, reconnect/heartbeat/poll handling), and the support services (ResourceLoader,DependencyLoader,Profiler,SystemErrorHandler,PolymerUtils,LitUtils, …). The wire-format constants stay mirrored from their server-side counterparts.Modernization enabled by dropping GWT. The
DomApiabstraction and the Polymer/HTML-import DOM path are gone — the port uses native DOM directly in the binding layer and inApplicationConnection, and the bootstrap no longer waits for an HTML-imports-ready gate (#25145, #25146). The GWT client fix from #25147, keeping replaced children in place until their replacements are inserted so a refilled container is never momentarily empty and the scroll position survives, is carried into the port.Removal of the GWT client. All 105 Java classes under
com.vaadin.clientplus the bundled GWT support classes andcom.vaadin.flow.linker.ClientEngineLinkerare deleted, along with the client-engine<script>tag inBootstrapHandler,ApplicationConstants.CLIENT_ENGINE_PATH(it named a folder that is no longer served), thecom/google/gwt/dev/js/globalsresource, and thegwt.versionproperty andgwt-elementaldependencyManagemententry in the root pom. No module depends on GWT any more.Fixes on top of the port
getJavaClassread the wrong node property. The port declared a localJAVA_CLASS = "class"constant whileNodeProperties.JAVA_CLASSis"jc", so thejavaClassfield of the dev-modeclient.getNodeInfo(nodeId)API — used by dev tools to report the component type behind an element — was always null. The constant now lives in the TSNodePropertiestable with the other mirrored wire names, and theApplicationConnectiontest fixture, which hardcoded the same wrong key and hid the bug, now uses the keys the server actually writes.doStartApplicationused a dynamic import, which made startup asynchronous where the Java bootstrap was synchronous and split the engine into its own bundler chunk (4.8kB + 105kB + 1.2kB versus a single 111kB chunk). That chunk is always fetched, so the split only added a round-trip to the startup critical path. No engine module has top-level side effects and the module graph is acyclic, so static import is safe; a test asserts the client API is published by the timedoStartApplicationreturns.Console.javasuppressed browser logging in production unless thevaadin.browserLoglocalStorage flag was set; the port carried over only the flag check and calledconsole.*directly from every module, so all 64 log statements across 21 modules logged unconditionally — including the raw session-resynchronization response body.Consolenow hassetProductionModeand gateddebug/log/warn/error,ApplicationConfigurationcallssetProductionModeagain, and an eslintno-consolerule oversrc/main/frontend/internalkeeps it from regressing. Two sites stay ungated (marked) because their Java counterparts were JSNI callingconsole.errordirectly.Also cleaned up: comments describing the port as work in progress ("not ported yet", "contracts satisfied at cutover",
$entrywrappers, constraints from the HtmlUnit-basedGwtTests) are reworded to describe the code as it is, keeping references to the GWT original where they explain why something looks the way it does; theMIGRATION_STRATEGY.mdpointer, which never existed in this repository, is dropped.SessionCloseLogoutITno longer whitelists console errors from the removed client engine path.API Changes
165 classes affected: 105 classes removed, 1 constant removed.
com.vaadin.flow.shared.ApplicationConstants
com.vaadin.flow.linker.ClientEngineLinker
com.vaadin.client.* (GWT client engine — 104 classes removed)
The entire GWT client engine is deleted. All of these types were public; they were only ever consumed by the GWT compiler and by client-side add-ons compiled against the engine, and have no replacement on the Java side — the equivalents now live as TypeScript modules in
flow-client/src/main/frontend/internal.