Vue property decorator. Uparcie nie odczytuje wartości propsa.

Mam taki komponent vue i korzystam z vue-property-decorator.

<script lang="ts">

import {Vue, Component, Prop} from 'vue-property-decorator';
 @Component
	export default class LinksBox extends Vue{
        @Prop(String) readonly previousURL!: string
        @Prop(String) readonly nextURL!: string

W taki sposób przekazuję wartości w Blade :

@if(!$movies->onFirstPage()) previousURL="test" @endif
@if($movies->hasMorePages()) nextURL="test" @endif>

Kombinowałem chyba na 20 sposobów i dalej nie widzi wartości propsa przekazywanej do komponentu. Co ja mam w końcu zrobić aby on łaskawie to zauważył?

Co to za konstrukcja "@if"? Domyślam się, że Laravel. Chciałem to napisać w Twoim poprzednim temacie ale się powstrzymałem więc teraz napiszę: Nie łącz back-endu z front-em. Zrób sobie osobny projekt na API i osobny na aplikacje webową. Z czasem będziesz miał coraz więcej problemów z połączeniem tego.

Odpowiadaj proszę w postach.

Chcesz mi powiedzieć, że jedynym słusznym podejściem do tworzenia aplikacji internetowych jest Client Side Rendering(jak rozumiem o to Ci chodzi)? Zrobiłem małe badanie tematu i z tego co się dowiedziałem, zarówno generowanie po stronie serwera jak i po stronie klienta ma swoje plusy i minusy stąd nie rozumiem skąd u Ciebie przekonanie, że powinienem zorganizować to w sposób jaki opisałeś, tym bardziej, że nie znasz szczegółów mojego projektu.

Nie. Jedynym słusznym podejściem jest całkowita separacja backendu (API) od frontendu (aplikacja webowa).

To czy będziesz używał CSR (client side rendering) czy SSR (server side rendering) zależy od sposobu w jaki zbudujesz aplikację webową. Dla Vue istnieje np. https://nuxtjs.org/ który pozwala Ci na implementacje SSR bardzo małym kosztem.

Założmy taki sceniariusz:
Użytkownik wchodzi na podstronę /kontakt a następnie klika w link /oferta.

Co się zadzieje w przypadku aplikacji:
a) Laravel (własna implementacja SSR + Vue)
Użytkownik wykona 2 razy żądanie GET przez co będzie musiał pobrać cały HTML od nowa.

b) NuxtJS
Użytkownik za pierwszym razem wykona żądanie GET, drugie żądanie nie będzie miało miejsca, chyba, że po ew. zasoby do API.

Boty (dla których się buduje aplikacje SSR) nie będą widziały różnicy pomiędzy a) i b) - użytkownik natomiast ją zobaczy w szybkości działania tj. b) jest znacznie szybsze.

Chociaż i tak najważniejszym argumentem jest przejrzystość kodu, łączenie ifów laravela z ifami z Vue - tego się nie będzie dało debugować przy bardzo skomplikowanym kodzie i programista straci trochę włosów (oby nie zębów ;)).

Przyznam szczerze, że nie do końca rozumiem co masz na myśli.

b) NuxtJS
Użytkownik za pierwszym razem wykona żądanie GET, drugie żądanie nie będzie miało miejsca, chyba, że po ew. zasoby do API.>

Jak to drugie żadanie nie będzie miało miejsca? To skąd aplikacja weźmie kod dla oferty?

użytkownik natomiast ją zobaczy w szybkości działania tj. b) jest znacznie szybsze.>

Dlaczego?

Chociaż i tak najważniejszym argumentem jest przejrzystość kodu, łączenie ifów laravela z ifami z Vue - tego się nie będzie dało debugować przy bardzo skomplikowanym kodzie i programista straci trochę włosów (oby nie zębów ;)).>

W jaki sposób to zwiększa przejrzystość kodu?

Jak to drugie żadanie nie będzie miało miejsca? To skąd aplikacja weźmie kod dla oferty?

