`use_database_state` hook about reactpy-django HOT 8 CLOSED

I imagine the usage should look like either:

results = use_database(lambda: Model.objects.all())

@use_database
def results():
    return Model.objects.all()

The implementation might look like:

def use_database(function, initial_value=None):
    result, set_result = use_state(initial_value)

    query_function = use_callback(query_function)
    async_function = use_memo(lambda: database_sync_to_async(function))

    @use_effect
    async def exec_function():
        output = await async_function()
        if isinstance(output, QuerySet):
            bool(output)
        set_result(output)

    return result

from reactpy-django.

With that kind of interface, how would someone edit an entry and then save changes?

There needs to be some way of performing .save() operations via database_sync_to_async

from reactpy-django.

Wouldn't one typically do that in response to some sort of event, in which case you'd be able to define an async handler that does this?

from reactpy-django.

You're right though, that does feel a bit disjointed. Maybe the interface ought to be more like use_state for single record access.

model, set_model = use_one_model(
    Model.objects.get(...)  # assuming query exec is delayed
)

async def handle_event():
    await set_model(attr=...)

from reactpy-django.

I'm not really sure how this should work for bulk access though...

from reactpy-django.

Actually, there's a deeper issue here around object identity where the declarative nature of IDOM and the imperative nature of Django clash - Django expects you to modify an object to update it in the database, but IDOM uses object identity to infer whether something has changed. For example, imagine using a model in a use_memo hook:

model, set_model = use_one_model(...)
something_expensive = use_memo(lambda: compute_something_expensive(model))

A naive implementation of use_one_model would mutate model, call model.save() and, on the next render, return the same model instance. But in order to know whether something_expensive needs to be re-computed, IDOM looks at the identity of model. If model is the same object, then something_expensive won't be re-computed. Thus you'd encounter a bug where, despite calling set_model, something_expensive would not receive a corresponding update.

It almost feels like there needs to be a thin declarative wrapper around Django's models...

from reactpy-django.

While Django models might be mutable (haven't confirmed), I know that Django querysets are immutable. The lazy nature of things is the biggest issue though. I haven't been able to find a good solution to that yet.

Also, I believe accessing Model.objects needs to occur within a sync context.

I honestly think the best solution to this might end up being a monkey patch to the Django Model object...

from reactpy-django.

Closing this.

I think it no longer makes sense given the existence of use_query, and may not be technologically feasible.

from reactpy-django.