Leif Åstrand

I would rather implement the main layout in a slightly different way that should be basically equivalent from a functional point of view but might be easier to understand. `@layout.tsx`...

That example might work in this particular case but it can be improved for clarity and to work as expected also in other cases. The first problem is that the...

I don't think there's any reason to have `vaadin.documentTitleSignal.value = currentTitle;` inside `useEffect`. All that `useEffect` does in that case is to avoid running the callback again if `currentTitle` hasn't...

All the actual logic for interpreting the value that Flow sets in the signal instance is in `@layout.tsx` which is owned by the application. The application developer can remove all...

Note to whoever investigates this: the symptoms sound like the old issue with how downloads trigger a "premature" `beforeunload` event and then a listener for that event assumes that the...

Could you give some examples of the kind of operation that you would want to do for the root of the DOM structure when running as a regular UI and...

I lean towards just updating documentation unless we discover some specific use case that would really necessitate a change. The reason for this is that I suspect I suspect there's...

Those examples do indeed point towards a direction where the current `UI.getElement()` would remain as it is today and we should just supplement documentation to encourage considering whether it's the...

I guess this goes both ways. If you add some new functionality in a package that isn't included, then you will believe it's broken if it isn't automatically picked up...

There would be the same challenge with session locking as for any other approach for external storage of the session: https://github.com/vaadin/flow/issues/4746#issuecomment-434593526 On the other hand, there's a workaround for those...