-
-
Notifications
You must be signed in to change notification settings - Fork 518
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
[5.x] Fix issue when using Livewire with full measure static caching #10306
Conversation
Marking this PR as a draft for now. Once the tests are passing, feel free to mark this as "ready for review" and we can take a look. 👍 |
I've fixed the tests. An alternative approach to the code changes could be to simply add the script at the beginning of the |
Copied over from Discord:
Currently I am using this code to initialize Livewire: if (window.livewireScriptConfig?.csrf === 'STATAMIC_CSRF_TOKEN') {
document.addEventListener('statamic:nocache.replaced', () => Livewire.start());
} else {
Livewire.start();
} |
That seems like a better approach to me. Even if we move the nocache js to the top of the page, the ajax request might still take longer than expected for a number of reasons. If you start Livewire only after the |
I'm not sure if it's a good idea to defer The only issue with the CSRF token is that a script might request an update to Livewire before the token has been fetched and replaced.
@jasonvarga Would this be a better solution? So we could have the CSRF token script in the head and the nocache script at the end of the body? Also, worth considering; if Livewire allowed hooking into its update cycle, we could maybe add some code to tell Livewire to only execute the update requests once |
Ok yeah that's all valid too. |
The one issue, that we try to solve, are 419 errors if Livewire tries to update without a valid token, right? |
Yes, that's the issue this PR tries to solve. 😄 |
I did some more testing, and it turns out that this PR works as expected when letting Livewire do its magic script injection, as per jonassiewertsen/statamic-livewire#64. This PR also reduces the initial load times as mentioned by @morhi. So Livewire can start without having to wait for the CSRF token to be replaced. However, if you are manually bundling Livewire, you are required to add this code shared above to your bundle: if (window.livewireScriptConfig?.csrf === 'STATAMIC_CSRF_TOKEN') {
document.addEventListener('statamic:nocache.replaced', () => Livewire.start());
} else {
Livewire.start();
} If you don't, you will still run into a I wish we could abstract this away somehow. |
Ping @jasonvarga |
I've worked on a couple of PR's for Jonas' Livewire addon to enhance support for Statamic's static caching. See jonassiewertsen/statamic-livewire#61 and jonassiewertsen/statamic-livewire#64.
The newly added
AssetsReplacer
adds support for Livewire's@assets
Blade directive, that allows you to push assets into the<head>
.I've previously PR'd support for Livewire and Statamic's full measure static caching in #8762. This script works as expected in general scenarios. However, I've encountered an edge case, where the CSRF token isn't replaced in time before a request to Livewire is made.
This can happen, when a script, added to the
<head>
with the@assets
directive, is making requests to Livewire, e.g. withthis.$wire
. The issue is that at the time of this request, the CSRF token hasn't been replaced yet, as the nocache script is only executed at the end of the</body>
. Sothis.$wire
is making a Livewire request using theSTATAMIC_CSRF_TOKEN
placeholder as the CSRF token.This PR resolves this issue by moving the nocache JS to the head before any
<link>
or<script>
so that the CSRF token placeholder is replaced before any other script is executed.