Kod dla oferty będzie już pobrany w 1 żądaniu. Tak działają aplikacje SPA/CSR. NuxtJS przy pierwszym żądaniu zachowuje się jak SSR, przy każdym następnym jak SPA/CSR.

Dlaczego?

Załóżmy, że podstrona /kontakt zajmuje 100kB, /oferta też 100kB. Ale różnica pomiędzy nimi wynosi np. 10kB (trochę tekstu reszta wygląda podobnie). Więc w przypadku całkowitego SSR musisz pobrać 200 kB (1 żądanie 100kB, 2 też 100kB), w przypadku SPA/CSR 110kB (1 żądanie 110kB, 2 żądanie 0kB).

W jaki sposób to zwiększa przejrzystość kodu?

Nie chcę Cię do tego przekonywać, możesz zrobić projekt w Laravel w magiczym połączeniu z Vue, zadawać na forum pytania jak rozwiązać problemy które z tego połączenia wynikają a po kilku latach przekonać się, że jednak warto rozdzielić kod na 2 części.

Kod dla oferty będzie już pobrany w 1 żądaniu. Tak działają aplikacje SPA/CSR. NuxtJS przy pierwszym żądaniu zachowuje się jak SSR, przy każdym następnym jak SPA/CSR.>

No to jeżeli tak ma się sytuacja to kolejne co przychodzi na myśl to :
Czy w takim razie przy pierwszym rządaniu pobieramy wszystkie szkielety(w sensie bez np. informacji z bazy danych) do wszystkich możliwych podstron? Czy jeszcze inaczej? Jak rozumiem nuxt ogarnia tutaj wszystko pod kątem SEO.

Załóżmy, że podstrona /kontakt zajmuje 100kB, /oferta też 100kB. Ale różnica pomiędzy nimi wynosi np. 10kB (trochę tekstu reszta wygląda podobnie). Więc w przypadku całkowitego SSR musisz pobrać 200 kB (1 żądanie 100kB, 2 też 100kB), w przypadku SPA/CSR 110kB (1 żądanie 110kB, 2 żądanie 0kB).>

No to rozumiem, to oczywiście jest zysk

Nie chcę Cię do tego przekonywać, możesz zrobić projekt w Laravel w magiczym połączeniu z Vue, zadawać na forum pytania jak rozwiązać problemy które z tego połączenia wynikają a po kilku latach przekonać się, że jednak warto rozdzielić kod na 2 częśc>

Nie będę się upierał bo nie mam na tyle doświadczenia. Ale z tego co piszesz wynika(przynajmniej ja to tak rozumiem), że należałoby de facto całkowicie odstawić generowanie html w twig'u i w przypadku laravel'a w blade. I twierdzisz, że jeżeli mam projekt w Laravel + Vue to bardzo rozsądnym byłoby wykorzystanie nuxt'a?

No to jeżeli tak ma się sytuacja to kolejne co przychodzi na myśl to :
Czy w takim razie przy pierwszym rządaniu pobieramy wszystkie szkielety(w sensie bez np. informacji z bazy danych) do wszystkich możliwych podstron? Czy jeszcze inaczej? Jak rozumiem nuxt ogarnia tutaj wszystko pod kątem SEO.

Tak właśnie jest, ale można to skonfigurować tak, żeby przy pierwszym żądaniu pobrał tylko te 100kB a przy wejściu na stronę /oferta pobierze sobie w tle (plik *.min.js) te brakujące 10kB.

Ale z tego co piszesz wynika(przynajmniej ja to tak rozumiem), że należałoby de facto całkowicie odstawić generowanie html w twig'u i w przypadku laravel'a w blade. I twierdzisz, że jeżeli mam projekt w Laravel + Vue to bardzo rozsądnym byłoby wykorzystanie nuxt'a?

Tak, jeżeli chcesz SSR i Vue to musisz wykorzystać Nuxt - ale z projektu Laravel należy całkowicie się pozbyć Vue.