Design Document: Live Components for `django-components` #1366

EmilStenstrom · 2025-09-07T08:42:53Z

EmilStenstrom
Sep 7, 2025
Maintainer

Hi everyone! Here's a heavily AI-authored design document for "LiveComponents", a new extension for DJC. Thoughts?

Executive Summary

django-components today is a powerful way to encapsulate HTML, templates, and logic into reusable components inside Django projects. However, its execution model is still page/request-based: the browser reloads or re-renders on every action.

This proposal introduces Live Components: server-owned, stateful components that render themselves as normal Django templates, but can update their DOM in place over a WebSocket (or HTTP fallback). Developers continue to write plain HTML templates and Python classes, but user interactions (clicks, submits, navigation) are automatically routed back to the server, where the component updates its state and returns fresh HTML fragments.

The goal: rich, reactive UI without writing JavaScript or custom HTML DSLs. The design is deliberately similar to Phoenix LiveView or Laravel Livewire, but built on the foundations of django-components.

Goals

Zero-DSL authoring: Authors keep writing plain Django templates (button, form, a href, input). No data-* attributes required.
Server state is source of truth: Component state lives in Python objects on the server.
Minimal client runtime: A ~150 LoC script handles event delegation, socket connection, and DOM patching.
Compatibility with djc: Leverage existing Component, self.id (unique render ID), and fragment rendering for patches.
Progressive enhancement: If JS or sockets fail, normal HTML semantics still work (forms submit, links navigate).
Extensibility: Allow pluggable patch strategies (root replace → DOM morph) and multiple transports (WS, SSE, HTTP).

Architecture

Server Side

1. LiveComponent Mixin
Extends django_components.Component:

Holds state (dict or dataclass).
Provides assign(**kwargs) → updates state, re-renders fragment, returns {component_id, html} patch.
Exposes event handlers (def save(self, evt): …) that correspond to standard HTML intents (button/form names).

class Counter(LiveComponent):
    template = "counter.html"
    state = {"count": 0}

    def inc(self, evt): self.assign(count=self.state["count"] + 1)
    def dec(self, evt): self.assign(count=self.state["count"] - 1)

2. Routing Events
Incoming payloads (from client) look like:

{
  "type": "click",
  "component_id": "c1A2b3",
  "intent": "inc",
  "value": "…",
  "form": {...}
}

Dispatcher finds the right LiveComponent instance, invokes inc(evt), and returns a patch.

3. Rendering Fragments
Use djc’s existing fragment rendering (deps_strategy="fragment") so only inner HTML and missing JS/CSS assets are sent. Dependencies are handled automatically.

4. Transport Layer

Primary: WebSocket endpoint (/live).
Fallback: SSE or HTTP POST to Component.View (public=True) for environments without WS.
Each message returns {component_id, html} (and optionally target_id) to patch.

Client Side

1. Event Delegation
A global script attaches listeners for:

click (buttons, inputs, links)
submit (forms)
change / input (inputs, selects, checkboxes, radios)

2. Component Root Resolution
Every component instance already has a unique id (self.id, e.g., c1A2b3).
On event, runtime finds nearest ancestor with id^="c" and uses that as component_id.

3. Intent Derivation (no DSL)

Buttons/inputs: name (preferred), else value, else text fallback.
Form submit: browser gives evt.submitter.name.
Links: if same-origin and plain → navigate(href); if link has name/value → action click.
Inputs: change produces {field, value} payload.

4. Sending & Receiving

Serialize payload as JSON, send over WS.
Receive patch: {component_id, html}.
Apply: document.getElementById(component_id).innerHTML = html.
Optional: more advanced morphing engine later.

5. Progressive Enhancement

If JS is disabled: buttons submit forms, links navigate normally.
If WS is unavailable: fall back to HTTP endpoints (Component.View).

Example Flow

Template (unchanged Django):

<div id="{{ component.id }}">
  <p>Count: {{ count }}</p>
  <button name="inc">+</button>
  <button name="dec">-</button>
</div>

Component (Python):

class Counter(LiveComponent):
    template = "counter.html"
    state = {"count": 0}
    def inc(self, evt): self.assign(count=self.state["count"] + 1)
    def dec(self, evt): self.assign(count=self.state["count"] - 1)

User clicks “+”:

Client runtime captures click → finds root id c1A2b3 → payload {type:"click", intent:"inc"}.
Server runs inc(), updates state, re-renders fragment.
Server returns {component_id:"c1A2b3", html:"<p>Count: 1</p>…"}.
Client swaps innerHTML.

