Description
Not really sure if this is considered a bug, an oversight, or deliberately not included so I'll leave it as a bug report for now. Basically, I'm attempting to implement existing file-uploads. I figured the simplest way to do this would be;
- Any files that already exist on the server are instantiated as an instance of
Illuminate\Http\UploadedFile (or my own custom class that extends Illuminate\Http\UploadedFile like Livewire\TemporaryUploadedFile does), and any uploads that are new are instantiated as an instance of Livewire\TemporaryUploadedFile as is default with Livewire. This would allow for relatively easy filtering as database wise we could just check;
- Loop over existing records in database and diff against all elements in your livewire property that aren't an instance of
Livewire\TemporaryUploadedFile. If they don't exist delete them otherwise keep them.
- Collect instances of
Livewire\TemporaryUploadedFile and loop over them and store each of them to the database.
However, it would appear if you attempt to use an instance of Illuminate\Http\UploadedFile as part of the array you use for wire:model, it just obliterates your data when you upload a new Livewire\TemporaryUploadedFile that gets added to the array. See example below;
-
Before another upload:

-
After another upload:

As you can see, the Livewire\TemporaryUploadedFile now exists but it completely purged my previous data.
But if I use another type like a string, or even TemporaryUploadedFile::createFromLivewire($i->getPath());, it persists and doesn't get corrupted by the array as shown below.
-
Before another upload:

-
After another upload:

As you can see, it stays in the array but this doesn't seem like a very good way of doing it since TemporaryUploadedFile causes a lot of issues with the path (since I'd assume it wasn't really built for this purpose) as you can see in the first screenshot, and even just from a naming perspective it seems pretty odd to name an already uploaded/saved file as Temporary.
I'd be interested to see if someone has figured out how to solve this on the current version of Livewire or if it will require some internal changes before a use-case like this is viable with Livewire.
Context
- Livewire version: [1.3.0]
- Laravel version: [7.18.0]
- Browser: [Chrome]
Description
Not really sure if this is considered a bug, an oversight, or deliberately not included so I'll leave it as a bug report for now. Basically, I'm attempting to implement existing file-uploads. I figured the simplest way to do this would be;
Illuminate\Http\UploadedFile(or my own custom class that extendsIlluminate\Http\UploadedFilelikeLivewire\TemporaryUploadedFiledoes), and any uploads that are new are instantiated as an instance ofLivewire\TemporaryUploadedFileas is default with Livewire. This would allow for relatively easy filtering as database wise we could just check;Livewire\TemporaryUploadedFile. If they don't exist delete them otherwise keep them.Livewire\TemporaryUploadedFileand loop over them and store each of them to the database.However, it would appear if you attempt to use an instance of
Illuminate\Http\UploadedFileas part of the array you use forwire:model, it just obliterates your data when you upload a newLivewire\TemporaryUploadedFilethat gets added to the array. See example below;Before another upload:

After another upload:

As you can see, the
Livewire\TemporaryUploadedFilenow exists but it completely purged my previous data.But if I use another type like a string, or even
TemporaryUploadedFile::createFromLivewire($i->getPath());, it persists and doesn't get corrupted by the array as shown below.Before another upload:

After another upload:

As you can see, it stays in the array but this doesn't seem like a very good way of doing it since
TemporaryUploadedFilecauses a lot of issues with the path (since I'd assume it wasn't really built for this purpose) as you can see in the first screenshot, and even just from a naming perspective it seems pretty odd to name an already uploaded/saved file asTemporary.I'd be interested to see if someone has figured out how to solve this on the current version of Livewire or if it will require some internal changes before a use-case like this is viable with Livewire.
Context