Closed aerni closed 2 months ago
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.
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?
Yes, it all works without conflicts. If you manually include the Livewire assets, the assets won't be injected a second time.
Thanks. I just wanted to be sure.
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.The
AssetsReplacer
adds support …@assets
Blade directive. Without this PR, the assets wouldn't be pushed to the head at all.