Implementation Plan

Prototype (djc_ext_live)
- Implement LiveComponentMixin with state, assign(), and dispatch_intent().
- Add ASGI WebSocket endpoint for /live.
- Write client runtime (~150 lines).
Integrate with djc
- Reuse self.id and fragment rendering.
- Use existing Component.View for HTTP fallback.
Patching Strategies
- v1: full root innerHTML replacement.
- v2: DOM morph (opt-in).
Security & Scaling
- Include CSRF/session in WS handshake.
- Inject request.user into component methods.
- Store state per connection (in memory + optional Redis for HA).
Developer Experience
- No template pollution; all event derivation from standard HTML.
- Hot-reload for templates/components.
- Dev warnings for buttons/links without name (ambiguous intents).

Non-Goals (for v1)

Fine-grained DOM diffing (can come later).
Full offline mode.
Rich client-side hooks beyond progressive enhancement.

Risks & Mitigations

State explosion: Many sockets → many component states. Mitigate via session scoping and Redis store.
Ambiguous intents: Elements without name. Mitigate via dev-mode console warnings.
SEO/navigation: Use normal links for fallback; navigate() enhances UX but isn’t required.

Conclusion

By adding a small Live extension, django-components can leap from “static component rendering” to a reactive component model without requiring users to learn React, Vue, or a custom DSL. Templates stay plain HTML, logic stays Python, and the client runtime remains minimal. This design respects Django’s philosophy (HTML-first, server-driven, progressive enhancement) while delivering the interactivity expected from modern web apps.

dalito · 2025-09-07T11:14:42Z

dalito
Sep 7, 2025

Sounds interesting. Maybe check if Datastar could help which is too new to be well known/considered by AI. If streams should go mainly from server to client it may be a good choice with its SSE foundation. It does the fine-grained DOM diffing already now.

1 reply

EmilStenstrom Sep 7, 2025
Maintainer Author

I'd like to avoid a framework and any kind of HTML annotations at all. Minimal wrapper which listens to events and pass to backend for processing. Then push back from backend when done.

JuroOravec · 2025-09-14T13:02:40Z

JuroOravec
Sep 14, 2025
Maintainer

What's the appeal of this approach? Is it to be able to write UI user event handlers in Python?

I'm not fan of this paradigm. To me it feels like the same like how PHP was looked down upon because it was known for mixing UI and server logic.

Also because abstracting JS away behind Python inevitably means that you will limit what people can do. And they then have to rely that you will implement the features they're missing.

In this sense, I see "No JS" frameworks as false promise

While the users don't have to learn JS, they have to learn the framework. If you learn to write JS once, you can reuse this skill everywhere. If you learn a specific framework, you're back at zero the moment you change the framework. So I think people are better off learning a bit of JS.
"No JS" is also a bit deceptive - It gives the perception that the websites will work in strict security environments where scripting is disabled (see <noscript>). But truth is that you will most likely need to execute some JS in order to listen to user clicks, etc. So the website would NOT work with scripting disabled.

On API

Because with abstracting JS behind Python, while you gain that you can react to user events in Python, you lose the logic separation.

Now both the UI rendering AND UI event handling would likely be defined in the same Python file.
What's more, because Python relies so much on classes, the API design will likely end up such that the same Python class contains both properties and methods for UI rendering and UI event handling.
When you then add class instantiation into the mix (will you reuse the same component instance for event handling that you used for component rendering?), then that will result in that sort of spaghetti classes like Django's Form class, which IMO are really confusing to work with, because it's hard to ensure the exact state.

So with that in mind, that's why when it comes to any sort of features that deal with incoming data (HTTP / websocket, etc), I think they should be scoped in a nested class to show clear separation from the rendering logic. Same thing how I also suggested the Tetra framework integration to have an API like so:

from django_components import Component

class Table(Component):
    class Tetra:
        title = public("")
        done = public(False)

        @public.watch("title", "done")
        @public.debounce(200)
        def save(self, value, old_value, attr):
            self.todo.title = self.title
            self.todo.done = self.done
            self.todo.save()

Thoughts

But to each their own, so some thoughts on this:

How does this differ from Tetra?
No thoughts on Routing Events
How would the user state be handled on the server? Big portion of Tetra does is about how they serialize the state, so that it can be rehydrated on user event.
- Furthermore, one thing I never understood - relying on server side event handling means that the state has to be stored on the server. For how long? 15 mins? 1 hour? Do you keep the state of the previous pages you visited before? Because if not then that sounds like a bad user experience:
  - I go away for 20 mins, then click on a button, and I get an error because my session got terminated in the meantime.
  - Or I click on some link accidentally, so I click back, but I get error, because the server already deleted the state of the previous page.
