use_mutation exclusivity #132
-
|
Consider the following component, which is displayed using What I find suspicious is that a copy of the component (or any component, for that matter?) would not load in a parallel tab B until the mutation in A completes. I guess that has to do with component caching. In fact, I already have trouble accepting that the two mutations don't run in parallel when invoked from tab A and tab B -- I think the exclusivity should be session-scoped, whether from typing import Callable
from django.utils.timezone import now
from django_idom.hooks import use_mutation
from idom import html, use_state, component
def work(t0, trg: Callable):
import time
time.sleep(10)
trg(now() - t0)
@component
def Main():
sleeper = use_mutation(work)
elapsed = use_state(None)
return html.div(
html.button(
{
'on_click': (lambda e: sleeper.execute(t0=now(), trg=elapsed.set_value)),
'class_name': "btn btn-primary",
'disabled': sleeper.loading,
},
f"Elapsed: {elapsed.value}" if elapsed.value else "use_mutation"
),
) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 9 replies
-
My suspicion is that this has more to do with the synchronous nature of the task. In short, that |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, |
Beta Was this translation helpful? Give feedback.
-
|
The page loads, but the component does not. |
Beta Was this translation helpful? Give feedback.
-
|
@numpde I think the only real solution we have will be to allow you to specify whether your query/mutation is thread sensitive. Unfortunately, as the docs explain, that isn't guaranteed to work. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I've discovered that |
Beta Was this translation helpful? Give feedback.
-
|
Found a similar issue reported here in Django Channels. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately this has been a long standing issue with how Django handles async. They've taken the approach of ensuring ASGI causes zero performance impact to WSGI, which unfortunately leaded to horrible async capabilities. I vaguely recall that Django's thread pool executor can be configured in size, but doing so would break the ORM. |
Beta Was this translation helpful? Give feedback.
-
|
At least based on the report in that issue, setting |
Beta Was this translation helpful? Give feedback.
-
|
Django fundamentally only has a sync ORM stack. But they fake async using thread sensitive Since Django's async API for the ORM are wrapped with their own |
Beta Was this translation helpful? Give feedback.
-
|
Ok, this just seems like something the user should be able to configure if they're confident that their query can be run concurrently then. |
Beta Was this translation helpful? Give feedback.
-
|
I suspect the issue here is related to how Django's async functionality is currently faked within Django Core ( By default everything async that Django does is single threaded. And IDOM currently relies on Django's async stack. We might actually be able to get away with disabling that thread sensitive behavior within IDOM though, since IDOM is technically never executing database queries itself. |
Beta Was this translation helpful? Give feedback.
-
|
This is now being tracked in the following locations and will be resolved soon IssuePull Request |
Beta Was this translation helpful? Give feedback.
-
|
@numpde Can you test out using
It should resolve the issues you're seeing here in one of two ways:
|
Beta Was this translation helpful? Give feedback.
This is now being tracked in the following locations and will be resolved soon
Issue
Pull Request