Luciano Vernaschi

I opened issue #495 on the Hilla 1.1 generator to describe how it works. Basically, fields are used to generate corresponding TS files and everything (fields and properties) is sent...

Also, considering that Hilla users definitely put annotations on fields, I'm afraid we have to keep using them.

It depends on how we want to implement push support in the multi-module generator: while the generated endpoints are supposed to be identical, the differentiation between `call` and `subscribe` could...

The generator only parses sources in the module the Hilla application is in. That's by design. Work is in progress in version 1.2.0 to overcome this limitation.

That's what version 1.2 does.

Thinking about #440 I thought that, since we're using Jackson to perform the actual data transfer, and since generated TS classes must necessarily match transferred data, we could ask Jackson...

Actually, nothing changes, as `client.subscribe` always returns something, and this change is just to reflect that in TypeScript endpoint return types. Then, if someone returns `null` in theirs Flux-related endpoint...

Actually the `touched` state already exists and is called `visited`. Validation should be triggered immediately on the whole form and validity update status on single fields should be skipped until...

I modified the code to take advantage of the `visited` state and I'm not sure that it is a good idea to implement this change. It doesn't look like a...

The `build-frontend` task is not run in dev mode. Wouldn't it be easier to fix the [order of execution](https://github.com/vaadin/flow/blob/8858e439ad32ee0a88f86002f1a462b8f8c512b5/flow-server/src/main/java/com/vaadin/flow/server/frontend/NodeTasks.java#L699) in `prepare-frontend`?