On websocket, I read that there's some issue / not possible to use websockets with Django. Might be old info.
On event delegation - This would work only for the simplest websites. I work on a moderately complex website (e.g. imagine the Vuetify autocomplete field with "multiple" and "chips" selected), and here user input DOES NOT directly map to an <input> field.
On form submitting - Same thing. It works for the simplest kind of websites. But once you need to 1) pre-process, 2) do custom input validation, or 3) run some JS after form submission, it's easier to handle that entirely in JS.
- So the take away is that there should be some JS hooks that could be called so that the same logic can be triggered wherther by submitting a <form>, or sending the data from within JS.
No thoughts on payload structure
Links - Don't quite understand from the summary how the links would be defined.

Other

There is django-livecomponents. Don't know if the package is publicly available on PyPI. It's based on some old version of django-components, some ~v0.20. They use HTMX and Alpine.

I'm actually having a call with their CEO/CTO tomorrow. They'd like to upgrade, but they want to wait for django-components v1. And they might sponsor us to get there.

3 replies

EmilStenstrom Sep 14, 2025
Maintainer Author

Thanks Juro, great set of questions. Here’s how I’m thinking about each one:

0) “What’s the appeal? Isn’t this ‘No-JS’ / PHP-style mixing?”

The appeal is to cut the boilerplate for small/medium interactivity (counters, filters, paginated tables, wizards, inline CRUD) without adopting a JS framework. Keep templates as plain Django + server state as the source of truth. It’s “minimal JS,” not “no JS.” There is a tiny client runtime to wire events → server. If you want to compare to something modern instead of PHP, look at Phoenix Liveview instead. This appeal is the same, work in one framework, not two different ones (in different programming languages).

We’re explicit that <noscript> environments fall back to normal form submits/links rather than live updates. So this will work with <noscript>.

1) How is this different from Tetra (and similar frameworks)?

No Alpine / no custom DSL/attributes by default. We derive intents from standard HTML (name, value, submitter). You can still opt into small hooks when needed, but the base case is plain HTML + Python. Progressive enhancement first. Plain links/forms keep working; live mode upgrades UX. Not trying to be a full-stack UI framework - just a minimal “live” layer on top of DJC.

Reading between the lines you might be arguing: "Let's work with the existing frameworks to not alienate them from this project", and I'll be happy to do that, but let's then be explicit with that if so.

I'm proposing this as an optional extension, so it wouldn't we the default way to interact with DJC, just another option.

2) API / separation of concerns (avoid spaghetti classes)

I like your nested-class suggestion. Something like this?

from django_components import Component

class TodoList(Component, LiveComponentMixin):
    template = "todo_list.html"

    class State:
        items: list[dict] = []

    class Events:
        def add(self, evt, state):
            title = evt.form.get("title", "").strip()
            if title:
                state.items.append({"title": title, "done": False})

        def toggle(self, evt, state):
            i = int(evt.value)
            state.items[i]["done"] = not state.items[i]["done"]

Render stays in the template (and optionally helper methods on the outer class).
Events go in Events (or a mixin), passed a plain, serializable state object so we don’t tie logic to the Python instance lifecycle.

3) Component instance reuse vs. state; lifecycle

I think this is solvable, but should be part of a more detailed architecture for this feature. ChatGPT suggests:

Do not rely on reusing the same Python object. We store serialized state (dict / dataclass) per {session, page_key, component_id}. On each event we rehydrate that state into a fresh component instance (or pass state directly into Events).

Store: in-memory for dev; Redis adapter for prod / HA.

Versioning: include a state_version in the payload; reject stale updates gracefully (request a refresh).
This avoids “spaghetti instance” problems and makes deployment/load-balancing sane.

4) State lifetime, back button, inactivity

Since everything can always fall back to server-side rendering, the saved state acts more like a cache to speed things up. Again ChatGPT:

TTL: sliding 20–30 minutes per active page; each event refreshes TTL.

Back/forward: the payload includes page_key. If state exists, we rehydrate; if it expired, we silently refetch fresh HTML (full or partial) rather than 500’ing.

Deep links: components must render from initial props without needing prior state.

Net effect: no “click after coffee break → cryptic error.” Worst case is a quick re-render / reload.

5) WebSockets with Django (is this feasible?)

