Glad you clarified the main use case between both HTMX and Livewire cause I was getting the intuition it looks and works like Livewire... The concept is still the same but the implementations are both principally different
For the contact form example what i like to do is create a wrapper around the form that will contain your "#response" element and the form itself, i put hx-target="this" and hx-swap="outerHTML" on the wrapper and no target and swap on the form so it can bubble up to the wrapper, extract it into a partial or component and render the entire partial/component as the response. In this way you will always has a fresh form when you it is a success response and if i have errors i just flash the old input with session()->flashInput() so i can use the `old(VALUE, DEFAULT)` helper. Like you would do normally with blade and redirects
Stuff starts to get really ugly/crazy at 14:29 LOL, but the overall solution is quite interesting. I would use it on small websites for sure. Thanks for share, Andre 👍
Hi thank's for this video a have question I used htmx to delete and the deletion operation is done successfully, but the list is not updated. In your opinion, the reason is that file web.php is used instead of file api.php for routing?
What web server are you using? When I do the api call as shown in the first part, I get the response in 100ms give or take, but you got in 16ms, any idea why there is a huge perf gap?
I know 5 months have passed since you asked this, but from your description i guess you are using Windows or WSL. From my experience, Laravel runs smoothly on Linux and Mac, while on Windows it usually gets kinda sloppy.
The thing is that it's not "doing stuff in htmX" but in Laravel PHP, ...while recieving Ajax calls from a webpage (one way or another). It goes the same in the others demos using Python, Rust, Go or whatever. All the hype like "switch from React to Htmx" sounds like internet attention as you can't compare a JS framework that actually do everything with ajax calls that need a backend to actually do something. Htmx alone is like the Tailwind version of jQuery!
Well yea, that's the point. YOU don't have to do anything (mostly) in the front-end with HTMX. Instead of passing JSON to the front end which requires an entire framework to unpack and render into HTML while managing a client version of state why not just send the HTML directly from the back end where the state is managed by the server? Even with react, you still need to process the data to send back from the server, the only difference is it's the HTML which can be inserted directly into the DOM.
HTMX feels natural. It is like this is how it should have been all along.
request: full series of Laravel + HTMX
htmx with Alpine should be a gem combo alongside Laravel
Yeah, seems like they would work well together.
Glad you clarified the main use case between both HTMX and Livewire cause I was getting the intuition it looks and works like Livewire... The concept is still the same but the implementations are both principally different
For the contact form example what i like to do is create a wrapper around the form that will contain your "#response" element and the form itself, i put hx-target="this" and hx-swap="outerHTML" on the wrapper and no target and swap on the form so it can bubble up to the wrapper, extract it into a partial or component and render the entire partial/component as the response. In this way you will always has a fresh form when you it is a success response and if i have errors i just flash the old input with session()->flashInput() so i can use the `old(VALUE, DEFAULT)` helper. Like you would do normally with blade and redirects
Stuff starts to get really ugly/crazy at 14:29 LOL, but the overall solution is quite interesting.
I would use it on small websites for sure.
Thanks for share, Andre 👍
More content on laravel htmx alpine
i love the way you explain things thanks for you great effort
great video, thanks! I like how you keep the errors in the editing.
Hmtx is cool for ui stuff to show, hide, filter. For forms I would use livewire. Its just much simpler than writing everything on your own.
Thanks for the excellent first approach to this new tool n_n
Hi thank's for this video a have question
I used htmx to delete and the deletion operation is done successfully, but the list is not updated. In your opinion, the reason is that file web.php is used instead of file api.php for routing?
Thankyou
Thank you for sharing
Please let me font and other extensions that you used in visual studio code
Thanks
May i know why you refresh the page when you make changes in the response html file.
Awesome...
Can i edit ajax header too
I'm not sure if you can change the headers... Here's more info on headers in the docs: htmx.org/docs/#request-headers
How htmx can be use for a CRUD pure laravel or can olnly be use through api?
Looks like this solution is much more complicated than using Laravel Livewire
What web server are you using? When I do the api call as shown in the first part, I get the response in 100ms give or take, but you got in 16ms, any idea why there is a huge perf gap?
I'm using Valet locally. Not sure what could be causing your local server to be slow.
I know 5 months have passed since you asked this, but from your description i guess you are using Windows or WSL. From my experience, Laravel runs smoothly on Linux and Mac, while on Windows it usually gets kinda sloppy.
datatable need to update with htmx version
The thing is that it's not "doing stuff in htmX" but in Laravel PHP, ...while recieving Ajax calls from a webpage (one way or another). It goes the same in the others demos using Python, Rust, Go or whatever.
All the hype like "switch from React to Htmx" sounds like internet attention as you can't compare a JS framework that actually do everything with ajax calls that need a backend to actually do something.
Htmx alone is like the Tailwind version of jQuery!
Well yea, that's the point. YOU don't have to do anything (mostly) in the front-end with HTMX.
Instead of passing JSON to the front end which requires an entire framework to unpack and render into HTML while managing a client version of state why not just send the HTML directly from the back end where the state is managed by the server?
Even with react, you still need to process the data to send back from the server, the only difference is it's the HTML which can be inserted directly into the DOM.
Too much code duplication. And if you create partials/templates for each part of your view that will be messy too