-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HasUrlParameter.setParameter is executed twice with vaadin.eagerServerLoad=true #16046
Comments
the same relates to |
My biggest issue with this is that I have some pretty expensive business logic triggered by |
If you know it's always two times called (has to be checked), just a add counter or AtomicBoolean as class field that checks if this is the second call as temporary workaround? |
Thank you for your reply. The problem with the proposed counter is that the |
@knoobie thank you very much! Your workaround with |
@knoobie There is one side effect with this approach - the Router links don't work after the page is loaded. For example, I have a Product Catalog View with multiple pages. When I'm on the page #2 or more, it is very convenient to click on the Product catalog router link to quickly return to the page #1. The I'll really appreciate if you could fix this issue on your end. |
Just FYI - I don't know is it related somehow, but during initial start up of the application I may very often see resync issue:
|
any chance to fix this problem soon? |
I don't think it has any priority at the moment looking at the impact because it occurs only with eagerServerLoad=true which in turn is a rarely used feature. |
That's sad ( Is there any other way right now to dynamically change meta tags other than with help of |
I tried a fix for this but there seems to be another underlying problem of the eagerly provided UIDL not being used at all.. |
thank you! I'll really appreciate if you could fix it. It causes a lot of issues to me right now ( |
Sure, if you tell how. If the routing happens only on the second request, it is a bit too late to write the response code for the first.. |
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
@Artur- I see the number of associated commits, what a great news, thank you! Does this mean that potentially this issue will be fixed with help of them? If so, will it be included into Vaadin Flow 24.0.3? |
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
#16498 fixes this indeed. It will not make it to 24.0.3 but hopefully the following release |
Awesome news! Thank you very much! |
Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
) Changes bootstrap for eager mode so that the index page contains the <flow-container-[appId]> div and the virtual child for this element is created eagerly on the server. This allows the initial render on the client side to put the content inside the flow-container instead of document body as happened before. By using a convention on how the container div is created and id is set, we no longer need to communicate the element tag and id from the client. Fixes #16046
Hi @Artur- I just updated to Vaadin 24.0.4 Looks like the fix still hasn't been added there? |
It's not backported |
Sorry to bother you with this, but do you have any information on when this will be released? I'm just waiting for this fix more than my own birthday :) |
This ticket/PR has been released with Vaadin 24.1.0.alpha3 and is also targeting the upcoming stable 24.1.0 version. |
Description of the bug
I have a View which
implements HasUrlParameter<String>
.Also I configured:
vaadin.eagerServerLoad=true
(for IndexHtmlRequestListener)with such setup,
HasUrlParameter.setParameter()
method is executed twice during the first page loadExpected behavior
HasUrlParameter.setParameter()
method is executed only one time during the first page load withvaadin.eagerServerLoad=true
Versions
The text was updated successfully, but these errors were encountered: