In some way, it kind of makes sense having some @loadOnce, since we didn't tell users to remove the loadOnce and use @basset as we did for most of our code, people who had published files with @loadOnce would expect them to still work.
As you see we only use @loadOnce for blocks of javascript, ence this fix is targeted at that. To expand the scope of this to support either css or js like bassetBlock does, we would need to parse the buffer (ob_get_clean()) and maybe search for <script> or <style> tags.
I could have also changed the @loadOnce directives we have in our code to @bassetBlocks, but that would still be a BC for users that have published those buttons before.
I think this gives us the better compatibility until we remove loadOnce completely in next version as we should have done when launching basset. 🤷 it is what it is.
Some weeks ago I fixed a broken compatibility of basset with @loadOnce directives in #122
That fixed the reported issue but left other cases un-handled, like @loadOnce blocks.
A search across our repos, I see we left some @loadOnce behind in PRO package. https://github.com/search?q=org%3ALaravel-Backpack+%40loadOnce%28&type=code
In some way, it kind of makes sense having some @loadOnce, since we didn't tell users to remove the loadOnce and use @basset as we did for most of our code, people who had published files with @loadOnce would expect them to still work.
As you see we only use @loadOnce for blocks of javascript, ence this fix is targeted at that. To expand the scope of this to support either css or js like bassetBlock does, we would need to parse the
buffer(ob_get_clean()) and maybe search for<script>or<style>tags.I could have also changed the @loadOnce directives we have in our code to @bassetBlocks, but that would still be a BC for users that have published those buttons before.
I think this gives us the better compatibility until we remove loadOnce completely in next version as we should have done when launching basset. 🤷 it is what it is.