Yes. Django now has native ASGI support; A small ASGI endpoint can handle WebSockets in production today. For environments where WS is awkward, we could support SSE or HTTP POST fallback via Component.View.

6) Event delegation limits (complex widgets like multi-select chips/autocomplete)

I don't see why everything has to map to one input widget. The state is at the component level, so in your autocomplete example you could have both a list of selected states, and a list states for checkboxes. Events triggered inside that component would pass the new state to the server. I might be missing something, but I don't see how that breaks the abstractions here?

I guess we could add an opt-in client hook where you could opt to dispatch custom events. That would then only be used for advanced components...

7) Forms: pre-process, custom validation, post-submit JS

Data validation of course needs to be done on the server-side as well, so this would be a way to avoid having that validation defined twice. The core flow would be the submit returned a new patched HTML form with error messages baked in.

But yes, we could add a opt-in client hook here too for custom JS stuff if you wanted to do that before or afterwards.

8) Payload structure (explicit, stable)

I'm answering with a quick idea from ChatGPT here too, as I think we're not yet at the "let's nail the details"-stage, and more of a "is this even doable?"-stage:

Request:

{
  "type": "click|submit|change|navigate|custom",
  "component_id": "c1A2b3",
  "intent": "add|toggle|save|...",
  "target": {"id": "btn-1", "name": "add", "value": "3"},
  "fields": {"title": "Buy milk"},      // only for submit/change
  "payload": {...},                      // for custom widgets
  "meta": {
    "path": "/todos?page=2",
    "page_key": "p:abc123",
    "state_version": 7
  }
}

Response:

{
  "component_id": "c1A2b3",
  "html": "<div id='c1A2b3'>...</div>",
  "state_version": 8,
  "patch": "replace_inner"
}

9) Links — how are they defined / intercepted?

A plain link inside a live component gets delegated to the component, and it can return either a fragment, which means that component will be replaced with that HTML, or a full HTML body which means the full page will be replaced and new components loaded. External links are followed as normal.

10) “People should just learn JS” / lock-in concerns

Totally fair. This is not anti-JS; it’s a pragmatic option for Django teams who:

mostly ship server-rendered apps,
want to add interactivity without adopting a JS stack,
and are OK with 80/20 coverage (opt into small JS for the hard 20%).

Because we avoid a DSL and keep HTML semantics, the exit ramp is easy: you can replace a live component with a JS widget gradually.

11) Live-components

Happy you are talking to them. They are the ones currently sponsoring the project! Happy to hear if they would like to work more closely with you/us. Send me a summary afterwards on WhatsApp what you decide?

JuroOravec Sep 14, 2025
Maintainer

Thanks that sounds much better than I initially imagined!

RE: API

The API with class State and class Events looks very clean.

Right now I use a lot the Component.View handlers. But it's limiting, because with Component.View the endpoint handlers are defined per HTTP methods (get, post, etc). But sometimes there can be more than one form or action per component. So then I have to send one as POST, the other as PATCH, etc. But that already breaks either Django or django-ninja, because one of them doesn't properly read form data when the form is sent with HTTP method other than POST.

Which is why I had to switch entirely from submitting forms directly as <form> to instead use JS (fetch()) to send the requests. So that I can send the data as JSON (application/json), instead of a form data (multipart/form-data)

Actually, if the state was passed in like that, into the event handler directly and not tied to the component instance lifecycle, I can imagine I could use the Events API also for returning HTML fragments.

For fragments I currently do something like this:

class Button(Component):
    template = "..."

    class View:
        # This is what gets called when I want to fetch the Button as HTML fragment
        def get(self, request):
            return Button.render_to_response(
                kwargs={
                    "text": request.GET["text"],
                }
            )

Instead, I could switch to Events like so:

class Table(Component):
    template = "..."

    # Event handlers
    class Events:
        def fragment(self, evt, state):
            return Button.render_to_response(
                kwargs={
                    "text": evt.data["text"],
                }
            )

The Component.View could then be softly deprecated - to be used only as a compat layer for registering components with Django's urlpatterns. And instead Component.Events would be the recommended way to handle events.

Next, there shouldn't be any extra overhead for using these event handlers when not using any state. What I mean by that is that if my component doesn't define any State, then no database entry should be created when I render this component. In other words, an event handler defined in Component.Events + No state should be more or less the same as an event handler defined in Component.View.

So overall the difference between View, State, and Events would look like this:

