7 回答

TA貢獻(xiàn)1798條經(jīng)驗(yàn) 獲得超7個贊
就我而言,解決方案是保護(hù)公共財(cái)產(chǎn)并將其手動傳遞給刀片,因此它被排除在 Livewire 的自動處理之外。

TA貢獻(xiàn)1946條經(jīng)驗(yàn) 獲得超3個贊
要解決此問題,請打開vendor/livewire/livewire/src/ComponentChecksumManager.php 文件并var_dump($stringForHashing);
在第19 行return 語句之前添加。然后,您可以看到正在散列的數(shù)據(jù),并將其與之前的散列數(shù)據(jù)進(jìn)行比較,以找出差異。
完成此操作后,我能夠識別 javascript 重新排列的數(shù)字鍵并提出適當(dāng)?shù)男迯?fù)方法。
需要注意的一件事是,某些 json 格式化程序也會對數(shù)字鍵重新排序,因此最好在不格式化或手動格式化的情況下比較 json。
編輯:使用 var_dump 可能會干擾某些頁面的功能,因此將數(shù)據(jù)寫入文件可能是更好的選擇:
file_put_contents('/path/to/log.txt', $stringForHashing . "\n\n", FILE_APPEND);

TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超7個贊
無論如何,我們的問題是一個非常大的整數(shù),大于 javascript 通過 Number.MAX_SAFE_INTEGER 可以處理的整數(shù)。
我們在這里填寫了錯誤報(bào)告:https://github.com/livewire/livewire/discussions/4788 (livewire 2.10.4)。
因此,當(dāng)使用太大的整數(shù)時,沒有解決錯誤本身的方法。如果您想將您的值視為真正的整數(shù),那么您現(xiàn)在運(yùn)氣不佳,但也許轉(zhuǎn)換為字符串可能適合您。(和/或在 php 端進(jìn)行計(jì)算 - 使用受保護(hù)的屬性 - 如果在您的情況下可行)。
話雖這么說,我們問題的真正原因是 uuid 轉(zhuǎn)換為 int,因?yàn)槲覀儧]有填充protected $keyType = 'string';
Laravel 模型的 ( https://laravel.com/docs/9.x/eloquent#primary-keys )!

TA貢獻(xiàn)1775條經(jīng)驗(yàn) 獲得超8個贊
除了上面其他人建議的之外,如果您有一個使用groupBy()可能是此問題原因的集合,也可能會發(fā)生這種情況,
要修復(fù)此問題,請protected $attribute在組件中使用,而不是public傳遞$attribute到組件視圖。
protected $attribute;
public function mount($attribute){
$this->attribute = $attribute;
}
...........
public function render()
{
return view('livewire.view-here',['attribute'=>$attribute]);
}

TA貢獻(xiàn)1812條經(jīng)驗(yàn) 獲得超5個贊
在我的例子中,Livewire 組件引用了一個具有自定義屬性的模型,該屬性是使用Carbon::now()
因此,每次組件嘗試水合時,該屬性都有不同的值,因此被“損壞”。

TA貢獻(xiàn)1836條經(jīng)驗(yàn) 獲得超13個贊
我這樣做了,它對我有用:
php artisan config:cache php artisan config:clear
- 7 回答
- 0 關(guān)注
- 312 瀏覽
添加回答
舉報(bào)