HTMX and Golang - Building A Counter With State Management
Вставка
- Опубліковано 12 сер 2023
- Learn how to use HTMX and Golang to build a counter functionality with server-side state management, with decrease and increase buttons that alter the state and update the value on the browser without a full-page reload.
🖥️ Repository (source code)
github.com/webdevfuel/htmx-go...
Very well explained HTMX. Thanks for creating this playlist!!
Thanks! I'm really glad it was well explained!
Please make the text bigger, it’s very hard to read.
Sorry about that. I always forget to increase the font size. I've created a script to take care of that for me before recording, so hopefully in the future I won't forget again, haha. Appreciate you watching even though it was hard for you to read! 👍
@@webdevfuellmao. Just hold ctrl and scroll up 😭
im gonna be honest here, that was a LOT OF STUFF for getting a simple counter up and running. I'm pretty sure every other language/framework would have this in a couple of lines. But each to their own!
That's because it's not about doing a counter. You're creating a server that handles routing, sends response to client, and handles some sort of state. With this guide you now have more tools you can use to create a web application.
Notice that we did very minimal amount on client side. Imagine doing all of this, but without HTMX. Now, we would have to do everything we just did but ALSO we would need to select the right element, create an event handler, create a fetch, and parse the data. So actually, HTMX helped us write less code.
Could not even see a thing on mobile. Please consider that you can have people watching from mobile
Same
Use `your string here, without having to escape " or '` for Go strings ;) Nice tutorial!
really cool, made me question my whole life doing spas :))))
Haha, isn't that the goal of programming... to constantly question our entire existence? Thanks for watching! Glad you found it cool! 👍
thanks for the video, how can you modify the HTML body sending events from the server? for example, update the counter every x seconds from the browser.
If you want to trigger a request to the server every x seconds, you can use the HTMX attribute hx-trigger with value "every xs". For example hx-trigger="every 1s", to trigger a request every 1 second. Thanks for watching! 👍
@@webdevfuel thanks for your answer :)
that idea can work if you are interested in a polling solution, but what about subscribing to events started by the server? for example, the server sends a message to every user who has the page open
Oh, I see now. Thanks for clarifying that! In that case, you'd have to use websockets. There's an extension for HTMX. I haven't used it at all to be honest, but I'll be sure to check it out in the future, maybe even create a series on building a real-time chat application with HTMX and Go.
@@webdevfuelsounds like a great idea!
But this means if one user changes the state, it is changed on the server memory and that changes it for all the users everywhere right?
Yes, you're right. In this example that's what would happen with the in-memory value. There needs to be a session plus store the values in a db to have a counter per user.
Or use a message broker to isolate between shared state and user / session state
@@gedw99 "message broker"? Never heard/used. Can you give me an example library? I'm trying to find out how htmx could be used for a real life application. But if every click and key state has to be stored in some central DB with some userId key... it sounds kinda crazy. I guess I am missing something.
@@TheNoirKamui
htmx is suitable for data-oriented applications, such as: messages, comments, likes, etc., any application that displays, edits, and stores data. (Internet required)
It is not suitable for interactive applications such as games and calculators... where the user state is separate from the server, and the application can work without the Internet.
Hmm, I have a few issues with this, I wonder if there's an agreed upon solution within the community?
- you now specify the div counter in three places which makes maintenance a nightmare if you consider a real world application
- because the state is on the server, it is now shared among different users. Even if you'd store it in the database per user (which isn't viable in this and many more scenarios), it would still be shared among tabs. Seems client side javascript would still be necessary?
I suppose form inputs would solve number 2
You should not have to duplicate the counter, the way I understand it is you could target the counter div (innerHTML) and make the request and just return the updated number and it should update correctly within the counter div.
What if you have thousands of users at the same time all clicking the counter? Wouldn't your server get overwhelmed? While a typical React frontend would not have made a single call.
But I see the value in it though. SPAs with all the Babel Webpack Crap suck of course.
Well that is not entirely true. You need to define an strategy in order for "React not to make a single call". If you are executing an ajax request on submit then you need to do some kind of limiting (throttle). Which you can easily implement yourself as well with htmx. On the server side there is something similar (rate limiting) you can search how to do it as well.
Why using mutex?
Because the requests are synchronous. (goroutine)
This causes a data race problem
@@baxiry. maybe Asynchronous
I have to dig more into HTMX but a counter seams to be the worst example to illustrate it, as for a simple number in a page to go from 1 to 2 sending a fetch request sounds overkill. I can see how there are scenarios where HTMX can be useful, but it's also very limiting if we have to always depend on a backend.
Yes, it's for sure overkill but I still think a simple example is better to teach the fundamentals of HTMX and Go, even if it's further from a real world scenario. I'm doing a series on how to build a to-do list application with HTMX and Go, so you might find that useful to learn more advanced concepts that are closer a real world scenario. Thanks for watching! 👍
Dude, zoom that code.
Sorry! It's fixed on later videos, but forgot to zoom in on this one. Hope it's still helpful to you! 👍
What a mess! I doubt this can handle big projects, especially when dealing with APIs across multiple apps and platforms.
interesting video and tech. thanx a lot for making and sharing it. however I wonder how the counter state is managed in a multi-user mode
Thanks!! I'm thinking probably Redis or other in-memory key-value database would be a good use case for multiple users.
@@webdevfuel what if I want to keep the state in a local (browser) storage?
lol just because you can doesnt mean you should
Haha, it's for a sure a very basic example without a lot of real world use cases, but I still think it provides a basic foundation for how to use HTMX and Go. I'm doing a series on how to build a to-do list application with HTMX and Go. Give it a watch if you want something that makes more sense for this tech stack. Thanks for watching! 👍