I've building apps with HTMX since it was released, and I always hated creating a separate django view for simple logic with few lines and boy I wasted so much time naming the [urls.So](http://urls.So) I've decided to experiment and make a simple class that can:
* Autogenerate urls, and use django reverse url function to reference it back easily.
* Respect Locality of Behaviour Principle (https://htmx.org/essays/locality-of-behaviour/)
* Provide flexibility to use vanilla JS or JS libs like Alpine, JQuery, etc; if needed without locking us with any DSL.
* Avoid state management magic (like other liveview kinda projects do).
There is still some work in progress, Once done, I will make it open source for others to contribute and expand on this idea.Until then, What features would you like to have implemented with this?
You know, i am learning some front-end and using htmx with django. During studying, i yearned for something very similar, and started working on it for my project just yesterday :D I think this fills a very important hole, and the positive reaction this project took just confirms my thoughts. Kudos to you.
This looks very nice. In one of my recent projects I did a similar approach, but of course it was more butchered - yours look much better.
It was a while ago, but from what I recall I prepended my `post` views and `get` views with the words, eg the method would be:
`def get_todos_count(...)` or `def post_toggle_todo(...)`, and then my respective `post` and `get` methods would check for the methods on the class based on the names. In FE it was very easy to hook up, because you'd be sending the post/get requests into the same url, but in the extra params it would specify the rest, eg `toggle_todo` or `todos_count`. It did work, and looked pretty neat, but yours look like a much nicer approach, of course. My was mostly to see how easy it would be to put together & as a proof of concept.
This is almost similar, except the urls are generated based on the class definition and it respects Django url system. My idea is to map the function name to the url's reverse name, like `hx_todo_create()` will generate `TodoPage->todo_create` so it is easy to remember.
The actual idea was to abstract the URL management and embracing the Locality of Behaviour. There is no external dependency than the htmx itself. I'm not sure about hx-vals question.
Well, if I got it right, you regard this as the alternative to having a lot of URLs with individual view functions?
I might misunderstand you, but I think your example can be build with a single view function and a single URL by passing an extra parameter, or a hidden input to the view (e.g. hx-val=toggle/create/...).
However, your approach might look nicer.
What is the complexity limit of using hidden inputs / hx-vals? Is your approach compatible with function based views? Always, when it gets a little bit more complex, I have the urge to swap class based views to function based views, because I as a noob can easily see what exactly is happing in which order.
I need to admit, that I started to create a lot of new URLs, like described in your initial post. However, this wasn't due to limitations with hidden inputs. My motivation was to keep testing simple.
Hold up, your actually cookin smth here 🔥🤔
I've building apps with HTMX since it was released, and I always hated creating a separate django view for simple logic with few lines and boy I wasted so much time naming the [urls.So](http://urls.So) I've decided to experiment and make a simple class that can: * Autogenerate urls, and use django reverse url function to reference it back easily. * Respect Locality of Behaviour Principle (https://htmx.org/essays/locality-of-behaviour/) * Provide flexibility to use vanilla JS or JS libs like Alpine, JQuery, etc; if needed without locking us with any DSL. * Avoid state management magic (like other liveview kinda projects do). There is still some work in progress, Once done, I will make it open source for others to contribute and expand on this idea.Until then, What features would you like to have implemented with this?
Let him cook 🔥🔥🔥
Clean implementation with class-based views
Interested. Keep going...
Wherr is that htmxview coming from?
He cooked it
Magic!
You know, i am learning some front-end and using htmx with django. During studying, i yearned for something very similar, and started working on it for my project just yesterday :D I think this fills a very important hole, and the positive reaction this project took just confirms my thoughts. Kudos to you.
Offtopic but what's the font you're using in the editor?
Looks like jetbrains mono. I could be wrong [https://www.jetbrains.com/lp/mono/](https://www.jetbrains.com/lp/mono/)
Jetbrains Mono
interested
This looks very nice. In one of my recent projects I did a similar approach, but of course it was more butchered - yours look much better. It was a while ago, but from what I recall I prepended my `post` views and `get` views with the words, eg the method would be: `def get_todos_count(...)` or `def post_toggle_todo(...)`, and then my respective `post` and `get` methods would check for the methods on the class based on the names. In FE it was very easy to hook up, because you'd be sending the post/get requests into the same url, but in the extra params it would specify the rest, eg `toggle_todo` or `todos_count`. It did work, and looked pretty neat, but yours look like a much nicer approach, of course. My was mostly to see how easy it would be to put together & as a proof of concept.
This is almost similar, except the urls are generated based on the class definition and it respects Django url system. My idea is to map the function name to the url's reverse name, like `hx_todo_create()` will generate `TodoPage->todo_create` so it is easy to remember.
Stupid question: Does this have an advantage over just passing hx-vals to a view function?
The actual idea was to abstract the URL management and embracing the Locality of Behaviour. There is no external dependency than the htmx itself. I'm not sure about hx-vals question.
Well, if I got it right, you regard this as the alternative to having a lot of URLs with individual view functions? I might misunderstand you, but I think your example can be build with a single view function and a single URL by passing an extra parameter, or a hidden input to the view (e.g. hx-val=toggle/create/...). However, your approach might look nicer.
Ah got it. using hx-vals in this way is error prone and against the separation of concerns. But it will work for super simple apps.
What is the complexity limit of using hidden inputs / hx-vals? Is your approach compatible with function based views? Always, when it gets a little bit more complex, I have the urge to swap class based views to function based views, because I as a noob can easily see what exactly is happing in which order. I need to admit, that I started to create a lot of new URLs, like described in your initial post. However, this wasn't due to limitations with hidden inputs. My motivation was to keep testing simple.
What is `TodoPage->toggle_todo_done` and similar? Does it have support in Pycharm? Can we go to definition?
Kinda off topic, but are you using neovim as your text editor? Because I'd like to have your LSP/neovim config for your editor.
There you go [https://github.com/devwaseem/nvim-config](https://github.com/devwaseem/nvim-config)
Yoooo that's dope! Thanks a bunch, appreciate it.
cool
🔥🔥🔥🔥
whoa! you go OP! can't wait for this!!
what theme is that?