Skip to content
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

Add support for static caching #61

Merged

Conversation

aerni
Copy link
Contributor

@aerni aerni commented Jun 1, 2024

This PR adds a new AssetsReplacer class to make Livewire compatible with Statamic's static caching. The replacer is merged with existing replacers and loaded automatically. Users may swap the replacer class with their own implementation or add additional replacers in the config.

/*
|--------------------------------------------------------------------------
| Replacers
|--------------------------------------------------------------------------
|
| Define the replacers that will be used when static caching is enabled
| to dynamically replace content within the response.
|
*/

'replacers' => [
    \Jonassiewertsen\Livewire\Replacers\AssetsReplacer::class,
],

The AssetsReplacer adds support …

  • … for automatic injection of Livewire scripts and styles. Previously, you had to manually include the Livewire assets when using static caching.
  • … for Livewire's @assets Blade directive. Without this PR, the assets wouldn't be pushed to the head at all.

@aerni
Copy link
Contributor Author

aerni commented Jun 1, 2024

Thinking about this a little more, it might be a bit overkill to have an array of replacers in the config, as users can already add their own additional replacers in Statamic's static caching config file.

An array of replacers would make sense if there was more than one replacer that this addon provides. I could imagine to possibly extract the Livewire-specific CSRF token replacer functionality from Statamic's existing CSRF replacer and remove that code from Statamic's replacer.

But if we just deal with one replacer, it's maybe sufficient to just have a replacer config key with the AssetsReplacer as the value. You might even argue, that it's unnecessary to have the replacer configurable in the first place. However, I think it doesn't hurt and provides more flexibility to the users in case they need to customize some stuff.

@jonassiewertsen
Copy link
Owner

Thanks for this PR, which does look really good.

Are there any side effects we should be aware of might it even be a breaking change somehow?

Previously, you had to manually include the Livewire assets when using static caching.

Does it work without any conflicts, in case I update the Livewire addon, but still include my Livewire assets manually?

@aerni
Copy link
Contributor Author

aerni commented Jun 3, 2024

Yes, it all works without conflicts. If you manually include the Livewire assets, the assets won't be injected a second time.

See here:

public function replaceInCachedResponse(Response $response)
{
if (Str::contains($response, FrontendAssets::scripts())) {
return;
}
if (Str::contains($response, FrontendAssets::scriptConfig())) {
return;
}
app(FrontendAssets::class)->hasRenderedScripts = false;
Livewire::forceAssetInjection();

@jonassiewertsen
Copy link
Owner

Thanks. I just wanted to be sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants