livewire: Livewire not working with mix.browserSync
Description
Okay, so I first don’t know if Livewire is supposed to work with mix.browserSync, so please let me know if it’s just plain not supported. I see that there have been issues #996 and #1130 touching this topic and in #996 it seems that the issue author got it working by updating Livewire to 1.2.0. I’m using Livewire version 2.3.15.
I tried to start using Livewire in our Laravel 8 application that is in development and followed the quick start guide to implement the example counter. I had this error:
Livewire encountered corrupt data when trying to hydrate the [counter] component. Ensure that the [name, id, data] of the Livewire component wasn’t tampered with between requests.
After some investigation I found out that Livewire works with the url https://projectname.valet.test but not with the Browsersync proxy url: https://localhost:3000
To make debugging easier I installed a fresh Laravel 8 instance in url https://laravel-8.valet.test with just livewire/livewire package, configured Browsersync like this: mix.browserSync('https://laravel-8.valet.test'); and followed the counter functionality in the quick start guide. That gave me the very same result:
Livewire encountered corrupt data when trying to hydrate the [counter] component. Ensure that the [name, id, data] of the Livewire component wasn’t tampered with between requests.
So I assumed that Livewire checks the APP_URL and compares it with the request domain and changed APP_URL to match https://localhost:3000, but still had the same issue.
Is this a bug? Is there something I should do to get this working? Or is Livewire just not compatible with mix.browserSync?
Exact steps to reproduce
1.) Install fresh laravel/laravel 8.5.9
2.) Install Livewire 2.3.15
3.) Add mix.browserSync('https://yordomain.test'); into your webpack.mix.js
4.) Run npm i && npm run watch
5.) Start implementing the counter functionality.
Context
- Livewire version: 2.3.15
- Laravel version: 8.5.9 (laravel/framework 8.26.1)
- Alpine version: none
- Browser: Firefox Developer Edition
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 11
- Comments: 24
@roni-estein, completely agree. However, none of the breaking changes were intended, and all are trying to be addressed.
This is all coming about because of a necessary security patch. I’m trying literally my best with this. Please understand.
Agreed, I should have tagged 2.4 for that fix, but from a semvar perspective it really is a patch in the sense that it plugs a hole. But it did an a new API and like people have mentioned broke some things, so in hindsight it should have been 2.4.
Anyhow, sorry for the trouble, I really am. But all of this had to be done. After this pain, Livewire will go back to stability. This is an exceptional case and not the way Livewire will behave or ever has behaved. We are dedicated to stability and compatibility around here.
(also working on a fix for this)
I’ve tried just about every permutation of this, and I’ve gotten it to work, but there are always weird side effects from livewire itself not working properly to others. If someone finds a clear non-hack methodology to work with browser-sync, please post it here. I’d be happy to move forward, as it is it’s robbed too many hours from my work week.
I will say not just on the browser-sync front, but it is very frustrating and disheartening to have so many core changes happening in minor patch releases. This whole issue could have come about by releasing this as 2.4.0. Now I do get that this is coming from patching other items that had issues as well, and there are always tradeoffs, but this isn’t the first breaking change released as a minor patch. As I use Livewire in a lot of production work, I am really kind of nervous about delegating any upgrades at this point. I love and support livewire both with money and time on discord. Please take some time to think about semantic versioning and major-minor releases. I’m fine with things having issues, but blowing me up in a safe composer update shouldn’t happen. For now, I’m just locking all my projects on. 2.3.8.
I’ve been DEEP into laravel migration land for a while but I’m back in livewire action. I can check it out this tonight after I get the kids to bed, and see if file uploads work in the current browsersync pretty quickly. I’ll run the redirect intended too, and give you an update on both and see if I can find anything.
I’m only referencing browser-sync here because that’s the start of this issue. But no. You should source dive the changes from 2.3.9 on, they are extensive. This is one.
Fixed and tagged: v2.3.17
Re-open if I’m wrong.
As much as I understand the displeasure – isn’t this really just a bug about using BrowserSync? Sure, it is a bit uncomfortable to go without BrowserSync if you are used to it, but the function of Livewire itself is still given, isn’t it?
Browsersync continues to run on 3000 ports. Even if you don’t access to 3000 ports, you’ll still be able to get browserync.js. I checked that it works in v2.3.16.
https://github.com/livewire/livewire/commit/2ff70fdd893ecf9860fb70105efbc81aee93a02a
the effect of changing
Livewire::originalUrl()to returnurl()->current()Temporary solution (v2.3.16)
Run and open http://localhost:8000 Now Livewire with browserSync works fine in APP_ENV=local