[PHP] Het grote Laravel topic

[Chris7]

Hiroj schreef op dinsdag 1 september 2020 @ 10:06:
[...]

Tailwind wil ik ook niet helemaal afschuiven, maar qua overzicht bewaren in een blade view is het wel erg lastig. Enige oplossing daarvoor die ik nu heb gezien (ook tijdens de talk) is dat je alle blokken in components transformeert.

Desalniettemin ga ik het eens proberen en kijken waar het mij brengt. Wie weet stap ik ook wel volledig over op TailwindCSS. Heb jij nog goede tips voor mij waar ik rekening mee moet houden?

Overzicht vind ik zelf ook het grootste nadeel, maar dat weegt in mijn ogen niet op tegen de voordelen. Plus het dwingt je inderdaad eerder grote files op te breken in componenten.

- De documentatie is uitstekend. In het begin moet je soms nog opzoeken welke CSS properties mappen naar welke classes. Verder hebben ze ook een heel aantal screencasts voor als je dat een prettige manier van leren vindt.
- Gebruik PurgeCSS om bij een productie build alleen de classes over te houden die je gebruikt. Zit tegenwoordig ingebakken in Tailwind, zie docs.
- Omdat je bijna geen CSS meer schrijft vind ik een preprocessor zelf niet meer nodig, is weer een klein stukje complexiteit minder. Ik gebruik nu vanilla CSS, met in m'n laatste project wel een paar PostCSS plugins die in de Tailwind docs worden aangeraden (Tailwind is zelf ook al een PostCSS plugin).
- Tailwind UI is betaald maar heeft van veel componenten ook een gratis variant, en omdat het alleen utility classes gebruikt zijn die makkelijk te customizen. Aanrader alleen al om eens te kijken hoe de makers van het framework componenten opzetten.

[rnark]

Release day! Wat vinden jullie de meest interessante nieuwe feature in Laravel 8?

Persoonlijk vind ik Jetstream heel interessant. Maar de release zit eigenlijk vol met mooie nieuwe features.

[Postman]

Jetstream lijktleek me ook interessant, totdat ik zag dat je geforceerd word om Tailwind te gebruiken én npm te draaien.
Waarom weer zo ingewikkeld allemaal. Kan ik niet gewoon Jetstream met Bootstrap 4 blijven gebruiken? Google helpt me helaas niet, alleen maar Bootstrap bashing resultaten.

[Barryvdh]

Wat is er mis met NPM draaien?

Een Bootstrap variant heb ik nog niet gezien inderdaad, maar is wellicht niet zo spannend om te bouwen.

[Postman]

Barryvdh schreef op dinsdag 8 september 2020 @ 11:43:
Wat is er mis met NPM draaien?

Niets als je het ook daadwerkelijk gebruikt. Anders geeft het alleen nog maar meer overhead (deploy op een shared host, dus geen SSH).

Een Bootstrap variant heb ik nog niet gezien inderdaad, maar is wellicht niet zo spannend om te bouwen.

Heb het even geprobeerd en ook op Reddit was de conclusie dat het toch wel wat meer voeten in de aarde heeft dan een simpele aanpassing. Het is zo diep verweven dat CSS al aanzienlijk wat hoofdbrekens geeft, maar vooral de JavaScript vervolgens voor problemen zorgt.

Wellicht dat er Bootstrap UI zullen komen vanuit de community, maar nadeel daarvan is dat je moet afwachten of het bijgewerkt word. En de hele UI -auth optie lijkt de kant van deprecated op te gaan, het is al legacy genoemd in de release notes van 8.

Voor iemand die net een simpele blog heeft gemaakt in Laravel om te gebruiken in een website gemaakt met Bootstrap 4 (en waar het Laravel project dus compleet los van staat) zijn deze aankondigingen niet echt bemoedigend. Het is dat een shared host weinig opties biedt, anders was het een beetje de discussie over PHP in de coffee corner voor mij...

Waarom Laravel trouwens: omdat het een makkelijke en volgens mij goede manier geeft om login en registratie te doen. Een blog zou ik ook in plain PHP kunnen maken, alleen heel het security wiel opnieuw uitvinden zie ik niet zitten.

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 11:59:
[...]

Niets als je het ook daadwerkelijk gebruikt. Anders geeft het alleen nog maar meer overhead (deploy op een shared host, dus geen SSH).

Maar je kan toch lokaal bouwen en dan gewoon de gecompileerde bestanden committen en deployen?

[Postman]

Barryvdh schreef op dinsdag 8 september 2020 @ 12:09:
[...]


Maar je kan toch lokaal bouwen en dan gewoon de gecompileerde bestanden committen en deployen?

Vendor was al 6000+ bestanden met 49MB. Om nog meer troep te moeten uploaden zie ik niet zitten. En ja troep want ik gebruik het niet, heel de node_modules map is dus onzin voor mij en alleen omdat Jetstream het forceert.

Dus ik blijf maar bij UI met Bootstrap voorlopig en kijk wel of ze een update doen voor Jetstream. En anders misschien helemaal van Laravel afstappen, kijken wat er nog voor andere mogelijkheden zijn die security out of the box leveren.

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 12:36:
[...]

Vendor was al 6000+ bestanden met 49MB. Om nog meer troep te moeten uploaden zie ik niet zitten. En ja troep want ik gebruik het niet, heel de node_modules map is dus onzin voor mij en alleen omdat Jetstream het forceert.

Dus ik blijf maar bij UI met Bootstrap voorlopig en kijk wel of ze een update doen voor Jetstream. En anders misschien helemaal van Laravel afstappen, kijken wat er nog voor andere mogelijkheden zijn die security out of the box leveren.

Je vendor of node_modules hoef je ook niet te committen hè, tijdens een deploy doe je gewoon composer install. En je JavaScript en CSS bevatten alles in app.js/app.css normaal gesproken na compileren.

[amphora]

Barryvdh schreef op dinsdag 8 september 2020 @ 12:43:
[...]


Je vendor of node_modules hoef je ook niet te committen hè, tijdens een deploy doe je gewoon composer install. En je JavaScript en CSS bevatten alles in app.js/app.css normaal gesproken na compileren.

