-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Fix @teleport
directive when view is cached
#8282
Fix @teleport
directive when view is cached
#8282
Conversation
The problem is caused by the fact that the You can test if the Blade::compileString(<<<'HTML'
<div>
@teleport('foo')
bar
@endteleport
</div>
HTML); It's more or less related to #8068. |
@PerryvanderMeer, do you believe that this PR should not continue? |
Well it solves the problem, but I'm not sure why @calebporzio initially limited the scope of the directive to Livewire's blade compiler. |
This doesn't seem to work very well with testing. I also tried creating a component with a blade file and clearing the cache using |
Yeah, this is a problem with using |
All models and slideovers which were in @teleport() behaving odd after this update! They use to stay on screen on subsequent requests now they disappear after a subsequent request! |
@MrPunyapal Can you make a https://wirebox.app that demonstrates the issue? |
@joshhanley https://wirebox.app/ is not working for 3.4.11 only 👀 it works for 3.4.10! |
@MrPunyapal bugger, thanks! Will see if I can get it fixed. |
@MrPunyapal wirebox should be fixed now 🙂 |
thanks @joshhanley see the bug 3.4.10: https://wirebox.app/b/xeo72 3.4.11: https://wirebox.app/b/430dl open the modal and click on add random |
@MrPunyapal Your 3.4.10 Wirebox is private, so we can't access. |
done |
Tested a few things. Blade rendering and Livewire's update response are completely the same. Must be a problem since Alpine 3.13.9. Either way not related to this PR. |
FYI: without @-teleport it has the same behavior on both versions! |
What is causing this is Alpine, not the Blade directive. I made a version of the old directive with the new Alpine and it also fails |
But it's 3.4.11? |
Blade Directive with version 3.4.10 (works) |
Btw I forgot one thing! I was having this in my app service provider! I was using a blade directive from 3.3 only! 🙂 |
Solved it by tweaking some code at all the teleports |
Review the contribution guide first at: https://livewire.laravel.com/docs/contribution-guide
1️⃣ Is this something that is wanted/needed? Did you create a discussion about it first?
#8130
2️⃣ Did you create a branch for your fix/feature? (Main branch PR's will be closed)
Yes
3️⃣ Does it contain multiple, unrelated changes? Please separate the PRs out.
No
4️⃣ Does it include tests? (Required)
No
5️⃣ Please include a thorough description (including small code snippets if possible) of the improvement and reasons why it's useful.
When we run php artisan view:cache, the
@teleport
directive is broken. I didn't understand the reason in depth, however, when we create a directive similar to@this
using the Facade Blade, the same problem does not occur.I noticed how it is called to create the directive for
@teleport
differs from@this
. For this reason, I left it the same as@this
and it worked.I was unable to create a test that runs view:cache and generates the cache for a dusk test at run time