I found out about these components recently when I've installed breeze for a small personal project. It wasn't clear at all what's the deal with them. It's clear now! thank you!
2 года назад
Hey, I am just falling love in your channel! I learn laravel now, and it is so difficult to me to find explanations of laravel features, that makes really sence! I don't need so much time to understand them! Thans man!
As far as I can understand, components are perfect in replacing "elements" (inputs, images, buttons, etc.) but are a complete mess when they replace "sections". I think, and of course I could be wrong, we should take a step back to extend sections and use components to replace elements.
Well, I guess it depends on the Component's responsibility, if it is a simple plain dumb Component, I guess it is ok to extract things like inputs, buttons, images, selections, etc with no structural markup in this kind of Component.
I implemented blade components/slots. Took a bit, but I got it done and working. HOWEVER, I decided to revert back to the original code due to a major issue: it was taking more 50-60mg of memory to display the blade. I spent multiple days trying to find why the memory went up, and found that once I reverted back to the original code I was able to decrease the memory usage by 50-60mg.. Holy cow!!!!!! One other issue, the code seemed to have gotten much more difficult for somebody to follow. This might be a personal issue, mine. I am bummed that I can't use this approach. I will revisit this if/when the components/slots are allowed to be compiled. It will be interesting to see the difference. However, THANK YOU for taking your time to create this video. It was a tremendous help for me to create the components/slots.
I've always used view partials that I pass an array to as a second parameter long before components came out. I use them virtually the same way (inputs, buttons, charts, modals, etc) but feel I have more flexibility (not to mention several large code bases with this already in place). I can pass any data I want to the view, including custom arrays without any weird IDE linting issues. I have the option to place the views wherever I want instead of a central components folder. And I feel it makes it clear "something dynamic/special is happening here" instead of trying to look like another html tag. If anyone is wondering how to do this, just make a view without any @sections in it. Then use @include('path.to.your.view', [array_of_data_here]) where you want it to show up. The array data ends up in the views local scope. So if you pass ['data'=>$something] you can access it in the view by calling $data. For edge cases where I need default logic, I handle that in the view partial via a @php declaration at the top of the view that checks if the expected input exists and creates the default if needed. This wasn't meant to be an argument against components, more that there was already a way to get DRY within Laravel before they came along.
i've been using laravel since 5.5 and i use it almost exclusively for every project big or small. I'd be lying if I said that laravel wasn't leaving me behind. I take a break from learning to work on projects for 3-4 months and when I come back during a lull the laravel world has sped forward and there's so much new material out. Like you, sometimes I wonder what the trade off value is: use repeated code that I'm super familiar with and just copy/paste because it's second nature, or take the time to learn the new component syntax. Will I save more copy/paste time by learning the syntax or will I spend more time learning syntax than it takes me to just copy/paste things....
Agreed. When I started my project last year it was with Laravel 5.8. I launched last week and in the intervening time we had Laravel 6, Laravel 7 and Laravel 8 (which I can't use, due to LTS linux on the server only supporting PHP 7.2). The pace of change in Laravel world is stupidly - and unnecessarily - fast. I can't spend all day, everyday, learning about new Laravel features!
@@martinh4982 plus million. I used to skip almost a year. And i was so angry when i saw current version 8. Cmon, when was 7??? And what i see? Tailwind, inertia, livewire, jetstream etc etc etc. Imho everythings getting more and more complicated. And too fast. What was to the purpose of rewriting all route files from controller@action into controller:class, 'action'. Extra commas, brackets. View folder is now a true quest. I am so disappionted, really. In order to start a basic project you have to make too many extra movements, installations, requirements, npms ... In early 00 i had a notepad txt editor, and dreamweaver-) and a full-featured php site was working fine. And now basic project consists of thousands files. Sorry for overemotions)
Components are great for making complex reusable features, like profile cards and so on. I'm less convinced about taking it down to tag level components. I've seen people turn h1's, td's, tr's etc. into components. The main reason they do this is because they're using Tailwind and want to avoid copying large blocks of tw class names all over the place - which would be a real maintenance nightmare. I think in those cases you might be better off using plain old CSS or even Tailwind's apply functionality. Designing reusable components can also be very tricky. Sometimes you're far better off just using HTML until you reach the point of repeating yourself and it clicks "hey, I should turn this into a component!". So I guess my take on this is to use components where it makes sense to use them.
@@shoemoney Oh dear. Fortunately I've been avoiding Jetstream (and probably will never adopt it) because it reminds me too much of when ASP.Net got ajax extensions in the mid 2000s. It was very nasty indeed.
Nos the next step is to know when to make:component, when to livewire and when to just use simple ones like the ones described here, btw liked that you usted that componentize word.
I just started using laravel breeze and I agree with you, using components for atoms (inputs, selects, buttons...etc) and using traditional includes, yield and extends could be better for sections.
Sounds like Taylor is getting a God complex. Honestly I also do not like forced to learn tailwind when I am already pretty overwhelmed. Eventually someone will fork it. Just like what happened with b2 then matt forked it into wordpress.
But you aren't force to use tailwind. The whole argument is dumb if you don't want to use tailwind then scaffold the Laravel app without jetstream and add bootstrap. It's really not that difficult to understand. Y'all just lazy.
I have the same opinion, GEST is not a component it's A LAYOUT, it's not readable, hard to figure out, a time consuming, NOT always DRY sometimes you find yourself in blocked situation. A button is a component yes! I believe that all wrappers or any portions that have a logic should not be used as components here include is pretty cool solution.
I just release my first project using breeze. I still missing the simplicity of Laravel 7 (or before). Taylor did a good job on Breeze, but I prefer the old brade components instead. One good point of new blade components is the ability to use AlphineJS almost on-the-fly.
Also, check out tailwind components on web. Everything is compatible, so you don’t spend a lot of time building everything. Tailwind community is growing!
in previous Laravel versions you could use ViewComposers which works pretty similar, Blade Components sounds a lot like ViewComposers but as 1st class citizens now
I see from where they are coming but doesn’t this “componenting” everything and anything has drawbacks too? For example if you change one element maybe you just want to change only that element and nothing else. Or am I wrong there?
I didn't get the reason to use blade components instead of includes (except for the inputs). And includes way more simpler and clear. I think it's an interesting addition to Laravel, but totally not a replacement for includes, sections, and yields. Unless you want some extra complexity.
I am getting left behind too, I am still struggling to get my head around the x components. I have been using laravel since 5.2 and every version update seamed to be straight forward but the upgrade from 7 to 8 feels like more of a change in one version that all of the past changes combined over the years.
Hi Mr.Povilas hope you're doing well. I was wondering if can make a video showing how to configure multiauth api using passport with laravel 8 because there's no package supports that for laravel 8.
@@PovilasKorop Thanks for replying. I mean configuring multi-auth providers. What I'm doing is building an api for two apps one is for user(student) and and one for teacher and each of them has his own model. each of them requires different authentication. I tried many ways but the tokens created for a user can be used in teacher routes and the opposite even after using middlebrows following all the steps of laravel passport documentaion.
Web developers just love creating solutions to problems that don't exist. People will look back at this stuff in 10 years like we look back at spacer gifs in the early 2000's and cringe.
Now see this video I think will use components but before I was not because I was more used to copy and paste code directly and able see what code does and how it structured in way but I still feel x-layout was bad idea in some cases like let say you want to run one extra js file for one specific page it gonna be bit hard
Not really a big a fan of the new blade components I feel new and old Laravel users will get lost with all this new syntax, now developers need to know this first to be able to create a simple page in the framework. A component for a simple button seems overkill to me, all this just for not repeating a css class name?
What do you mean by multi authentication? You mean roles and permissions? I see a lot of people mixing those two things. They are trying to use multi-auth drivers, instead of using the same "users" table and adding Roles/Permissions to it. Watch this video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Uq-eEOhVCmw.html
@@PovilasKorop yeah I agree with you, but let me tell you what is the case, actually, I created an invoke function that read XML file and saves the necessary data in DB, and this should happen every day, so I have to create a command line and a schedule, but after that, I had to create same function to import XML file because there is a case for that, so instead of creating new one I decided to use that previews invoke function which doesn't expect any request before, so I had to add request as a param and that cost me an error in the command line so what I did was adding request like this _invoke(Request $request=null)
this is handle function inside command line: public function handle() { $controller = new ImportMoviesController(); $controller->__invoke(); } and this is the function inside the controller: public function __invoke(Request $request = null){ if ($request->file){ //import this file }else{ //find the existed file in storage and import it } }
@@aminedaimallah310 creating a new controller object inside of other method and calling invoke? It's some kind of very weird code, I would never use a controller like this. Controllers are assigned only in routes, they should not be created dynamically like this.
But everyone should use them wisely. Don't make components for everything and make nested components then put them inside loops. Yes, from software design perspective you're doing great job by making your reusable blocks and don't copy paste the same code everywhere. But on the other side you'll notice a massive drop in your app performance, because of how blade render those components. Use @include whenever possible and make components your last option.
YOU make videos every day helping people. FOR FREE. And the reason its badly needed is cause their docs SUCK. That sucks he talks to you like that. Sorry this pisses me off.
Well, Taylor also works for free when making things like Jetstream or Breeze. And their docs are good actually. It's just a disagreement on what tech stack to use under the hood and why.
@@PovilasKorop Respectfully I disagree. Wordpress is 100% free with an option for some professional services but ALL the main code is free... And Matt is worth hundreds of millions of dollars. Point being build an application that people use and the money will come. Every saas app I have ever built was free. I made money from conferences, 3rd party services... etc... The price of free =). Now YOU are making videos to help him make money. Sure you will pickup some but without your tools, videos even if you charge for them its making me more entrenched in the Laravel ecosystem. Make sense?
They have what envoy, envoyer, etc etc vapor is a pile of crap and thats a shame. Good idea.... horrible execution and support. They are spread way to thing trying to do way to much. Loosing focus of making a good core product. its so bloated there is a TON of stuff that has next to no docs.