Voor composer install moet je wel SSH toegang hebben, en dat heeft hij niet (shared hosting).
Ik bouw ook regelmatig kleinere sites met Laravel maar als de klant alleen een FTP account aanlevert ga ik ze toch echt proberen te overtuigen om een andere hoster te zoeken (of ik zet het op één van m'n Forge servers)

[Chris7]

Als je geen SSH toegang hebt dan heb je /vendor inderdaad wel nodig, maar node_modules niet. Je kan de CSS en JS lokaal compileren en die dan mee committen. Ik doe dat voor sommige projecten omdat het deployen makkelijker maakt. Je hoeft dan niet in je CI te builden en dan de artifacts weer ergens heen sturen, of op je productie server Node te draaien. Een deploy is dan in feite een git pull en composer install. Een nadeel is wel dat je per ongeluk een niet-geoptimaliseerde build van CSS/JS kan committen.

[PatrickH89]

Chris7 schreef op dinsdag 8 september 2020 @ 15:02:
Als je geen SSH toegang hebt dan heb je /vendor inderdaad wel nodig, maar node_modules niet. Je kan de CSS en JS lokaal compileren en die dan mee committen. Ik doe dat voor sommige projecten omdat het deployen makkelijker maakt. Je hoeft dan niet in je CI te builden en dan de artifacts weer ergens heen sturen, of op je productie server Node te draaien. Een deploy is dan in feite een git pull en composer install. Een nadeel is wel dat je per ongeluk een niet-geoptimaliseerde build van CSS/JS kan committen.

Beter is dan een release te laten voorbereiden op je CI/CD platform zodat er gewoon ergens een zip geüpload en gedeployed kan worden dan. Het build proces draait alle commands die je nodig hebt (composer install, npm install, npm run production etc.) zodat je geen SSH toegang hoeft te hebben. Github, Bitbucket en Gitlab hebben allemaal en manier om te builden tegenwoordig, naast legio andere CI/CD tools.

[Postman]

Aangezien ik toch niet zo ver was de keuze gemaakt om te beginnen met de nieuwe Laravel 8 en Jetstream en kijken of ik die (zonder te worden) om kan zetten naar Bootstrap 4. Op die manier zou ik wel gebruik kunnen maken van de nieuwe back-end, en ook mijn huidige front-end makkelijk kunnen ondersteunen.

Over het deployen naar shared host: dat van de node_modules wist ik niet, goede tip. En ik ben inderdaad van plan het de volgende keer via een zip bestand te doen en deze dan op de server (via een PHP script ) uit te pakken en alles goed te zetten. Scheelt allicht in de tijd want al die kleine meuk via FTP gaat traag

offtopic:
Weet iemand nog een goede hosting die wel SSH heeft? Ik ben nu bij one.com en betaal daar eigenlijk vrij weinig voor best aardig wat, behalve dan de SSH. Iets meer per maand is geen probleem, mits het vergelijkbare specs zijn met toevoeging van SSH dus. Al gekeken en wat bijv. TransIP en Antagonist aanbieden is meteen fors duurder en ook minder qua hoeveelheid opslag/dataverbruik. Zelfs de irritante Strato kost een vermogen voor bijna niets.

[scosec]

Postman schreef op dinsdag 8 september 2020 @ 19:10:
Aangezien ik toch niet zo ver was de keuze gemaakt om te beginnen met de nieuwe Laravel 8 en Jetstream en kijken of ik die (zonder te worden) om kan zetten naar Bootstrap 4. Op die manier zou ik wel gebruik kunnen maken van de nieuwe back-end, en ook mijn huidige front-end makkelijk kunnen ondersteunen.

Over het deployen naar shared host: dat van de node_modules wist ik niet, goede tip. En ik ben inderdaad van plan het de volgende keer via een zip bestand te doen en deze dan op de server (via een PHP script ) uit te pakken en alles goed te zetten. Scheelt allicht in de tijd want al die kleine meuk via FTP gaat traag

offtopic:
Weet iemand nog een goede hosting die wel SSH heeft? Ik ben nu bij one.com en betaal daar eigenlijk vrij weinig voor best aardig wat, behalve dan de SSH. Iets meer per maand is geen probleem, mits het vergelijkbare specs zijn met toevoeging van SSH dus. Al gekeken en wat bijv. TransIP en Antagonist aanbieden is meteen fors duurder en ook minder qua hoeveelheid opslag/dataverbruik. Zelfs de irritante Strato kost een vermogen voor bijna niets.

Ik zit zelf bij neostrada. Tot op heden erg tevreden over. Goede snelheid en werkt met cpanel.

[Postman]

Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

[PainkillA]

Postman schreef op dinsdag 8 september 2020 @ 23:44:
Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

laravel blijft in heel veel opzichten nog in de startup fase, een super degelijk upgrade beleid met backwards compatibility promise zoals symfony dat wel heeft is enorm belangrijk voor professionele omgevingen.

Waar je bij symfony 6 maanden van tevoren al de aankomende wijzigingen weet en alvast deprecated calls makkelijk kan detecteren en wijzigen wordt er bij laravel een nieuwe versie over de schutting gegooid en moet je maar lekker de upgrade guide gaan doorspitten en alles aanpassen en hopen dat er niets is vergeten door team laravel.

Verder is laravel vooral bezig met flashy trendy features te bouwen ipv echt belangrijke zaken toe te voegen/wijzigen. Code architectuur komt bij laravel op plek 99, prio 1 is dat groene junior developers/of hobbyisten die nog nooit in php hebben gewerkt een (draak van een) applicatie moeten kunnen bouwen die doet wat het moet doen.

[Postman]

PainkillA schreef op woensdag 9 september 2020 @ 08:39:
laravel blijft in heel veel opzichten nog in de startup fase, een super degelijk upgrade beleid met backwards compatibility promise zoals symfony dat wel heeft is enorm belangrijk voor professionele omgevingen.

Waar je bij symfony 6 maanden van tevoren al de aankomende wijzigingen weet en alvast deprecated calls makkelijk kan detecteren en wijzigen wordt er bij laravel een nieuwe versie over de schutting gegooid en moet je maar lekker de upgrade guide gaan doorspitten en alles aanpassen en hopen dat er niets is vergeten door team laravel.

Verder is laravel vooral bezig met flashy trendy features te bouwen ipv echt belangrijke zaken toe te voegen/wijzigen. Code architectuur komt bij laravel op plek 99, prio 1 is dat groene junior developers/of hobbyisten die nog nooit in php hebben gewerkt een (draak van een) applicatie moeten kunnen bouwen die doet wat het moet doen.

Begin dat nu ook te merken en ik val eigenlijk voor Laravel onder de categorie groene junior developers.
Zie ook dat veel van Laravel op Symfony leunt, vraag me af of het in mijn geval niet beter zou zijn om daar wat tijd in te investeren en heel Laravel te laten varen.

Wat ik het meest storende vind is dat er sowieso breaking changes zijn (nog los van het ontbreken van uitleg hoe aan te passen of een omweg te gebruiken) en dat veel van die breaking changes niet eens gecommuniceerd worden. Nee die moet je maar tijdens productie ervaren.

Voor mij zit de kracht van Laravel in de simpele out of the box registratie, login en authenticatie en autorisatie. Als ik dat met bijvoorbeeld Symfony ook kan bereiken dan zou dat voor mij een oplossing zijn (Yii2 schijnt daar ook erg goed in te zijn, maar het is redelijk niche dus weinig tutorial te vinden).

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 23:44:
Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

De laravel/ui package werkt nog gewoon, je moet er alleen een namespace omheen zetten, als je geen default route namespace meer hebt. (Staat ook in het issue)

PainkillA schreef op woensdag 9 september 2020 @ 08:39:
[...]


laravel blijft in heel veel opzichten nog in de startup fase, een super degelijk upgrade beleid met backwards compatibility promise zoals symfony dat wel heeft is enorm belangrijk voor professionele omgevingen.

Waar je bij symfony 6 maanden van tevoren al de aankomende wijzigingen weet en alvast deprecated calls makkelijk kan detecteren en wijzigen wordt er bij laravel een nieuwe versie over de schutting gegooid en moet je maar lekker de upgrade guide gaan doorspitten en alles aanpassen en hopen dat er niets is vergeten door team laravel.

Verder is laravel vooral bezig met flashy trendy features te bouwen ipv echt belangrijke zaken toe te voegen/wijzigen. Code architectuur komt bij laravel op plek 99, prio 1 is dat groene junior developers/of hobbyisten die nog nooit in php hebben gewerkt een (draak van een) applicatie moeten kunnen bouwen die doet wat het moet doen.

Voor bestaande applicaties verandert er niks. Het enige dat veranderd is, is dat in NIEUWE applicaties de default namespace is weggehaald. In oude applicaties KAN je dat ook doen als je wil (kon eerst ook al). Als je dat doet moet je wel de oude Auth routes in een Route group zetten met die middleware inderdaad.

Daarnaast gaat dit om het opzetten van boilerplate code, niet het framework zelf. Je kan gewoon nog steeds laravel/ui gebruiken. Je kan ook de nieuws presets gebruiken, of gewoon je code zelf schrijven. En als laravel/ui straks niet meer werkt dan wordt er echt wel een community fork gemaakt (of je doet dat zelf).

[Postman]

Er is meer mis, waar zijn de controllers bijvoorbeeld gebleven? Worden wel netjes vermeld in de documentatie, echter in Jetstream bestaan ze totaal niet meer.

This command should be used on fresh applications and will install a layout view, registration and login views, as well as routes for all authentication end-points. A HomeController will also be generated to handle post-login requests to your application's dashboard.

[Barryvdh]

Postman schreef op woensdag 9 september 2020 @ 13:37:
Er is meer mis, waar zijn de controllers bijvoorbeeld gebleven? Worden wel netjes vermeld in de documentatie, echter in Jetstream bestaan ze totaal niet meer.

[...]

Met JetStream heb ik geen ervaring, maar zoals ik begreep zouden ze in je App/Http moeten gekopieerd moeten worden.

Voor laravel/ui heb ik een Pull Request ingediend om hem standaard te laten werken met Laravel 8: https://github.com/laravel/ui/pull/143

Edit: Ik heb het even bekeken, maar ze komen uit Fortify. Zie https://github.com/larave.../1.x/src/Http/Controllers
De templates worden wel gekopieerd zodat je ze kan aanpassen.

[ Voor 15% gewijzigd door Barryvdh op 09-09-2020 14:07 ]

[Chris7]

PatrickH89 schreef op dinsdag 8 september 2020 @ 16:20:
[...]
Beter is dan een release te laten voorbereiden op je CI/CD platform zodat er gewoon ergens een zip geüpload en gedeployed kan worden dan. Het build proces draait alle commands die je nodig hebt (composer install, npm install, npm run production etc.) zodat je geen SSH toegang hoeft te hebben. Github, Bitbucket en Gitlab hebben allemaal en manier om te builden tegenwoordig, naast legio andere CI/CD tools.

Ja, maar dan moet je dus een build ergens uploaden en daar vandaan kunnen deployen. Voor kleinere projecten vind ik het een prima oplossing om gecompileerde dependencies in te checken in Git. Bij een deploy hoef je dan alleen een bepaalde branch van git te pullen (met bijvoorbeeld Forge kan dat wel automatisch, de CI pingt Forge om z'n deploy script uit te voeren).

[PatrickH89]

Chris7 schreef op woensdag 9 september 2020 @ 15:04:
[...]


Ja, maar dan moet je dus een build ergens uploaden en daar vandaan kunnen deployen. Voor kleinere projecten vind ik het een prima oplossing om gecompileerde dependencies in te checken in Git. Bij een deploy hoef je dan alleen een bepaalde branch van git te pullen (met bijvoorbeeld Forge kan dat wel automatisch, de CI pingt Forge om z'n deploy script uit te voeren).

Je kunt een build tool als Github Actions, Bitbucket Pipelines etc ook gewoon laten deployen in plaats van die upload tussenstap. Ik snap dat het de eerste keer gedoe is om op te zetten, maar ik zou het kleinste project wat er bestaat niet meer op die manier deployen (echt waardeloos om zo'n vervuilde git repo te hebben). Er is natuurlijk op zich niet zoveel mis mee voor kleinere projecten, maar ik vind de workflow met CI/CD tool een stuk fijner.

[Saven]

amphora schreef op dinsdag 8 september 2020 @ 13:20:
[...]

Voor composer install moet je wel SSH toegang hebben, en dat heeft hij niet (shared hosting).
Ik bouw ook regelmatig kleinere sites met Laravel maar als de klant alleen een FTP account aanlevert ga ik ze toch echt proberen te overtuigen om een andere hoster te zoeken (of ik zet het op één van m'n Forge servers)

Commerciële pro tip: vraag gewoon 2 a 3 tientjes per maand aan je klanten voor hosting en knal 'm op een eigen vpsje. Geen gezeik, alles in eigen beheer, en backup automatisch in te stellen. Easy peasy. Makkelijk te verkopen ook hoor.

Als een klant wel betaalt voor een Laravel app maar niet fatsoenlijke hosting wil betalen lijkt me het sowieso geen fijne klant. Maar dat terzijde

[Barryvdh]

Postman schreef op dinsdag 8 september 2020 @ 23:44:
Altijd leuk hidden changes: https://github.com/laravel/ui/issues/138
Ik wou dus in Laravel 8 een nieuw project starten met de oude UI --auth oplossing. Dit werkt dus niet. Lijkt dus dat ze al heel UI deprecated hebben in favor van Jetstream (en zeg dus maar dag tegen Bootstrap).

Wat een bagger ontwikkelaars zeg...

Ondertussen is versie 3.0 van laravel/ui uit met support voor Laravel 8: https://github.com/laravel/ui/releases/tag/v3.0.0

[Postman]

Barryvdh schreef op zaterdag 12 september 2020 @ 09:13:
[...]


Ondertussen is versie 3.0 van laravel/ui uit met support voor Laravel 8: https://github.com/laravel/ui/releases/tag/v3.0.0

Zag jouw bijdrage en de versie 3 inderdaad voorbij komen. Bedankt daarvoor.

Ik ga vandaag een begin maken met het omzetten van Jetstream (met Livewire) naar Bootstrap. Nog even kijken hoe ik dit het beste op GitHub kan plaatsen, het mooiste zou een auto build zijn maar dat gaat ver boven mijn kennis. Dus waarschijnlijk wordt het iets van een overschrijving van de blade bestanden.

Want hoewel UI nu weer werkt heb je grote kans dat het over 6 maanden opnieuw kapot gaat en als je ziet hoe bereid ze nu al waren om een nieuwe build te maken dan vrees ik dat het 2021 echt einde oefening is.

Uiteindelijk kost het mij nu wat meer tijd, maar hoop dat die tijd zich in de toekomst terug zal verdienen (plus ik heb geen echte noodzaak want het blog project was nog in ontwikkeling en min of meer hobby).

[Hiroj]

Postman schreef op zaterdag 12 september 2020 @ 10:27:
[...]

Zag jouw bijdrage en de versie 3 inderdaad voorbij komen. Bedankt daarvoor.

Ik ga vandaag een begin maken met het omzetten van Jetstream (met Livewire) naar Bootstrap. Nog even kijken hoe ik dit het beste op GitHub kan plaatsen, het mooiste zou een auto build zijn maar dat gaat ver boven mijn kennis. Dus waarschijnlijk wordt het iets van een overschrijving van de blade bestanden.

Want hoewel UI nu weer werkt heb je grote kans dat het over 6 maanden opnieuw kapot gaat en als je ziet hoe bereid ze nu al waren om een nieuwe build te maken dan vrees ik dat het 2021 echt einde oefening is.

Uiteindelijk kost het mij nu wat meer tijd, maar hoop dat die tijd zich in de toekomst terug zal verdienen (plus ik heb geen echte noodzaak want het blog project was nog in ontwikkeling en min of meer hobby).

Waarom denk jij dat Laravel in 2021 einde oefening kan zijn door de recente ontwikkelingen, waardoor (beginnende) programmeurs zich ook makkelijker op het framework kunnen richten?

Als een meer ervaren programmeur (lees meer dan 10 jaar ervaring) heb ik daar weinig moeite mee. Een framework zoals Laravel zorgt er tenminste voor dat de code overdraagbaar kan zijn naar andere ontwikkelaars toe.

[Barryvdh]

Hiroj schreef op maandag 14 september 2020 @ 11:39:
[...]


Waarom denk jij dat Laravel in 2021 einde oefening kan zijn door de recente ontwikkelingen, waardoor (beginnende) programmeurs zich ook makkelijker op het framework kunnen richten?

Als een meer ervaren programmeur (lees meer dan 10 jaar ervaring) heb ik daar weinig moeite mee. Een framework zoals Laravel zorgt er tenminste voor dat de code overdraagbaar kan zijn naar andere ontwikkelaars toe.

Ik denk dat hij bedoelt dat laravel/ui einde oefening is. Wat opzich niet heel raar zou zijn, aangezien Taylor en co aangegeven hebben dat ze laravel/ui niet meer zien als 'de goede oplossing', maar jetstream prefereren. Zie bijv. de reactie van Taylor hier hier: https://www.reddit.com/r/...ctions_to_jetstream_here/

Dat gezegd hebbende, ze zijn wel bijgedraaid met support voor Laravel 8 en het is even de vraag hoe Jetstream uitpakt in de praktijk. Wat mij betreft hebben ze gelijk over laravel/ui en React/Vue scaffolding, maar is de 'plain php' scaffolding soms nog wel handig.

[Hiroj]

Barryvdh schreef op maandag 14 september 2020 @ 12:54:
[...]


Ik denk dat hij bedoelt dat laravel/ui einde oefening is. Wat opzich niet heel raar zou zijn, aangezien Taylor en co aangegeven hebben dat ze laravel/ui niet meer zien als 'de goede oplossing', maar jetstream prefereren. Zie bijv. de reactie van Taylor hier hier: https://www.reddit.com/r/...ctions_to_jetstream_here/

Dat gezegd hebbende, ze zijn wel bijgedraaid met support voor Laravel 8 en het is even de vraag hoe Jetstream uitpakt in de praktijk. Wat mij betreft hebben ze gelijk over laravel/ui en React/Vue scaffolding, maar is de 'plain php' scaffolding soms nog wel handig.

Als dat zo is, dan kan hij best wel eens gelijk hebben ja. Maar goed, laravel/ui gebruik ik eigenlijk nauwelijks. Zie liever een pakket komen Laravel/auth zoiets, waarmee je enkel de scaffolding krijgt voor user management.

Alles na die stap in 95% van alle gevallen bij mijn klanten zijn maatwerk.

[Barryvdh]

Hiroj schreef op maandag 14 september 2020 @ 13:28:
[...]


Als dat zo is, dan kan hij best wel eens gelijk hebben ja. Maar goed, laravel/ui gebruik ik eigenlijk nauwelijks. Zie liever een pakket komen Laravel/auth zoiets, waarmee je enkel de scaffolding krijgt voor user management.

Alles na die stap in 95% van alle gevallen bij mijn klanten zijn maatwerk.

Ja opzich was laravel/ui met de standaard bootstrap scaffolding ook niet veel meer als login+register in de bootstrap divjes.

[Postman]

Hiroj schreef op maandag 14 september 2020 @ 11:39:
Waarom denk jij dat Laravel in 2021 einde oefening kan zijn door de recente ontwikkelingen, waardoor (beginnende) programmeurs zich ook makkelijker op het framework kunnen richten?

Inderdaad zoals @Barryvdh al aangeeft bedoel ik dat in 2021 de support voor Laravel/UI zal stoppen.

Dat gezegd hebbende, ze zijn wel bijgedraaid met support voor Laravel 8 en het is even de vraag hoe Jetstream uitpakt in de praktijk. Wat mij betreft hebben ze gelijk over laravel/ui en React/Vue scaffolding, maar is de 'plain php' scaffolding soms nog wel handig.

Ja opzich was laravel/ui met de standaard bootstrap scaffolding ook niet veel meer als login+register in de bootstrap divjes.

Precies dat mis ik nu in de Jetstream optie. Al zou het een optie zijn om niets aan CSS/JS te kiezen zou het al helpen. Aangezien je nu compleet overstelpt wordt met Tailwind is het niet makkelijk hier weer Bootstrap van te maken.
Nu kon je argumenteren dat je vroeger gedwongen werd om met Bootstrap of Vue te werken, nu wordt opeens Tailwind door je strot geduwd.

Het grote nadeel van Tailwind vind ik dat de HTML code totaal onleesbaar is in development. Er zullen vast voordelen zijn, ik zie ze nog niet.

[Hiroj]

Postman schreef op maandag 14 september 2020 @ 16:54:
[...]

Inderdaad zoals @Barryvdh al aangeeft bedoel ik dat in 2021 de support voor Laravel/UI zal stoppen.


[...]


[...]

Precies dat mis ik nu in de Jetstream optie. Al zou het een optie zijn om niets aan CSS/JS te kiezen zou het al helpen. Aangezien je nu compleet overstelpt wordt met Tailwind is het niet makkelijk hier weer Bootstrap van te maken.
Nu kon je argumenteren dat je vroeger gedwongen werd om met Bootstrap of Vue te werken, nu wordt opeens Tailwind door je strot geduwd.

Het grote nadeel van Tailwind vind ik dat de HTML code totaal onleesbaar is in development. Er zullen vast voordelen zijn, ik zie ze nog niet.

Zou het niet een idee zijn dat wij samen zo'n dergelijk pakket maken? Ik heb opgemerkt dat veel mensen hierover mopperen en behoefte hebben aan hetgeen wat wij hier ook bespreken.

[Barryvdh]

Hiroj schreef op dinsdag 15 september 2020 @ 10:09:
[...]


Zou het niet een idee zijn dat wij samen zo'n dergelijk pakket maken? Ik heb opgemerkt dat veel mensen hierover mopperen en behoefte hebben aan hetgeen wat wij hier ook bespreken.

Ja behalve dat laravel/ui dat is en ook nog gewoon werkt, dus voor mij niet perse de noodzaak om NU een alternatief te gaan ontwikkelen

[Chris7]

Postman schreef op maandag 14 september 2020 @ 16:54:
Het grote nadeel van Tailwind vind ik dat de HTML code totaal onleesbaar is in development. Er zullen vast voordelen zijn, ik zie ze nog niet.

Ik heb er onlangs hier in het topic wat over geschreven: Chris7 in "[PHP] Het grote Laravel topic"

Ik was eerst ook scepticus maar na Tailwind gebruikt te hebben is mijn mening erover snel gedraaid. Het nadeel van minder leesbare HTML weegt in mijn ogen niet op tegen de voordelen.

[HollowGamer]

Wat is best practice als je wilt upgraden naar Laravel 8 als je nogal wat extra packages hebt geïnstalleerd? Is er een checker die je kan gebruiken welke packages nog niet zijn bijgewerkt?

Spatie is altijd heel erg snel, maar ik twijfel een beetje over de andere. Opzicht niet erg, het hoeft niet direct en sta altijd open om een PR te maken wanneer nodig.

[Chris7]

HollowGamer schreef op woensdag 16 september 2020 @ 08:40:
Wat is best practice als je wilt upgraden naar Laravel 8 als je nogal wat extra packages hebt geïnstalleerd? Is er een checker die je kan gebruiken welke packages nog niet zijn bijgewerkt?

Spatie is altijd heel erg snel, maar ik twijfel een beetje over de andere. Opzicht niet erg, het hoeft niet direct en sta altijd open om een PR te maken wanneer nodig.

Laravel Shift heeft een upgrade checker voor packages, die werkt best goed. Net mijn require en require-dev blokken erin gegooid en hij herkent niet alle packages, maar dan blijven er een stuk minder over om handmatig te checken.

Je kan Laravel Shift ook gebruiken om automatisch je applicatie te upgraden. Bij de upgrade naar Laravel 7 een keer gebruikt en ik was er erg tevreden over, het bespaart toch best wat tijd voor erg weinig geld.

[Poinsy]

Hiroj schreef op maandag 14 september 2020 @ 13:28:
[...]


Als dat zo is, dan kan hij best wel eens gelijk hebben ja. Maar goed, laravel/ui gebruik ik eigenlijk nauwelijks. Zie liever een pakket komen Laravel/auth zoiets, waarmee je enkel de scaffolding krijgt voor user management.

Alles na die stap in 95% van alle gevallen bij mijn klanten zijn maatwerk.

De documentatie van Fortify is inmiddels geschreven lees ik net. Taylor geeft aan op Reddit dat Fortify dus eigenlijk de authentication logic is zonder de fronted templates e.d.

[Barryvdh]

Poinsy schreef op woensdag 16 september 2020 @ 11:24:
[...]


De documentatie van Fortify is inmiddels geschreven lees ik net. Taylor geeft aan op Reddit dat Fortify dus eigenlijk de authentication logic is zonder de fronted templates e.d.

Ja idd, dus eigenlijk zou je alleen laravel/ui hoeven te forken en aan te passen dat het Fortify gebruikt.

[Saven]

Ha, even iedereen weer wakker schoppen

Misschien is er een veel nettere oplossing voor wat ik had bedacht (en dus niet werkt). Ik wil eigenlijk eenzelfde route url hebben, waarbij op basis van de route parameters, een andere controller method wordt aangeroepen.

Voorbeeld:

PHP:

Route::get('/connect/{platform}/{module}', 'ConnectorController@platformA')
   ->where('platform', 'platformA')
   ->name('installer.a');

Route::get('/connect/{platform}/{module}', 'ConnectorController@platformB')
   ->where('platform', 'platformB')
   ->name('installer.b');

De reden hiervoor is dat ik $platform als 'route model' bind in de Controller, en dus dynamisch kan zijn. Maar de methods platformA en platformB verschillen in dit geval zodanig van logica dat het imo logischer is om twee verschillende methods te gebruiken.

Maar Laravel ziet de eerste route niet Alleen de tweede route is aan te roepen.

Een workaround zou zijn door met URL segments te werken, maar dat vind ik dan weer minder sjiek. Moet ik zelf het model inladen enzo.

Misschien heeft iemand anders een best practice c.q. betere oplossing dan wat ik heb bedacht met de url segments?

[Cartman!]

Saven schreef op dinsdag 29 september 2020 @ 15:34:
Misschien heeft iemand anders een best practice c.q. betere oplossing dan wat ik heb bedacht met de url segments?

Je wil nu logica oplossen in je routes; dat vind ik niet logisch. Ik zou die platform uitlezen in je controller en dan in je controller een service aanroepen die op basis van waarde A of B iets gaat doen.

Overigens, als je t perse met routes wilt doen, waarom maak je er dan een variabele van, dan kun je net zo goed het platform hardcoden in je route.

[ Voor 14% gewijzigd door Cartman! op 29-09-2020 16:22 ]

[Postman]

Eindelijk een begin gemaakt aan mijn conversie van Jetstream Livewire naar Bootstrap 4. Ik heb er voor gekozen om gebruik te blijven maken van de Livewire calls en componenten, en dus wel alle CSS om te zetten naar Bootstrap (waar mogelijk).

Tot op heden alleen de login & registratie pagina gedaan. Zal wel even duren voor ik alle componenten heb omgezet, ook omdat het niet altijd direct via Bootstrap op te lossen is (er blijft custom CSS nodig).

Of het überhaupt een voordeel heeft wat ik nu aan het doen ben begin ik ook een beetje te betwijfelen, maar het zorgt er in ieder geval voor dat ik geen dependency meer heb op Tailwind (hoewel ik daar ook geen referentie naar zie/zag, wel iets van AlpineJS?).

De GitHub is publiek onder https://github.com/fullslackdev/jetstream_bootstrap. Het zijn nog 3 losse mappen daarin, uiteindelijk ga ik een refactor doen en naar alleen 1 map (de bootstrap variant). Maar voor nu is het om de 3 versies te kunnen vergelijken.

[-DarkShadow-]

Laravel dependency injection zou toch op ieder object moeten werken?

Ik gebruik Spatie's Queueable Actions en die probeer ik te gebruiken met DI.

Mijn actie is als volgt, dus DI via de constructor:

PHP:

class SyncSomethingAction
{
    use QueueableAction;
    protected $service;

    public function __construct(Service $service) {
        $this->service = $service;
    }

    public function execute(int $arg)
    {
        ...

Die roep ik als volgt aan vanuit een andere actie:

PHP:

(new SyncSometingAction)->onQueue()->execute(1);

Hierbij krijg ik terug van PHP dat het argument voor de constructor van SyncSomethingAction ontbreekt. Dus DI werkt niet. Ik heb al enkele bekende services gebruikt die zeker zouden moeten werken, maar ook daarbij krijg ik dezelfde Exception. Wat mis ik?

[ Voor 198% gewijzigd door -DarkShadow- op 05-10-2020 14:28 ]

[PatrickH89]

Als je handmatig de class instantieert kan de container dat natuurlijk niet voor je doen

De Service kun je bij een controller (of andere service) laten injecten om die vervolgens zelf door te geven aan je SyncSomethingAction.

[ Voor 43% gewijzigd door PatrickH89 op 05-10-2020 21:12 ]

[Barryvdh]

Ja of je kan hem via de App container direct laten resolven:

code:

app(SyncSometingAction::class)->onQueue()->execute(1)

[ Voor 9% gewijzigd door Barryvdh op 05-10-2020 22:25 ]

[PatrickH89]

Barryvdh schreef op maandag 5 oktober 2020 @ 22:24:
Ja of je kan hem via de App container direct laten resolven:

code:

app(SyncSometingAction::class)->onQueue()->execute(1)

Dit kan absoluut, maar meestal als je een call als deze 'nodig' hebt klopt er iets niet met je structuur. Laravel heeft een krachtige IoC container, het zou jammer zijn om die aan te roepen dmv een Service Locator.

[-DarkShadow-]

PatrickH89 schreef op dinsdag 6 oktober 2020 @ 10:00:
[...]


Dit kan absoluut, maar meestal als je een call als deze 'nodig' hebt klopt er iets niet met je structuur. Laravel heeft een krachtige IoC container, het zou jammer zijn om die aan te roepen dmv een Service Locator.

Ik gebruik momenteel de "Beyond CRUD" architectuur van Spatie, maar dit is dan wel een flinke hiaat in de architectuur. Indien onQueue wordt gebruikt, wordt de service geresolved door de queue. Maar indien je de actie direct gebruikt, loop je tegen dit probleem aan.

[basvaningen]

Als "Vue" beginner blijf ik een beetje worstelen met authenticatie en zie dat de meeste tutorials onvolledig zijn of gewoonweg niet werken.
Ik heb nu deze tutorial gevolgd en dit werkt op 1 ding na. Misschien dat jullie mij kunnen helpen.

https://blog.codecourse.c...-authentication-with-vue/

Het probleem is dat als je ingelogd bent en je laat de pagina open laat staan je cookie verloopt na een X periode. Echter blijf ik wel ingelogd in de Vue app, maar zie ik wel in de console dat als er data opgehaald moet worden je "not authorized" bent.
Wat is in deze situatie volgens jullie de "best practice" om dit te checken. In de VueX store wordt al wel de user state opgeslagen, maar ik ben nog niet zover kwa kennis om te zien of dat ook goed en realtime (reactive) gebeurd in deze tutorial.

Alvast bedankt voor jullie hulp!!

[patricks8]

basvaningen schreef op vrijdag 23 oktober 2020 @ 09:01:
Als "Vue" beginner blijf ik een beetje worstelen met authenticatie en zie dat de meeste tutorials onvolledig zijn of gewoonweg niet werken.
Ik heb nu deze tutorial gevolgd en dit werkt op 1 ding na. Misschien dat jullie mij kunnen helpen.

https://blog.codecourse.c...-authentication-with-vue/

Het probleem is dat als je ingelogd bent en je laat de pagina open laat staan je cookie verloopt na een X periode. Echter blijf ik wel ingelogd in de Vue app, maar zie ik wel in de console dat als er data opgehaald moet worden je "not authorized" bent.
Wat is in deze situatie volgens jullie de "best practice" om dit te checken. In de VueX store wordt al wel de user state opgeslagen, maar ik ben nog niet zover kwa kennis om te zien of dat ook goed en realtime (reactive) gebeurd in deze tutorial.

Alvast bedankt voor jullie hulp!!

Waar je heel goed naar moet kijken zijn de Session domains en stateful domains die je kan zetten in je .env van je Laravel backend. Dat probleem heb ik namelijk gehad dat deze niet goed geconfigureerd waren. Daardoor lukt inloggen wel, maar elke volgende request een 403.

[basvaningen]

Ik zie net dat ik een apart topic moet aanmaken voor mijn vraag. Heb dit zojuist gedaan. De mod mag dus het bericht van mij verwijderen.

[VUE + Laravel] Authenticatie

[ Voor 17% gewijzigd door basvaningen op 23-10-2020 12:08 ]

[Barryvdh]

Hiroj schreef op maandag 31 augustus 2020 @ 13:00:
[...]

Ik heb wel een leuk project waarmee ik eens goed TailwindCSS en Livewire kan uitproberen. Ben benieuwd wat ik er uiteindelijk van ga vinden.

En hoe bevalt Livewire? Ik heb ook wat ge-experimenteerd met Livewire en tot nu toe bevalt het wel. Voor een eigen project en en nu ook voor een onderdeel op een klant project. Ook een stukje over geschreven: https://barryvdh.nl/larav...ar-with-laravel-livewire/

Blijft even wennen maar soms is het wel erg makkelijk om gewoon een PHP functie aan te roepen vanuit Javascript, of een event af te vuren vanuit PHP en op te vangen met Javascript

[llevering]

Barryvdh schreef op dinsdag 27 oktober 2020 @ 17:02:
[...]


En hoe bevalt Livewire? Ik heb ook wat ge-experimenteerd met Livewire en tot nu toe bevalt het wel. Voor een eigen project en en nu ook voor een onderdeel op een klant project. Ook een stukje over geschreven: https://barryvdh.nl/larav...ar-with-laravel-livewire/

Blijft even wennen maar soms is het wel erg makkelijk om gewoon een PHP functie aan te roepen vanuit Javascript, of een event af te vuren vanuit PHP en op te vangen met Javascript

Ik zag je blog voorbij komen, erg leuk om te zien, wat net een paar uur daarvoor had ik gedacht: 'Hoe zou Livewire wrappen om Fullcalendar'. Nog geen concreet use-case voor, maar ik gebruik het in veel projecten, dus dat komt vanzelf voorbij.

[Hiroj]

Barryvdh schreef op dinsdag 27 oktober 2020 @ 17:02:
[...]


En hoe bevalt Livewire? Ik heb ook wat ge-experimenteerd met Livewire en tot nu toe bevalt het wel. Voor een eigen project en en nu ook voor een onderdeel op een klant project. Ook een stukje over geschreven: https://barryvdh.nl/larav...ar-with-laravel-livewire/

Blijft even wennen maar soms is het wel erg makkelijk om gewoon een PHP functie aan te roepen vanuit Javascript, of een event af te vuren vanuit PHP en op te vangen met Javascript

Ik heb het uitgeprobeerd bij een nieuw project. Tot nu toe ben ik wel erg te spreken over de mogelijkheden ermee, maar zodra ik meerdere css klasses moet togglen ben ik wel eventjes zoet...

TailwindCSS bevalt mij daarentegen echt verrassend goed. Ik heb nu wel onwijs veel componenten in mijn code, maar als je weet bij welke je moet zijn dan gaat het hartstikke goed komen

[Thandruil]

Wij zijn sinds een week of twee ook bezig geweest met het in kaart brengen of Livewire een goede toevoeging in ons project kan zijn. Nu is het een Laravel+GraphQL+React app, maar waar we vooral tegenaan liepen was de hoeveelheid boilerplate code (mutations en queries schrijven) en het de tijd die het kost voor het bedenken van een logische API.

Nu met Livewire hebben we in korte tijd een groot deel van de app kunnen schrijven. Zelfs het herschrijven van een aantal dynamische UI components in Alpine viel eigenlijk alleen maar mee. Enige wat ik tot nu toe mis is dat de Livewire app niet echt een "pagina state" bijhoudt, zelfs met Turbolinks. Zo is het lastig om de state van bijvoorbeeld een inklapbaar menu tussen page loads bij te houden.

[Hiroj]

Thandruil schreef op zondag 1 november 2020 @ 23:14:
Wij zijn sinds een week of twee ook bezig geweest met het in kaart brengen of Livewire een goede toevoeging in ons project kan zijn. Nu is het een Laravel+GraphQL+React app, maar waar we vooral tegenaan liepen was de hoeveelheid boilerplate code (mutations en queries schrijven) en het de tijd die het kost voor het bedenken van een logische API.

Nu met Livewire hebben we in korte tijd een groot deel van de app kunnen schrijven. Zelfs het herschrijven van een aantal dynamische UI components in Alpine viel eigenlijk alleen maar mee. Enige wat ik tot nu toe mis is dat de Livewire app niet echt een "pagina state" bijhoudt, zelfs met Turbolinks. Zo is het lastig om de state van bijvoorbeeld een inklapbaar menu tussen page loads bij te houden.

Zou je dat niet met een sessie kunnen oplossen? Beetje out-of-the-box denkend hoor. Als je een menu openklapt, kun je prima in de PHP code een methode aanspreken die zowel het uitklappen als het plaatsen van een sessie waarde kan verzorgen.

Bij iedere page load check je vervolgens of die sessie waarde dan bestaat.

[Nonstop365]

Thandruil schreef op zondag 1 november 2020 @ 23:14:
Wij zijn sinds een week of twee ook bezig geweest met het in kaart brengen of Livewire een goede toevoeging in ons project kan zijn. Nu is het een Laravel+GraphQL+React app, maar waar we vooral tegenaan liepen was de hoeveelheid boilerplate code (mutations en queries schrijven) en het de tijd die het kost voor het bedenken van een logische API.

Nu met Livewire hebben we in korte tijd een groot deel van de app kunnen schrijven. Zelfs het herschrijven van een aantal dynamische UI components in Alpine viel eigenlijk alleen maar mee. Enige wat ik tot nu toe mis is dat de Livewire app niet echt een "pagina state" bijhoudt, zelfs met Turbolinks. Zo is het lastig om de state van bijvoorbeeld een inklapbaar menu tussen page loads bij te houden.

Is dit niet de oplossing?
https://laravel-livewire.com/docs/2.x/query-string

[Barryvdh]

Ik denk dat hij bedoeld buiten het component om, dus als je wisselt van het ene naar andere component. Met turbolinks zou dat goed moeten gaan zolang je menu buiten je content container zit toch?

[Thandruil]

Barryvdh schreef op donderdag 5 november 2020 @ 09:25:
Ik denk dat hij bedoeld buiten het component om, dus als je wisselt van het ene naar andere component. Met turbolinks zou dat goed moeten gaan zolang je menu buiten je content container zit toch?

Ja, precies. Livewire components zelf werken sowieso, de DOM wordt enkel van de component vervangen. Maar Turbolinks vervangt wel de gehele <body> inhoud, dus bij het navigeren van routes.

[Hiroj]

Barryvdh schreef op dinsdag 27 oktober 2020 @ 17:02:
[...]


En hoe bevalt Livewire? Ik heb ook wat ge-experimenteerd met Livewire en tot nu toe bevalt het wel. Voor een eigen project en en nu ook voor een onderdeel op een klant project. Ook een stukje over geschreven: https://barryvdh.nl/larav...ar-with-laravel-livewire/

Blijft even wennen maar soms is het wel erg makkelijk om gewoon een PHP functie aan te roepen vanuit Javascript, of een event af te vuren vanuit PHP en op te vangen met Javascript

Hoe bevalt Livewire je nu? Ik ben er inmiddels weer redelijk vanaf gestapt, omdat ik bepaalde belangrijke elementen mis. Zoals het kunnen plaatsen van slots en eigenlijk kon ik een hoop niet zonder AlpineJS doen, wat ook weer zijn eigen beperkingen kent...

Daarom ben ik toch maar weer teruggegaan naar VueJS

[Barryvdh]

Hiroj schreef op donderdag 12 november 2020 @ 10:02:
[...]

Hoe bevalt Livewire je nu? Ik ben er inmiddels weer redelijk vanaf gestapt, omdat ik bepaalde belangrijke elementen mis. Zoals het kunnen plaatsen van slots en eigenlijk kon ik een hoop niet zonder AlpineJS doen, wat ook weer zijn eigen beperkingen kent...

Daarom ben ik toch maar weer teruggegaan naar VueJS

Voor het ene project waar ik heb gebruik (intern CRM) bevalt het eigenlijk best goed, vooral voor kleine acties vanuit javascript (event droppen/verslepen in de calendar, lijst herladen als user/project veranderd, refresh knopje, actie aan knop hangen etc). Werkt ook gewoon snel zolang je niks spannends doet in die acties en de rest queued.
Alleen ben ik nog niet zo'n held in het nesten, waardoor sommige Livewire components wat groter worden en minder makkelijk beheersbaar (met update/add arrays etc). Al zou je dat ook prima moeten kunnen opsplitsen weer.

[-DarkShadow-]

Hiroj schreef op donderdag 12 november 2020 @ 10:02:
[...]
Daarom ben ik toch maar weer teruggegaan naar VueJS

Heb je Inertia al geprobeerd? Werkt perfect hier.

[Saven]

Barryvdh schreef op donderdag 12 november 2020 @ 10:42:
[...]

Voor het ene project waar ik heb gebruik (intern CRM) bevalt het eigenlijk best goed, vooral voor kleine acties vanuit javascript (event droppen/verslepen in de calendar, lijst herladen als user/project veranderd, refresh knopje, actie aan knop hangen etc). Werkt ook gewoon snel zolang je niks spannends doet in die acties en de rest queued.
Alleen ben ik nog niet zo'n held in het nesten, waardoor sommige Livewire components wat groter worden en minder makkelijk beheersbaar (met update/add arrays etc). Al zou je dat ook prima moeten kunnen opsplitsen weer.

Als ik ouderwets mag doen, en het gaat om maar heel weinig fancy-ness (lees: maar om 1 of 2 functies die je live wil refreshen) dan zou je ook nog gewoon Jquery kunnen overwegen met wat AJAX calls . Als je je hele applicatie een SPA wil maken is het een ander verhaal.

Jammer dat er niet echt een Nederlandse community bestaat die zich op Laravel richt. Maar we zijn dan ook maar een klein land

Toch gooi ik 't hier even in de groep. Ben gewoon benieuwd of jullie dit anders zouden aanpakken of niet. Bijvoorbeeld met interfaces / Service Containers etc. Alleen zit je dan weer te auwehoeren met het ophalen van benodigde gegevens.

Kort verhaal. Ik heb een aantal API Clients, en daaromheen een abstractielaag. Afhankelijk van het platform van een bedrijf, wil ik de wrapper API Client instantiëren.

De meest concrete vraag: is het OK om dit vanuit het Module model te doen met een getApiClient() method? Die method is niet direct verwant aan het model en doet niks met de database an sich. Het is wel makkelijk en imo redelijk 'simple but not stupid'

Stukje semi real world code met uitleg embedded. Het lijkt meer dan het is door alle comments en newlines

PHP:

<?php

class Company extends Model
{
    /**
     * Company can have multiple different modules..
     * Email marketing, CRM, Statistics, etc.
     */
    public function modules()
    {
        return $this->belongsToMany(Module::class);
    }

    /**
     * Get single module from this company based on module's name
     * Every company module has a settings table with common config fields.
     * Like API credentials for that module
     */
    public function module($name)
    {
        return $this->belongsToMany(Module::class)
            ->with(['settings' => function ($query)
            {
                $query->where('company_id', $this->id);
                $query->limit(1);
            }])
            ->where('name', $name);
    }
}

class Module extends Model
{
    /**
     * A module can belong to many companies through a pivot table (company_module)
     */
    public function companies()
    {
        return $this->belongsToMany(Company::class)->withPivot('module_id');
    }

    /**
     * Each module has a settings record,
     * but it belongs to the combination of a module_id and company_id
     */
    public function settings()
    {
        return $this->hasOne(Settings::class);
    }

    /**
     * Creates a new instance for the API Client wrapper for company platform
     * E.g. Mailchimp has a different client than Hubspot or Sendgrid or whatever.
     * This wrapper is an abstraction layer
     */
    public function getApiClient(Settings $settings)
    {
        //$settings->platform could be Mailchimp for example..
        $apiClient = '\App\ApiClients\\'.ucfirst($settings->platform).'\Client';

        return new $apiClient($this, $settings);
    }
}

class SubscriberController extends Controller
{
    private Module $companyModule;

    private Settings $moduleSettings;

    /**
     * Just an example, get the module information for this controller
     */
    public function __construct(Company $company)
    {
        // Get the Mail Marketing module and it's settings for this company
        $this->companyModule = $company->module('mailmarketing')->firstOrFail();
        $this->moduleSettings = $this->companyModule->settings;
    }

    /**
     * View a list of all subscribers
     */
    public function view(Request $request)
    {
        $apiClient = $this->companyModule->getApiClient( $this->moduleSettings );

        $subscribers = $apiClient->getAllSubscribers();

        return view('modules.subscribers.view', [
            'subscribers' => $subscribers
        ]);
    }
}

[Thandruil]

Saven schreef op donderdag 18 februari 2021 @ 14:56:
[...]
Als ik ouderwets mag doen, en het gaat om maar heel weinig fancy-ness (lees: maar om 1 of 2 functies die je live wil refreshen) dan zou je ook nog gewoon Jquery kunnen overwegen met wat AJAX calls . Als je je hele applicatie een SPA wil maken is het een ander verhaal.

Maar het "probleem" is dat je dan een API moet bedenken, implementeren en onderhouden. De USP van Livewire is dat je dat dus niet meer hoeft te doen.

Saven schreef op donderdag 18 februari 2021 @ 14:56:
Jammer dat er niet echt een Nederlandse community bestaat die zich op Laravel richt. Maar we zijn dan ook maar een klein land

Er is een Laravel Discord server, niet specifiek Nederlands, maar toch. https://discord.gg/BCXvv7mP

Saven schreef op donderdag 18 februari 2021 @ 14:56:
De meest concrete vraag: is het OK om dit vanuit het Module model te doen met een getApiClient() method? Die method is niet direct verwant aan het model en doet niks met de database an sich. Het is wel makkelijk en imo redelijk 'simple but not stupid'

Volgens het Separation of Controls Concerns principe zou Module zich niet bezig houden met het maken van een ApiClient instance. Dat kan je "oplossen" door een Factory pattern te gebruiken.

[ Voor 0% gewijzigd door Thandruil op 18-02-2021 16:18 . Reden: typfout ]

[Barryvdh]

Saven schreef op donderdag 18 februari 2021 @ 14:56:
[...]

Jammer dat er niet echt een Nederlandse community bestaat die zich op Laravel richt. Maar we zijn dan ook maar een klein land

Er is wel een LaraBene Slack groep, en een phpnl Slack group met een Laravel channel.

[HollowGamer]

Barryvdh schreef op donderdag 18 februari 2021 @ 19:10:
[...]


Er is wel een LaraBene Slack groep, en een phpnl Slack group met een Laravel channel.

Tja, wat is ook de toegevoegde waarde van Nederlandse communities? Voor meetings vind ik het wel leuk (liever kleinschalig), maar iedereen in de IT spreekt vrijwel Engels en vaak leer je meer op een platform als Github dan in je eigen kleine kring.

[Hiroj]

Barryvdh schreef op donderdag 18 februari 2021 @ 19:10:
[...]


Er is wel een LaraBene Slack groep, en een phpnl Slack group met een Laravel channel.

Dat vind ik wel leuk om waar te nemen, weet je waar ik mijzelf voor die slack groups kan inschrijven?

[Barryvdh]

Hiroj schreef op vrijdag 19 februari 2021 @ 12:20:
[...]

Dat vind ik wel leuk om waar te nemen, weet je waar ik mijzelf voor die slack groups kan inschrijven?

https://larabene.com/gids/slack
https://phpnl.nl/

[Saven]

Thandruil schreef op donderdag 18 februari 2021 @ 15:51:
[...]

Maar het "probleem" is dat je dan een API moet bedenken, implementeren en onderhouden. De USP van Livewire is dat je dat dus niet meer hoeft te doen.

True. Persoonlijk zou ik dan denk ik eerder voor Vue kiezen omdat dat wat breder gebruikt wordt. Maar ik heb met beide geen ervaring (staat op de planning), dus misschien is Livewire wel veel makkelijker

Thandruil schreef op donderdag 18 februari 2021 @ 15:51:
[...]

Volgens het Separation of Controls Concerns principe zou Module zich niet bezig houden met het maken van een ApiClient instance. Dat kan je "oplossen" door een Factory pattern te gebruiken.

Ja ook zeker waar. Zat ik al even naar te kijken, net als naar Registry pattern

Ik vond dit op zich wel een goed voorbeeld: http://rizqi.id/laravel-registry-pattern

Het is alleen dat heel veel gegevens uiteindelijk terugvloeien uit een aantal url segments/parameters.

Bijvoorbeeld dit:

https://applicatie.com/<companyID>/subscribers/overview

Dan zou je een ServiceProvider schrijven die op basis van de {comapany} parameter, en url segment(2) bepaalt welke factory wordt ingeladen. Vervolgens moet je op basis van die url parameters weer de module data, en module settings data ophalen en die meegeven bij het instantiëren van de class in de ServiceProvider.

In de model is alles eigenlijk al aanwezig

Anyway, wat stof om over na te denken. Bedankt voor je suggestie iig

[ Voor 3% gewijzigd door Saven op 20-02-2021 11:38 ]

[Barryvdh]

Wel interessant voor sommigen wellicht: https://twitter.com/LaraconOnline/status/1372250802882977792



Laravel Octane is een tool die ervoor zorgt dat Laravel ipv Nginx/FPM via Roadrunner (een Go applicatie) of Swoole (PHP extensie) kan draaien. Dat kan nu ook al met 3rd party libraries, maar nu dus met support in Laravel zelf, wat het meer production-ready moet maken. Beta wordt verwacht over enkele weken.

[Koen Hendriks]

Laravel Octane ziet er zeer belovend uit, de performance is echt indrukwekkend.

[kwaakvaak_v2]

Octane is wel koel, en zoals Taylor zelf ook al aangaf meer een project omdat het kan, en niet omdat het moet.

Neemt niet weg dat zeker wel nut heeft, het kan mogelijk de subtiele trap zijn die PHP naar een wat meer statefull platform kan stuwen. Alhoewel, elke request een volledig nieuwe omgeving ook zo zijn voordelen. Minder kans op vage memory leaks enzo.

[Barryvdh]

kwaakvaak_v2 schreef op zondag 21 maart 2021 @ 14:06:
Octane is wel koel, en zoals Taylor zelf ook al aangaf meer een project omdat het kan, en niet omdat het moet.

Neemt niet weg dat zeker wel nut heeft, het kan mogelijk de subtiele trap zijn die PHP naar een wat meer statefull platform kan stuwen. Alhoewel, elke request een volledig nieuwe omgeving ook zo zijn voordelen. Minder kans op vage memory leaks enzo.

Ja volgens mij gaf hij ook aan dat mensen er een beetje bang voor zijn, en met goede support vanuit Laravel het wel goed zou moeten zijn. Memory leaks zijn opzich ook geen ramp, want je http workers kunnen ook herstarten als ze over hun geheugen limiet heen gaan, net als de queue workers, die in principe op dezelfde manier werken al.

[-DarkShadow-]

Octane ziet er gaaf uit. PHP-PM stond nog op mijn lijstje om een keer uit te proberen, maar dat wordt dan Octane waarschijnlijk :-)

[Barryvdh]

-DarkShadow- schreef op maandag 29 maart 2021 @ 16:40:
Octane ziet er gaaf uit. PHP-PM stond nog op mijn lijstje om een keer uit te proberen, maar dat wordt dan Octane waarschijnlijk :-)

Staat online als beta nu https://github.com/laravel/octane

[Koen Hendriks]

Awesome! Minimaal php 8.0 zal wel flinke instap zijn voor bestaande projecten.

[Barryvdh]

Koen Hendriks schreef op dinsdag 6 april 2021 @ 20:21:
Awesome! Minimaal php 8.0 zal wel flinke instap zijn voor bestaande projecten.

Denk dat je ook niet zomaar bestaande projecten er in moet gooien, en sowieso zal het even duren voordat het 'productie-ready' is. Maar heb even geprobeerd, met Roadrunner ging het best makkelijk.

[Koen Hendriks]

Barryvdh schreef op dinsdag 6 april 2021 @ 20:48:
[...]

Denk dat je ook niet zomaar bestaande projecten er in moet gooien, en sowieso zal het even duren voordat het 'productie-ready' is. Maar heb even geprobeerd, met Roadrunner ging het best makkelijk.

Ik ben ook aan het proberen om het op te zetten, maar ik blijf met een dependency error zitten met Roadrunner.

code:

  Problem 1
    - spiral/roadrunner v2.0.0 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-RC.1 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-RC.3 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-RC.4 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-beta.21 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-beta.22 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-beta.24 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-beta11 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-beta12 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-beta13 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.0-beta19 requires spiral/roadrunner-worker >=2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.1 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.2 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.2-beta.1 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.2-beta.2 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.3 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.0.4 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner v2.1.0-beta.1 requires spiral/roadrunner-worker ^2.0 -> satisfiable by spiral/roadrunner-worker[v2.0.0, v2.0.1, v2.0.2, v2.0.3].
    - spiral/roadrunner-worker v2.0.3 requires composer-runtime-api ^2.0 -> no matching package found.
    - spiral/roadrunner-worker v2.0.2 requires composer-runtime-api ^2.0 -> no matching package found.
    - spiral/roadrunner-worker v2.0.1 requires composer-runtime-api ^2.0 -> no matching package found.
    - spiral/roadrunner-worker v2.0.0 requires composer-runtime-api ^2.0 -> no matching package found.
    - Installation request for spiral/roadrunner ^2.0 -> satisfiable by spiral/roadrunner[v2.0.0, v2.0.0-RC.1, v2.0.0-RC.3, v2.0.0-RC.4, v2.0.0-beta.21, v2.0.0-beta.22, v2.0.0-beta.24, v2.0.0-beta11, v2.0.0-beta12, v2.0.0-beta13, v2.0.0-beta19, v2.0.1, v2.0.2, v2.0.2-beta.1, v2.0.2-beta.2, v2.0.3, v2.0.4, v2.1.0-beta.1].

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
 - It's a private package and you forgot to add a custom repository to find it

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Dit terwijl ik gewoon een zo goed als nieuwe kale Laravel 8 applicatie heb opgesteld en lokaal PHP 8 gebruik:

code:

PHP 8.0.3 (cli) (built: Mar  4 2021 20:42:56) ( NTS )

Ik heb mijn stability ook op beta gezet voor Octane

code:

    "minimum-stability": "beta"

Dit zijn mijn huidige dependencies in mijn composer.json:

code:

"require": {
        "php": "^7.3|^8.0",
        "fideloper/proxy": "^4.4",
        "fruitcake/laravel-cors": "^2.0",
        "guzzlehttp/guzzle": "^7.0.1",
        "laravel/framework": "^8.12",
        "laravel/octane": "^0.1.0",
        "laravel/tinker": "^2.5",
        "spiral/roadrunner": "^2.0"
    },
    "require-dev": {
        "facade/ignition": "^2.5",
        "fakerphp/faker": "^1.9.1",
        "laravel/sail": "^1.0.1",
        "mockery/mockery": "^1.4.2",
        "nunomaduro/collision": "^5.0",
        "phpunit/phpunit": "^9.3.3"
    },

[Barryvdh]

Koen Hendriks schreef op woensdag 7 april 2021 @ 16:12:
[...]


Ik ben ook aan het proberen om het op te zetten, maar ik blijf met een dependency error zitten met Roadrunner.

Heb je wel Composer 2? Of nog versie 1? Volgens mij heb je 2 nodig voor Octane. En beta is niet nodig, ik zou gewoon stable houden.

[Koen Hendriks]

Barryvdh schreef op woensdag 7 april 2021 @ 16:15:
[...]


Heb je wel Composer 2? Of nog versie 1? Volgens mij heb je 2 nodig voor Octane. En beta is niet nodig, ik zou gewoon stable houden.

Ik las echt precies net jouw zelfde antwoord wat je op de github issues pagina had gegeven haha. Composer 2 lost het inderdaad op.

[Koen Hendriks]

Klopt het dat de Octane server stopt als er syntax errors zijn? Dat maakt het niet ideaal voor debuggen namelijk.

code:

    INFO  Server running…

   Local: http://0.0.0.0:8000

   Use Ctrl+C to stop the server

   200    GET / ...................................................... 111.96 ms

    ParseError

   syntax error, unexpected token "function", expecting ")"

   at routes/web.php:21
      17▕     return view('welcome');
      18▕ });
      19▕
      20▕
   ➜  21▕ Route::get('/test/' function () {
      22▕  phpinfo();
      23▕ });
      24▕
testproject exited with code 1

[ Voor 129% gewijzigd door Koen Hendriks op 09-04-2021 13:26 ]

[Barryvdh]

Koen Hendriks schreef op vrijdag 9 april 2021 @ 13:12:
Klopt het dat de Octane server stopt als er syntax errors zijn? Dat maakt het niet ideaal voor debuggen namelijk.

code:

    INFO  Server running…

   Local: http://0.0.0.0:8000

   Use Ctrl+C to stop the server

   200    GET / ...................................................... 111.96 ms

    ParseError

   syntax error, unexpected token "function", expecting ")"

   at routes/web.php:21
      17▕     return view('welcome');
      18▕ });
      19▕
      20▕
   ➜  21▕ Route::get('/test/' function () {
      22▕  phpinfo();
      23▕ });
      24▕
testproject exited with code 1

Ik zou zeggen maak een issue Het is niet voor niks in beta nu.

Edit: even getest maar het gaat in principe volgens mij alleen fout als je een syntax error maakt in bestanden die nodig zijn voor Octane zelf. De routes worden ingeladen op dat moment inderdaad dus met een error kan je niet verder. Maar als je gewoon controllers hebt en daar een error in maakt, is dat geen probleem.

[ Voor 16% gewijzigd door Barryvdh op 09-04-2021 15:26 ]

[Koen Hendriks]

ah kijk dat wel logisch dan. Wil ook nog in de Octane optimised routes duiken, schijnt nog best wat performance te winnen daar.

Wil liever zelf altijd ergens goed induiken voor ik een issue aanmaak haha

[Koen Hendriks]

@Barryvdh Maak jij ook al gebruik van Sail? Normaal had ik altijd mijn eigen docker files maar met een nieuw project ben ik nu Sail aan het gebruiken. Opzich werkt het prima maar ik loop nu tegen de issue aan dat ik geen libXrender heb... Ik zie ook geen manier in de docs om de docker uit te breiden...


Whoops weer iets te vroeg gepost, met

code:

sail artisan sail:publish

krijg je gewoon toegang tot de Dockerfile waarin je libXrender kunt instaleren.

[ Voor 19% gewijzigd door Koen Hendriks op 20-04-2021 15:47 ]

[HollowGamer]

Iemand die hier Octane al heeft draaien? Ik wil het een kans geven, maar ik twijfel of het wel zin heeft bij een website die je enkel lokaal voor jezelf host.

Waarom ik het dan toch wil proberen.. waarom niet?
Gewoon om meer te leren hoe het werkt.

[ Voor 10% gewijzigd door HollowGamer op 05-06-2021 13:58 ]

[Thandruil]

HollowGamer schreef op zaterdag 5 juni 2021 @ 13:58:
Iemand die hier Octane al heeft draaien? Ik wil het een kans geven, maar ik twijfel of het wel zin heeft bij een website die je enkel lokaal voor jezelf host.

Waarom ik het dan toch wil proberen.. waarom niet?
Gewoon om meer te leren hoe het werkt.

Ten eerste, als je het wilt leren dan is het zeker waard om het te proberen. Maar ik denk niet dat het écht nut heeft om op een persoonlijke site te draaien. De extra complexiteit van het draaien van Octane weegt in mijn ogen niet op tegen de voordelen er van voor deze specifieke case.

[HollowGamer]

Ik heb voor het eerst een Laravel package gemaakt dankzij Spatie's laravel-package-tools!

Het valt mij erg op, dat je al heel snel kijkt naar Spatie hiervoor, maar misschien zie ik iets over het hoofd?
Voor mijn gevoel leer je enorm veel door naar hun packages te kijken en die min of meer te kopiëren (structuur, indeling, classes, etc.). Met die laravel-package-tools heb je enorm veel hooks, wat super werkt bij het registreren van service providers bijvoorbeeld.

Zou iemand geïnteresseerd zijn om het even de code reviewen en/of eventueel testen?
Het is geen groot pakket, maar ik sta heel graag open voor feedback en tips!

Als ik daarvoor een eigen topic moet aanmaken, dan hoor ik het graag.

-------

Ander nieuws: https://laravel-news.com/livewire-v3-features

Persoonlijk kijk ik hier erg naar uit! Het begint steeds meer Vue te lijken (geen React ervaring).

Zo zijn straks components twee-weg communiceerbaar en is Alpine meer geïntegreerd. Na een tijdje te hebben gespeeld met Alpine, begin ik het steeds leuker te vinden.

Of ik Vue voorgoed vaarwel zou zeggen.. denk het niet. Vue heeft leuke frameworks, werkt fijn met een API en persoonlijk heb ik dat liever gescheiden i.p.v. een grote bundel. Maar je hebt met Livewire wel ontzettend snel iets opgebouwd en met V3 wordt het nog gemakkelijker/uitgebreider.

[Barryvdh]

HollowGamer schreef op zaterdag 24 september 2022 @ 17:30:
Ik heb voor het eerst een Laravel package gemaakt dankzij Spatie's laravel-package-tools!

Het valt mij erg op, dat je al heel snel kijkt naar Spatie hiervoor, maar misschien zie ik iets over het hoofd?
Voor mijn gevoel leer je enorm veel door naar hun packages te kijken en die min of meer te kopiëren (structuur, indeling, classes, etc.). Met die laravel-package-tools heb je enorm veel hooks, wat super werkt bij het registreren van service providers bijvoorbeeld.

Zou iemand geïnteresseerd zijn om het even de code reviewen en/of eventueel testen?
Het is geen groot pakket, maar ik sta heel graag open voor feedback en tips!

Als ik daarvoor een eigen topic moet aanmaken, dan hoor ik het graag.

Ik zou zeggen, post hier je package

[HollowGamer]

--kan-weg--

[ Voor 96% gewijzigd door HollowGamer op 08-05-2023 17:32 ]

[Ultimation]

Ik ben onlangs van baan gewisseld en daar werken ze met Laravel. Ik heb al 9+ jaar ervaring met php, maar niet eerder Laravel of een ander framework volledig gebruikt. Wel losse onderdelen uit dergelijke frameworks gebruikt zoals het Doctrine ORM, DI containers en routers. Ook ben ik bekend met allerlei architecturen en what not.

Die kennis wil ik graag op niveau brengen via een (online) cursus. Ik heb die van Global Training, Edu Vision, Koening-Solutions, Spiral Train en udemy gevonden.

Een hoop van deze curussen bieden fundamentals aan die ik nagenoeg kan overslaan, maar het is lauter bedoeld om 't allemaal een keer aan te raken zonder altijd maar die docs erbij te moeten pakken. Ook wil ik er iets dieper op in gaan dan de "Hello World" van Laravel zelf.

Ik vroeg mij af of jullie nog ervaring hebben met deze aanbieders en misschien nog tips hebben m.b.t. dergelijke cursussen.

[ Voor 15% gewijzigd door Ultimation op 08-05-2023 17:21 ]

[HollowGamer]

@Ultimation Laracast, en gewoon kijken naar Laravel Boilerplates op GitHub.

[Koen Hendriks]

@Ultimation Mijn eerste ingeving was ook Laracast. Dat is echt specifiek voor het framework en daar kan je ook geavanceerde lessen doen en de basics makkelijk skippen.

[Groax]

@Ultimation Probeer eens een CRUD te maken met je favoriete series of wat je ook leuk vind en bouw daar op door.

Laracast is zeker een goeie om een abonnement op te nemen.

[Chris7]

+1 voor Laracasts, beste resource voor Laravel en daaraan gerelateerde tools. Link

Laracasts heeft ook veel gratis video's, zeker voor beginners dus dan kun je makkelijk kijken of het wat voor je is.

[Ultimation]

Ik ga met de Laracast aan de gang! Dank allemaal voor de input. Ik had er compleet overeen gekeken.

[Marc3l]

@Ultimation zou inderdaad ook starten op Laracast. Mocht je je daarna nog vervelen

Laravel Daily (https://laraveldaily.com/) en Spatie (https://spatie.be/courses) hebben ook nog cursussen.
Laravel Daily heeft ook een Youtube kanaal met bijna elke dag wel een tutorial, https://www.youtube.com/@LaravelDaily

[CodeBaker]

Hallo, ik ben bezig met een shopify store op te zetten, hier wil ik een laravel applicatie aan koppelen doormiddels van API calls de order op te halen in de applicatie, nu zijn er ook er ook bepaalde orders die niet uit eigen productie komen. Deze orders wil ik weer doorzetten naar de desbetreffende producent. Kan ik dit het beste met een observer doen? alvast bedankt.

[Marc3l]

CodeBaker schreef op woensdag 10 mei 2023 @ 15:44:
Hallo, ik ben bezig met een shopify store op te zetten, hier wil ik een laravel applicatie aan koppelen doormiddels van API calls de order op te halen in de applicatie, nu zijn er ook er ook bepaalde orders die niet uit eigen productie komen. Deze orders wil ik weer doorzetten naar de desbetreffende producent. Kan ik dit het beste met een observer doen? alvast bedankt.

Er zijn denk ik verschillende manieren, het zou met een observer kunnen.
Of in de API call bij het ophalen van de orders.

Ik weet niet hoe je code/API eruit ziet. Moet je eerste loopen over alle orders?
Zo ja, je zou dan in die loop ook een check kunnen maken als het een order uit niet eigen productie is en daarvoor een job inschieten (https://laravel.com/docs/10.x/queues#creating-jobs). In die job de order naar de desbetreffende producent sturen. Voordeel van een job is als de API van een producent bijvoorbeeld offline is dat je automatisch een nieuwe poging kan doen na x tijd.

[CodeBaker]

@Marc3l Ik loop eerst over alle orders heen. Zoals je noemt een check erin bouwen en vervolgens in een job doen lijkt me een goede oplossing! bedankt.

[HollowGamer]

https://livewire.laravel.com/docs/volt

Ik moet zeggen dat ik nogal onder de indruk ben van de stappen die Livewire met V3 heeft gezet. Ook iets als Filament werkt erg top, en er zou al een bèta zijn om de nieuwe Livewire te ondersteunen.

Het wordt wel meer VueJS, maar dan in PHP. Beetje mixed, omdat ik altijd een API en frontend apart bouw, maar met een SPA kun je tegenwoordig ook gewoon een PWA aan hangen, zodat het werkt als een app. Jammer alleen dat de grote twee (iOS en Android) het nog niet toestaan in hun stores.

Maar erg top en gelukkig toont het dus overeenkomsten met andere frameworks.

[amphora]

HollowGamer schreef op donderdag 27 juli 2023 @ 21:39:
https://livewire.laravel.com/docs/volt

Ik moet zeggen dat ik nogal onder de indruk ben van de stappen die Livewire met V3 heeft gezet. Ook iets als Filament werkt erg top, en er zou al een bèta zijn om de nieuwe Livewire te ondersteunen.

Het wordt wel meer VueJS, maar dan in PHP. Beetje mixed, omdat ik altijd een API en frontend apart bouw, maar met een SPA kun je tegenwoordig ook gewoon een PWA aan hangen, zodat het werkt als een app. Jammer alleen dat de grote twee (iOS en Android) het nog niet toestaan in hun stores.

Maar erg top en gelukkig toont het dus overeenkomsten met andere frameworks.

Ik was al fan van Livewire en v3 nu helemaal, wire:navigate is echt geniaal...
Volt is ook zeker interessant, maar veel 'haat' uit de dev wereld omdat alles in één file zou zitten, separation of concern zit diep bij sommigen, zelf heb ik dat wel losgelaten.

[ Voor 10% gewijzigd door amphora op 28-07-2023 09:33 ]

[HollowGamer]

amphora schreef op vrijdag 28 juli 2023 @ 09:29:
[...]

Ik was al fan van Livewire en v3 nu helemaal, wire:navigate is echt geniaal...
Volt is ook zeker interessant, maar veel 'haat' uit de dev wereld omdat alles in één file zou zitten, separation of concern zit diep bij sommigen, zelf heb ik dat wel losgelaten.

Je moet voor de grap eens naar /r/PHP gaan, daar is Laravel zelfs gebanned lol. Maar goed dat heb je ook in de sub /r/Linux, denk dat die mensen het te serieus nemen en weinig bijdragen aan het product uiteindelijk.

Maar ik ben het met je eens. Ik doe niets anders met Vue en composables, wat gewoon goed werkt.

[Koen Hendriks]

HollowGamer schreef op vrijdag 28 juli 2023 @ 10:58:
[...]

Je moet voor de grap eens naar /r/PHP gaan, daar is Laravel zelfs gebanned lol. Maar goed dat heb je ook in de sub /r/Linux, denk dat die mensen het te serieus nemen en weinig bijdragen aan het product uiteindelijk.

Maar ik ben het met je eens. Ik doe niets anders met Vue en composables, wat gewoon goed werkt.

Ik zie anders gewoon Laravel related posts op /r/php staan. Denk niet dat het helemaal klopt wat je zegt. https://www.reddit.com/r/..._herd_laravel_11_laravel/

Ik moet zelf nog beginnen met V3 maar het ziet er veel belovend uit. Ben erg voorstander van HTML over the wire en de vorige versies met veel plezier in projecten gebruikt.

[RobIII]

Modbreak:

Off-topic discussie en gesteggel verwijderd. Voor de duidelijkheid:

• Werving is ongewenst
• "Mail me" is ongewenst
• Sitechecks (en code-reviews daarmee ook) zijn ongewenst