class Table(Component):
    template = "..."

    # session state
    class State:
        click_count = 1

    # Event handlers - receives state if there is any
    class Events:
        def on_submit(self, evt, state):
            ...

    # Define how to render component when registered with `urlpatterns`
    class View:
        def get(self, request):
            ...

Websocket vs HTTP vs other

One unknown to me is that I don't know how Django handles user authentication with websockets. Since it feels that Django and its ecosystem makes a strong use of attaching data to the Request object (e.g .request.user).

Here, I think it would be best if the inputs to event handlers would be just like in your examples - evt and state.

By omitting request arg (or equivalent for websocket), we could make it more flexible:

Whether the events would be sent via websocket or HTTP could be an implementation detail. User could swap out different "backends" in the settings.
If we had these swappable "backends", thenthis API with Events and State could also work outside of Django. So e.g. if one day django-components was made to work with FastAPI, someone could write an integration to use a websocket on top of FastAPI.

But again, don't know how user authentication would work in this case.

Other

I don't see why everything has to map to one input widget. The state is at the component level, so in your autocomplete example you could have both a list of selected states, and a list states for checkboxes. Events triggered inside that component would pass the new state to the server. I might be missing something, but I don't see how that breaks the abstractions here?

This relates to the idea of automatically registering event listeners on the client. In some edge cases you may have user inputs which don't have any corresponding <input> or <form> elements. E.g. I'm displaying a network graph as an SVG and I want to trigger a click event when clicking on an SVG element representing a node in the graph. In that case we're unable to automatically attach the listener. So some escape hatch would be needed.

EmilStenstrom Sep 14, 2025
Maintainer Author

Starting from the end of your comment, I agree that that would need custom event handlers. Maybe the API could be just registering the click event?

class SVG(Component):
    template = "..."

    class State:
        focus: ...

    class Events:
        def click(self, evt, state):
            state.focus = evt.data["target"]
            return SVG.render_to_response(...)

Click would then be a built-in name, that gets registered on the wrapping div of a component. All clicks inside the component would bubble there and get it passed to the server-side, including where you clicked. The component would update the state, and re-render.

vb8448 · 2025-09-21T14:43:45Z

vb8448
Sep 21, 2025

One major risk to consider is latency: even on internal corporate networks, you will have at least ~80/100ms of latency for every roundtrip. Something most users won't notice but, if you start to attach mouse-hover/focus events, it will be immediately noted by users and the UX will fill clunky.

Additionally, any kind of problem between the user and the application (slow network, server load, ecc ecc) will immediately affect UX.

The need of extra dependencies(django-channels & redis) and network roundtrips will increase complexity and make debugging and tracing more complicated.

Think about out of order events: handling clicks locally is deterministic, w/ network in the middle it's no more the case (En can be handled before En-1). This will lead to weird bugs very hard to debug.

8 replies

vb8448 Sep 22, 2025

@EmilStenstrom elixir is a much faster language compared to python, the python/django overhead for many small events will hurt.
Regarding dependencies, as far as you have more than 1 web server you'll need something to share state across instances, unless you implement some kind of sticky routing on the balancer in front of your application (but it comes with its own drawbacks).

@JuroOravec Pyodide is slow, and it's another dependency to handle and pay attention to.

Please don't get me wrong, it's just my 2 cents, but you are trying to resolve something that it's easier and better to do with js and maybe some htmx/unpoly/ecc. You will end with something similar to plotly/dash.

EmilStenstrom Sep 22, 2025
Maintainer Author

@vb8448 Not true, Elixir is not "much faster" than Python. Erlang has better multi-threaded performance since they use lightweight threads, but that won't matter much when we're adding databases and network requests into the mix.

Each app can decide how to use storage. If they use the database or django cache, or redis, is up to each one.

I don't quite get your point. Is it "it's not possible to build a system following the spec above"? If we were to build a system like the above it wouldn't be a good system? Is it that you wouldn't use the system if we built it?

vb8448 Sep 22, 2025

@EmilStenstrom let's say you have an application that needs to handle 50rps at peaks, if you start moving small JS stuff from client-side to backend you will need to design your system to handle much more. How much depends on the functions you are moving, but it can be 2-10x. In this scenario python will be much slower, you will probably also need to consider moving to async ...

"it's not possible to build a system following the spec above"

It's definitively possible to build it, but my point is it makes sense to build it to cover use cases where you anyway will HAVE TO go to the server (like in the live view example you posted) and not for stuff that can stay locally (e.g. memorizing active tab in a specific page).

if we were to build a system like the above it wouldn't be a good system

