-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added hx-confirm and hx-delete. #3
Added hx-confirm and hx-delete. #3
Conversation
This is one little piece that was missing for me when I migrated my custom code from https://github.com/Baralga/baralga-app to gomponents-htmx. |
Thank you! 😊 |
(I plan to add the remaining attributes tomorrow, so will release then.) |
@remast @lobre v0.3.0 now released! Give it a spin and let me know what you think. 😊 Feel free to connect on Mastodon: https://hachyderm.io/@markus |
Does anyone know how I get Github to show contributors on the front page of the project? |
Awesome, thanks for having implemented all of that! That’s really practical! I don’t know how to show contributors, or at least if there is a way to add them on the front page automatically... I am not a super fan of having to import all those different libraries, I would prefer a single import for gomponents, and another for htmx, but I can understand that you think it is better "organized", especially in the documentation (even if I would not bother myself :-)). It scares me a little if more and more libraries are supported, it could generate dozens of lines of import if I want to use them all.
Apart from this, it is really cool as it gives a lot of joy to be able to do frontend templates that easily in go! |
@lobre yeah, it looks a bit chaotic when it's all jumbled together. Normally, I would have the html-related imports in a separate package For gomponents, it made sense to me to have all low-level HTML elements and attributes in a separate package, so they can be dot-imported. The higher-level components (such as It's the same with HTMX: the attributes are in the base package (so they can be aliased easily with I'll think about if this can be improved. Thank you for your feedback! |
Have you thought of trying to namespace different things in the same package? This Reddit thread explains a little bit about how this is used in the https://www.reddit.com/r/golang/comments/hocwje/just_found_out_that_we_can_namespace_functions_in/ I am not saying that it would be a superior design, but maybe worth being considered. For instance, there could be only one package
It is just a quick draft of what could me made, but there are other ways to organize that. And the code could be split into different files in the root package, to keep the "structure" and have the code still easily understandable. I am sure you will not like it, as it surely feels less tidy from a package designer perspective, but for a user, it could be handy to only have to import one package to use gomponents. I think it is what people like with Would love to hear your thought about this, even if I know it could be a little opinionated ^^ |
@lobre thank you again for taking the time to provide feedback. You guessed correctly. 😋 But not for the reasons you outlined. My thinking is:
I hope that's a satisfactory answer. 😊 |
Makes sense, thanks for taking the time to answer |
No description provided.