Using Volt is a great way to build small, self-contained Livewire components. It's not designed for creating large components with lots of backend tasks. In the React world, Volt components are similar to server components. I really like it!
Great point! I look of Volt in a similar way where it allows me to scaffold out features as quickly as possible and break them up into smaller components, when needed. :) -Josh
Just one thing for the future... Always show the artisan commands... For example you didnt show the command to have a class based component, but you showed it when you switched to the non class based one. You also could show that the class doesnt have to be on the same blade file and can instead be on its own php file. It is a bit better to follow. Besides that you make awesome videos and you are a great addition to the Laravel world. Thank you
Thank you for the support and for the suggestion. I appreciate it and I'll try to improve that in the future to show everything instead of just after the fact. Hopefully it did come across in the beginning talking about how Livewire works that the class and the blade separated is the standard way of doing things within Livewire (without Volt). Thanks! :) -Josh
I love livewire (and vold)... but this functional approach is not for me. I mean how can you say this is readable: state([ 'some_var' => 'some_value' ]) echo $this->some_var; "$this" is suppose to represent an instance of a class in PHP. No class is represented in the code base. ... sure, my example did not enclose the call to "some_var" inside a function, but still...
Yeah, I agree with this. if instead of '$this' they could do '$state' or just use the variable itself could be better imo. Or if we are going on the react route, might as well do 'setSomeValue' already.
I just realized... Livewire probably reads thru the file and creates a class(then object) based on it's contents. It leaves everything inside the tags, so state could be a method to create properties for the class. Calling the properties with $this now makes sense. But still not readable. $state as an alternative or a stand-in to $this makes more sense with how the component is coded.
I personally prefer the Class approach myself. BUT for those unfamiliar with PHP or even class-based languages, the functional API might feel for familiar or readable. But, that's why we have options (even if you choose not to use Volt entirely). :) -Josh
@@LaravelPHP When we accepted Laravel as a framework, the goal was to write code that's clean & consistent (with some flexiblity as is the PHP way) . Right now there's just too many ways to do the same thing. The problem comes with hiring developers, they'll use every option avaliable. This is why too much choice is bad, sure you can enforce coding standards, but this is not always possible across multiple companies, so alas, back to spaghetti code in PHP. The thing we wanted to avoid since forever.
As a React dev learning Laravel, I appreciate having the option but given the limitations of tooling support for this, I'll probably rather use class components. The only thing I'm really missing is the power of Typescript.
Thanks for the great video! The functional api looks really slick. It's great what you're doing. One question - what's behind you on the wall in the three picture frames? I can't see everything.
@@AntoRex78 Yes, you can use reactive properties: state(['todos'])->reactive(); This will receive todos as a property from the parent and also the child will be updated when that change in the parent.
I would say so! Instead of having Livewire files that have logic and view in two separate files, you now have those two things colocated. And, you find yourself writing less controllers since a lot of the logic lives in the files themselves. -Josh
to me, it seems like the whole volt thing is kind of bucking the trend of MVC. i guess it has its use cases but it will quickly become spaghetti nightmare on a decently sized web app.
I think any coding structure has the ability to become spaghetti nightmare. But I do think that the benefit of Volt (like you mentioned) is the ability to scaffold out or quickly prototype a feature without having to do much work. Plus, it could be a great entry-path to folks coming from the JS world. :) -Josh
That's interesting, but the only problem I see is the tooling, there is no intellisene in blade files in vs code, I'm not willing to use it until the tooling gets better
I love this mindset. Thank YOU. I prefer the Class Volt style myself, and the flexibility we have in Laravel is a HUGE benefit. We can build awesome things no matter how our code structure looks or what tools we use on the front-end. :) -Josh
Only if we choose to write spaghetti code. But the benefit of Laravel is having the flexibility to choose whatever front-end works for the particular project we are working on at any given time. And if you just wanted to build one component in Volt where it might stay small, then you can do that too without changing the rest of your code structure. :) -Josh
First of all, I would like to thank Laravel and its entire team. Then, I would like to say that I love PHP and it will never die haha. I think it's a great idea to create your own packages to reuse them in other projects. Why not a store-style like Composer for classic components that are repeated each time with simple logic and easy implementation documentation that could speed up the creation of web applications! Now all that's left is to touch on mobile haha.
There is just a downside of using volt for vscode users. It does not have autocomplete for imports or intellisense. I think thats because as you are in a blade file and not a php file. This is the only reason i don't use SFC livewire.
Volt it's a great idea! Before we could have everything in one file but in the class and now also in the template, make sense. The functional syntax looks terrible though.
As someone who never used Livewire i wanna say it looks approachable because it reminds me of Vue that i use for every project. However i dont see the reason to use this instead of something like Inertia
I'm glad it looks approachable! I think that's the goal. To make a style like this seem easy to use for people who are used to Vue/React/Svelte. And it's not meant to replace Inertia by any means. Just another tool in the toolbelt. :) -Josh
Hey Josh! It's great to see you in the official Laravel channel. I have a question about single file components. I try to apply SOLID (mainly SRP) principles to my apps as best as I can. And I feel like putting logic into a component is kind of violating the Single Responsibility Principle. As far as I know, you need to put your resource methods (index, show, edit...) together, in the Controller file. Even though it's so cool to use Volt in simple apps like a todo list, I'm not sure how useful it would be in a more complex app. Am I wrong in thinking this way, or does this have a solution I'm not aware of? I'm not at all a professional in Laravel, these are just my opinions and things I've heard from tutorials and courses. I just wanted to hear some opinions on this.
I think the benefit of Volt in a more complex app is having to think critically of when and where to extract out functionality into separate components. Build things out in Blade/Alpine and only extract to Volt components when you need server interaction. Of course, you can still build apps with traditional MVC/Livewire and use a Volt component to prototype a feature. The possibilities are endless and the flexibility hasn't changed. :) (Also thank you for the support. Super happy to be here.) -Josh
This was excellent! My question, though, is how would SEO and site performance be affected against something like a laravel-inertia-vue app with ssr? Like anything seems like it has excellent use cases, but coming from that aforementioned stack, this seems very promising
This would all be Server rendered so no issues with SEO and site performance. There are some fun options within Livewire 3 for navigation helpers to try to achieve a SPA feel without being a full SPA. Overall, use what works for you and build beautiful things. :) -Josh
Nah I think is not only horrible but a shoot in the foot bad idea to have all in one file. Let's not become React Pls. We; PHP community should know better.
This is not really from react server components, everything started with svelte component. Vue copied it, then react followed. All in all, this is a better pattern.
I don't think it's trying to become like React, but rather giving more flexibility and options to how we build beautiful apps within the Laravel ecosystem. Some (like myself) might prefer the SFC approach while others love the MVC approach with or without traditional Livewire. :) -Josh
@LaravelPHP Fair point. I still think the SFC is inherently defective. I think if we take a look at some of the worst takes on JS land, it all comes from unnecessary optimization and an absurd quantity of syntactic sugar in which you have hundreds of approaches. Many of them sub-par. I personally think this is not innovation. Battle tested technology is labeled as boring because there are solid and proven reasons to adhere to simplicity and reliability. SFC, in my opinion, is bad takes. Once you're dealing with a non-trivial component, it becomes absurdly complicated and messy, which is why I favor separation of concerns SoC principles.
Nope. The web is in too good of a place to go back. But, I think the Single File Component piece is very appealing to folks coming from the JS ecosystem who are interested in checking out Laravel. The benefit of having a ton of flexibility with how we build amazing apps in the framework. :) -Josh
So if you're kinda fan of react, then you'll love this, I guess? But still, volt approach is just a syntactic sugar. Is laravel delving away from its MVC structure? Pfft
I don't think it's delving away at all. Rather expanding opportunities for people to learn and experience Laravel. The flexibility given within the framework has never been greater and for those coming from more of a SFC approach (React/Next, Vue/Nuxt, etc.), this might be a great option if you don't prefer to use MVC structure with Inertia. But use what makes sense for YOU and build beautiful things. :) -Josh
Good point. I probably should have clarified that like JavaScript folks might use Console.log to help debug as they go, DD helps do the same, even though it is not the same in how it works. -Josh
What if you need to store field value without waiting for all form to be filled then submit ? Single file with update method for specific field such as profile image makes sense
It depends on how you use it. It can definitely lead to bad discussions if you don’t encapsulate your components in a reusable fashion using patterns found in frontend frameworks like vue, react and svelte.
I think it could be a mess whether with traditional MVC/Livewire or with Volt. But the benefit comes down to the speed of prototyping features. :) You don't have to solely use Volt components in your application. It's why I think the flexibility of Laravel is a strong suit. -Josh
Volt is not there by default unless you consciously add it. I personally think it is unnecessary addition, but, no hate. Perhaps there are some cases suitable for this kind of approach--I just haven't encountered one so far in my personal work. The title is misleading and dangerous, though, especially for the newcomers. This is NOT modern index.php file. In fact this is how you write PHP apps, but there are a load of reason why you should seriously consider not write/organize your code like this, thus dudes came up with frameworks like Laravel with a certain patterns in place. Some of use have experienced working with this type of spaghetti since 2000s.
Laravel Breeze scaffolding does include Volt currently. It wasn’t my intention to say it replaced everything that Laravel gives you, but it does show there are a number of new approaches and Volt gives you options for DX if you like Livewire. :) -Josh
"This looks super real." - Um, because it's the same thing you had before, but not inside a class? That makes it real? That's... yeah I'm assuming you just misspoke because every interpretation of that sentence I can think of is unflattering.
I think you might have misheard me or I didn’t speak clearly. “This looks super readable.” I think Volt Functional API helps bridge the gap for people who have lived outside of the PHP or even OOP world for some time and, to most people, the functional API is more readable than class-based structure. - Josh
@@LaravelPHP Functional or procedural? Because if it's causing persistent state changes then I challenge that it's functional, because the functions aren't pure. (It's really common for people to confuse those terms.)
The Layout attribute would be added after the "new" keyword. Here's an example in the docs: livewire.laravel.com/docs/volt#class-based-volt-components Hope that helps. :)
Using Volt is a great way to build small, self-contained Livewire components. It's not designed for creating large components with lots of backend tasks. In the React world, Volt components are similar to server components. I really like it!
Great point! I look of Volt in a similar way where it allows me to scaffold out features as quickly as possible and break them up into smaller components, when needed. :)
-Josh
@@LaravelPHP I couldn't agree more!
Volt is a game changer, 1st day I used it I just got hooked
Same for me!
-Josh
Just one thing for the future...
Always show the artisan commands... For example you didnt show the command to have a class based component, but you showed it when you switched to the non class based one.
You also could show that the class doesnt have to be on the same blade file and can instead be on its own php file.
It is a bit better to follow. Besides that you make awesome videos and you are a great addition to the Laravel world.
Thank you
Thank you for the support and for the suggestion. I appreciate it and I'll try to improve that in the future to show everything instead of just after the fact.
Hopefully it did come across in the beginning talking about how Livewire works that the class and the blade separated is the standard way of doing things within Livewire (without Volt).
Thanks! :)
-Josh
I love livewire (and vold)... but this functional approach is not for me. I mean how can you say this is readable:
state([
'some_var' => 'some_value'
])
echo $this->some_var;
"$this" is suppose to represent an instance of a class in PHP. No class is represented in the code base.
... sure, my example did not enclose the call to "some_var" inside a function, but still...
I agree with you. The class approach make a lot more sense
Yeah, I agree with this. if instead of '$this' they could do '$state' or just use the variable itself could be better imo. Or if we are going on the react route, might as well do 'setSomeValue' already.
I just realized... Livewire probably reads thru the file and creates a class(then object) based on it's contents.
It leaves everything inside the tags, so state could be a method to create properties for the class.
Calling the properties with $this now makes sense. But still not readable.
$state as an alternative or a stand-in to $this makes more sense with how the component is coded.
I personally prefer the Class approach myself. BUT for those unfamiliar with PHP or even class-based languages, the functional API might feel for familiar or readable.
But, that's why we have options (even if you choose not to use Volt entirely). :)
-Josh
@@LaravelPHP When we accepted Laravel as a framework, the goal was to write code that's clean & consistent (with some flexiblity as is the PHP way) . Right now there's just too many ways to do the same thing. The problem comes with hiring developers, they'll use every option avaliable. This is why too much choice is bad, sure you can enforce coding standards, but this is not always possible across multiple companies, so alas, back to spaghetti code in PHP. The thing we wanted to avoid since forever.
As a React dev learning Laravel, I appreciate having the option but given the limitations of tooling support for this, I'll probably rather use class components. The only thing I'm really missing is the power of Typescript.
It's definitely something that we (Laravel and the community) are aware of. I definitely understand that. :)
-Josh
Thanks for the great video! The functional api looks really slick. It's great what you're doing.
One question - what's behind you on the wall in the three picture frames? I can't see everything.
Thanks for watching! :) Those posters are some of my personal mottos: "Create Consistently, Provide Value, Learn Out Loud."
-Josh
In the react components you can pass states as a props to the child components. Can we able to achieve same here in volt?
Yes you can, you can pass props to nested components.
@@Nat-ih9oe cool, child component will re-render if props updated?
@@AntoRex78 Yes, you can use reactive properties:
state(['todos'])->reactive();
This will receive todos as a property from the parent and also the child will be updated when that change in the parent.
I'm not a native english, what i understand is in simple term that "volt is an option for you to go out from the MVC idea when needed". Is that true?
I would say so! Instead of having Livewire files that have logic and view in two separate files, you now have those two things colocated. And, you find yourself writing less controllers since a lot of the logic lives in the files themselves.
-Josh
to me, it seems like the whole volt thing is kind of bucking the trend of MVC. i guess it has its use cases but it will quickly become spaghetti nightmare on a decently sized web app.
I think any coding structure has the ability to become spaghetti nightmare. But I do think that the benefit of Volt (like you mentioned) is the ability to scaffold out or quickly prototype a feature without having to do much work. Plus, it could be a great entry-path to folks coming from the JS world. :)
-Josh
That's interesting, but the only problem I see is the tooling, there is no intellisene in blade files in vs code, I'm not willing to use it until the tooling gets better
Nice guitars, sir.
Yeah this is good, some people maybe use it but I'm like the oldy way
I love this mindset. Thank YOU.
I prefer the Class Volt style myself, and the flexibility we have in Laravel is a HUGE benefit.
We can build awesome things no matter how our code structure looks or what tools we use on the front-end. :)
-Josh
Bringing spaghetti code back to the future !!
Only if we choose to write spaghetti code. But the benefit of Laravel is having the flexibility to choose whatever front-end works for the particular project we are working on at any given time.
And if you just wanted to build one component in Volt where it might stay small, then you can do that too without changing the rest of your code structure. :)
-Josh
@@LaravelPHP yeah absolutely, but the must efficient way to write spaghetti code is to have the freedom to do it.
Nan... this can go for a small project and not a sophisticated project. @josh can you make endpoint with this?
An API endpoint would still be handled in the Framework itself and wouldn't be how you would use Volt. :)
-Josh
First of all, I would like to thank Laravel and its entire team. Then, I would like to say that I love PHP and it will never die haha.
I think it's a great idea to create your own packages to reuse them in other projects. Why not a store-style like Composer for classic components that are repeated each time with simple logic and easy implementation documentation that could speed up the creation of web applications! Now all that's left is to touch on mobile haha.
There is just a downside of using volt for vscode users. It does not have autocomplete for imports or intellisense. I think thats because as you are in a blade file and not a php file. This is the only reason i don't use SFC livewire.
great video, I haven't played with volt enough yet looks very odd but kinda cool.
I love that mindset! It can be cool if you want to scaffold out a quick idea without committing to much in your code (one file). :)
-Josh
Volt it's a great idea! Before we could have everything in one file but in the class and now also in the template, make sense. The functional syntax looks terrible though.
I like the class syntax myself, but I know the functional syntax appeals to a lot of folks. It's great to have options. :)
-Josh
As someone who never used Livewire i wanna say it looks approachable because it reminds me of Vue that i use for every project. However i dont see the reason to use this instead of something like Inertia
I'm glad it looks approachable! I think that's the goal. To make a style like this seem easy to use for people who are used to Vue/React/Svelte.
And it's not meant to replace Inertia by any means. Just another tool in the toolbelt. :)
-Josh
@@LaravelPHP you guys really nailed it on that one I must say.
@@LaravelPHP and thank you all for your service. For making top class software that are free to use. You guys literally carry my career ❤️
Hey Josh! It's great to see you in the official Laravel channel. I have a question about single file components.
I try to apply SOLID (mainly SRP) principles to my apps as best as I can. And I feel like putting logic into a component is kind of violating the Single Responsibility Principle. As far as I know, you need to put your resource methods (index, show, edit...) together, in the Controller file. Even though it's so cool to use Volt in simple apps like a todo list, I'm not sure how useful it would be in a more complex app. Am I wrong in thinking this way, or does this have a solution I'm not aware of?
I'm not at all a professional in Laravel, these are just my opinions and things I've heard from tutorials and courses. I just wanted to hear some opinions on this.
I think the benefit of Volt in a more complex app is having to think critically of when and where to extract out functionality into separate components. Build things out in Blade/Alpine and only extract to Volt components when you need server interaction.
Of course, you can still build apps with traditional MVC/Livewire and use a Volt component to prototype a feature. The possibilities are endless and the flexibility hasn't changed. :)
(Also thank you for the support. Super happy to be here.)
-Josh
feels like Wordpress?
This was excellent! My question, though, is how would SEO and site performance be affected against something like a laravel-inertia-vue app with ssr? Like anything seems like it has excellent use cases, but coming from that aforementioned stack, this seems very promising
This would all be Server rendered so no issues with SEO and site performance. There are some fun options within Livewire 3 for navigation helpers to try to achieve a SPA feel without being a full SPA.
Overall, use what works for you and build beautiful things. :)
-Josh
I am using livewire volt but on the server is return 404 on the click event. can you please help me in this
Nah I think is not only horrible but a shoot in the foot bad idea to have all in one file. Let's not become React Pls. We; PHP community should know better.
Comming from Sveltekit, I really like this way 😇
This is not really from react server components, everything started with svelte component. Vue copied it, then react followed. All in all, this is a better pattern.
I don't think it's trying to become like React, but rather giving more flexibility and options to how we build beautiful apps within the Laravel ecosystem. Some (like myself) might prefer the SFC approach while others love the MVC approach with or without traditional Livewire. :)
-Josh
@LaravelPHP Fair point. I still think the SFC is inherently defective. I think if we take a look at some of the worst takes on JS land, it all comes from unnecessary optimization and an absurd quantity of syntactic sugar in which you have hundreds of approaches. Many of them sub-par. I personally think this is not innovation. Battle tested technology is labeled as boring because there are solid and proven reasons to adhere to simplicity and reliability. SFC, in my opinion, is bad takes. Once you're dealing with a non-trivial component, it becomes absurdly complicated and messy, which is why I favor separation of concerns SoC principles.
oh whatever, idealistic crap slows you down; freelance is a different game.
Are we going back to the Old School Web Development? 🤔
Nope. The web is in too good of a place to go back. But, I think the Single File Component piece is very appealing to folks coming from the JS ecosystem who are interested in checking out Laravel. The benefit of having a ton of flexibility with how we build amazing apps in the framework. :)
-Josh
I'm done when he wrote a class above a div
Essentially it is making Wordpress from Laravel
So if you're kinda fan of react, then you'll love this, I guess? But still, volt approach is just a syntactic sugar. Is laravel delving away from its MVC structure? Pfft
Think its just allowing people to stay with current trends, all the frameworks are tending to lean towards to same conventions.
Yes, 💯
I don't think it's delving away at all. Rather expanding opportunities for people to learn and experience Laravel. The flexibility given within the framework has never been greater and for those coming from more of a SFC approach (React/Next, Vue/Nuxt, etc.), this might be a great option if you don't prefer to use MVC structure with Inertia.
But use what makes sense for YOU and build beautiful things. :)
-Josh
Why all you guys use hats?? Is that a Pattern?
Baldness
That's a good question. 🤔
If you do not familiar with laravel dd stands for var_dump() and die; so it is not like console.log
Good point. I probably should have clarified that like JavaScript folks might use Console.log to help debug as they go, DD helps do the same, even though it is not the same in how it works.
-Josh
@@LaravelPHP
I am not a laravel developer but dd and dump just a fantastic tool it is like a orange lambo
@@LaravelPHP
console.log it just handy on browser when you use it in server you need to import util module and format things
nit for me bruh
Completely fine! I think that's why Laravel is so fantastic with having options for how we build amazing things. :)
-Josh
Not even impressed, I’d rather use Symfony
@@balodoc then use Symphony
single file for logic n view is always a bad idea very bad idea
agreeee
cringe
What if you need to store field value without waiting for all form to be filled then submit ? Single file with update method for specific field such as profile image makes sense
It depends on how you use it. It can definitely lead to bad discussions if you don’t encapsulate your components in a reusable fashion using patterns found in frontend frameworks like vue, react and svelte.
Imaging this mess in a big team 😂
I think it could be a mess whether with traditional MVC/Livewire or with Volt. But the benefit comes down to the speed of prototyping features. :)
You don't have to solely use Volt components in your application. It's why I think the flexibility of Laravel is a strong suit.
-Josh
Volt is not there by default unless you consciously add it. I personally think it is unnecessary addition, but, no hate. Perhaps there are some cases suitable for this kind of approach--I just haven't encountered one so far in my personal work. The title is misleading and dangerous, though, especially for the newcomers. This is NOT modern index.php file. In fact this is how you write PHP apps, but there are a load of reason why you should seriously consider not write/organize your code like this, thus dudes came up with frameworks like Laravel with a certain patterns in place. Some of use have experienced working with this type of spaghetti since 2000s.
Laravel Breeze scaffolding does include Volt currently. It wasn’t my intention to say it replaced everything that Laravel gives you, but it does show there are a number of new approaches and Volt gives you options for DX if you like Livewire. :)
-Josh
"This looks super real." - Um, because it's the same thing you had before, but not inside a class? That makes it real? That's... yeah I'm assuming you just misspoke because every interpretation of that sentence I can think of is unflattering.
I think you might have misheard me or I didn’t speak clearly. “This looks super readable.”
I think Volt Functional API helps bridge the gap for people who have lived outside of the PHP or even OOP world for some time and, to most people, the functional API is more readable than class-based structure.
- Josh
@@LaravelPHP Functional or procedural? Because if it's causing persistent state changes then I challenge that it's functional, because the functions aren't pure. (It's really common for people to confuse those terms.)
Very bad variable and function names. Makes this video uneeserily confusing. 😅
That's a great point. We will seek to make that more intentional in the future. :)
-Josh
😍😍😍
Make mysql free for php herd
I am having a challenge changing layout using class api. Someone help me, I am running out of coffee 😭
The Layout attribute would be added after the "new" keyword.
Here's an example in the docs: livewire.laravel.com/docs/volt#class-based-volt-components
Hope that helps. :)
First 😂😂
please make mysql free for laravel herd :(