I think it will add more "headaches"(extra dependencies, network reliability, harder ha deploying, debugging ecc) than problems it solves.

But again, just my 2 cents.

EmilStenstrom Sep 22, 2025
Maintainer Author

The main differences between our perspectives is that i consider JS to be the main headache. Building a modern JS frontend is the same as building the same system twice; once for the backend and then once again in the frontend (in a different language at that!).

You're forcing developers to switch between languages to make the simplest of changes
You are forcing development teams to hire dedicated front-end engineers, because the backend engineers can't handle the frontend
You're committing to another set of build tools, dependency systems, and linting tools, and they are updating at a crazy rate
You put yourself at the mercy of browser differences, and break accessibility and SEO, and so on, and so on...

Some people try to get away from building the system twice by saying that the backend should just be an API. Except, if that was the best path, why would they use DJC at all?

JuroOravec Sep 22, 2025
Maintainer

Yup, no new points from me, but generally if one of your main goals are performance for web dev, you shouldn't pick Python / Django. And so if someone chooses Python / Django for other reasons (like @EmilStenstrom listed), then other aspects may be more important than raw perf.

Agree with @vb8448 that I think people shouldn't use the server-side events for managing state that doesn't necessarily need the server. But that's only a recommendation. It's then up to the individual developers how they will use the available tools. We can't prevent them from doing that.

Coming to Django from JS ecosystem, this narrative took some time getting used to. But the difference is that while my experience with JS web dev was e.g. in a team of 6-7 full stack devs, the opposite extreme of some people using Django or django-components are e.g. single scientist or doctor who are building things on the side.

That's why I suggested the Pyodide approach, and why I suggested to make it easy to switch between Python and JS event handlers. Imagine I'm a Python-first developer:

I first implement the UI with state updated in Python (server-side event), because that's the most convenient way for me to write it - I simply write a Python method, that's what I'm already well familiar with.
Then I notice that ok some interactions are getting slow, so I decide to spend some more time exploring which methods can run in client-only. It will be slow, because it runs in Pyodide, but it should still be faster than having to wait for a whole network roundbout trip. As a Python-first developer, I don't have to go and refresh my mind about how a JS framework X or Y works. I simply had to write a single line in Python to make that change.
Later, I notice that some interactions are still slow. Only now I decide to invest more of my time to e.g. move the logic to purely JS.

On the other hand, somebody as @vb8448 you or me, we might skip to step 3 right away, because we can appreciate the tradeoffs and we've got the skills to do that.

Uh oh!

Design Document: Live Components for django-components #1366

Uh oh!

EmilStenstrom Sep 7, 2025 Maintainer

Executive Summary

Goals

Architecture

Server Side

Client Side

Example Flow

Implementation Plan

Non-Goals (for v1)

Risks & Mitigations

Conclusion

Replies: 3 comments · 12 replies

Uh oh!

Uh oh!

dalito Sep 7, 2025

Uh oh!

Uh oh!

EmilStenstrom Sep 7, 2025 Maintainer Author

Uh oh!

Uh oh!

JuroOravec Sep 14, 2025 Maintainer

On API

Thoughts

Other

Uh oh!

Uh oh!

EmilStenstrom Sep 14, 2025 Maintainer Author

Uh oh!

JuroOravec Sep 14, 2025 Maintainer

RE: API

Websocket vs HTTP vs other

Other

Uh oh!

EmilStenstrom Sep 14, 2025 Maintainer Author

Uh oh!

vb8448 Sep 21, 2025

Uh oh!

vb8448 Sep 22, 2025

Uh oh!

EmilStenstrom Sep 22, 2025 Maintainer Author

Uh oh!

vb8448 Sep 22, 2025

Uh oh!

EmilStenstrom Sep 22, 2025 Maintainer Author

Uh oh!

JuroOravec Sep 22, 2025 Maintainer

Design Document: Live Components for `django-components` #1366

EmilStenstrom
Sep 7, 2025
Maintainer

Replies: 3 comments 12 replies

dalito
Sep 7, 2025

EmilStenstrom Sep 7, 2025
Maintainer Author

JuroOravec
Sep 14, 2025
Maintainer

EmilStenstrom Sep 14, 2025
Maintainer Author

JuroOravec Sep 14, 2025
Maintainer

EmilStenstrom Sep 14, 2025
Maintainer Author

vb8448
Sep 21, 2025

EmilStenstrom Sep 22, 2025
Maintainer Author

EmilStenstrom Sep 22, 2025
Maintainer Author

JuroOravec Sep 22, 2025
Maintainer