Multiple views per component

[tanssinet]

For a few days, I have been working on a component that includes autocomplete. It may be a generic autocomplete component in the future, but currently it is related to the business logic.

I have been iimplementing it with django components, Alpine.js, HTMX and Bootstrap 5.

Currently, there are two components, "composition_search" and "composition_list_editor". The former is actually not a component in itself, but provides an HTMX endpoint to the latter, search results as <div> elements. So these two are tightly coupled.

I started thinking that perhaps they are so tightly coupled that they conceptually actually belong to the same component. The reason they are seperate components is that django components does not support having multiple different kind of endpoints per component, because there is view per component relationshp.

If you think about it, views are a way to express operations as endpoints, and it really makes sense that there can be many operations for a single component, especially in the HTMX world.

Currently, this is not a big issue for me, but just wanted to get the idea out there.

[dylanjcastillo]

This about template fragments, right? I've been thinking about it but don't have a clear view now of how that'd work in django-components.

[tanssinet]

Seems like I am using multiple accounts here, sorry for the confusiom. Same person anyway.

Yes, exactly. I feel like I am implementing a URL dispatcher inside each component.

[EmilStenstrom]

Personally I think this is something we shouldn't do as part of django-components. I think you could do it yourself though, just by overriding the Component class with your own logic and inheriting from that one instead. Makes sense?

[mikko-ahonen]

I guess it comes down to the question "what is a component?" and your vision for the library.

If you look at it technically, just as a set of js + python + html + css, then the current situation is fine, especially if you think that the "hardcore HTMX" way of development is not that important.

However if we look at components from a logical perspective, I think one key element of a component is a support for multiple logical operations beyond the hard-coded ones (PUT, POST, GET, DELETE). Another key aspect is that it encapsulates some reusable behavior.

For your proposed solution where there is some magic to route the request to a certain method, inheritance from Component makes sense.

I was thinking that there mightj be multiple alterative approaches to achieve the same functionality, such as multiple views per component.

In Django, there seems to be in practice an implicit assumptiion that a view and the corresponding URL are tightly coupled. If we also make an implicit assumption that one component is one view, in practice it seems to imply for the HTMX development that one logical component actually consists of multiple technical django-components.

[EmilStenstrom]

@mikko-ahonen Some other considerations:

• How much of what you are talking about is application specific, and how much of it is "base" functionality that should be part of django-components?
• What mental model do we expose to users of the library, both direct (people choosing the library and implementing it) and indirect (people reading the code that someone else implemented)?

I'm definitely open to discussing this further. For instance, what would the API be?

There are a couple of "framework" libraries out there, that are doing what you propose:

https://www.tetraframework.com/

<button class="btn btn-primary" @click="add_todo(title)>

@default.register
class ToDoList(Component):
    @public
    def add_todo(self, title):
        ...

https://www.django-unicorn.com/

<form unicorn:submit.prevent="add">

class TodoView(UnicornView):
    def add(self):
        ....

[mikko-ahonen]

I tried Unicorn, but got stuck with some "framework" problem. I have not tried Tetra, but it looks more promising as it is using Alpine. I prefer the library approach of Django components, though.

How much of what you are talking about is application specific, and how much of it is "base" functionality that should be part of django-components?

I think it is core functionality of components, at least in how I see what components are.

What mental model do we expose to users of the library, both direct (people choosing the library and implementing it) and indirect (people reading the code that someone else implemented)?

The mental model of the user and the API depends on the approach.

If we take the "component can be exposed as multiple views" approach, then I guess API would be some method decorators to define mapping between each view and the methods, and adding view name to parameter for the as_view()

in components/foobar/foobar.py:

  @component.register("foobar")
  class Foobar(component.Component):
     ...
     @post_for_view("save")
     def save(...):
     ....
     @get_for_view("edit")
     def edit(...):
     ...

in components/urls.py:

    ...
    path("foobar/save", Foobar.as_view("save"), name='foobar-save'),
    path("foobar/edit", Foobar.as_view("edit"), name='foobar-edit'),
    ...

For the "component functions can be autowired to URL keyword" approach, then I guess the API would be subclass of Component + some code to expose methods as a view.

in components/foobar/foobar.py:

  @component.register("foobar")
  class Foobar(component.MethodViewsComponent):
     ...
     def save(...):
     ....
     def edit(...):
     ...

in components/urls.py:

    ...
    path("foobar/save", Foobar.methods_as_view(post="save"), name='foobar-save'),
    path("foobar/edit", Foobar.methods_as_view(get="edit"), name='foobar-edit'),
    ...