Wpis z mikrobloga

@Radaka: Zależy jaką to robi różnicę. Jeżeli zmieniasz string tego samego atrybutu to wystarczy trochę logiki wewnątrz obiektu, ale jeżeli ze ścieżki do obrazka chcesz wyrzeźbić svg to już lepiej oddzielne pole i logika po stronie frontu/generowania htmla.
@MQs: Pobieram produkty i dostaje takeigo jsona:

products : [
{
name: 'bla bla'

image: {
name: "obrazek",
imagepath: "path",
image
thumbnail: "thumbnail"
}
}
]

i teraz chce sobie zmutować relacje tak aby w przypadku gdy produkt nie ma relacji do obrazków to nie zwracał mi nulla, tylko spreparowany przeze mnie obiekt z placeholderami
@Radaka: Jeszcze raz: Jeśli front się nie zorientuje, że spreparowałeś obiekt (te same pola, tak samo obsługiwane) to bez problemu podmieniaj na backendzie. Ale jeśli obiekt zastępujący obrazek ma być czymś innym to lepiej dodatkowe pole, a na image zostawiasz nulla. Inaczej każdy aktualny klient się rozkłada przy tej zmianie bez powodu.
@MQs: Nie chodziło mi czy można tylko jak to zrobić ale rozgryzłem

public function image()
{
return $this->hasOne(Image::class);
}

protected $appends = ['imageone'];

public function getImageOneAttribute($value)
{
return $this->image ?? [nowy
arraygdyniemaobrazka];

}
@Utiopa: No ale bym musiał przeliterować całą kolekcje, sprawdzać czy występuje relacja, zmieniać wartość w zależności czy występuje albo nie występuje i znów budować tablice z nowymi wartościami
@Radaka też tak kiedyś myślałem, ale później jak musisz użyć tego modelu bez obrazów to appends Ci i tak pociągnie, i czemu raz sobie zwracasz jeden obiekt, a raz tablicę?
@lolen: Tablica była by wtedy gdybym musiał przeliterować, to po prostu bym utworzył tablicę i zwrócił ją już jako json, aktualnie zwracam obiekt, z tym że mi dokleja wszędzie dodatkowe pole we wszystkich zapytaniach też jest irytujące, mimo wszystko potrzebuje zrobić tak aby aplikacja jak najmniej była ociązałą