@rmorshea I need your opinion on theuse_user_data API. To save you some time, here's the short and sweet summary:

use_user_data allows you to store or retrieve data specific to the connection'sUser object. Thisuser_data is persistently stored within the database and can be accessed like such:

fromreactpyimportcomponent,htmlfromreactpy_django.hooksimportuse_user_data@componentdefmy_component():# user_data properties: current, loading, error# user_data callable attributes: refetch# set_user_data properties: loading, error# set_user_data callable attributes: __call__, resetuser_data,set_user_data=use_user_data()# Here's an example that uses most of the APIasyncdefon_key_press(event):ifevent["key"]=="Enter":# User data is always a dictmerged_data=user_data.current| {uuid4():event["target"]["value"]}set_user_data(merged_data)returnhtml.div(html.input({"placeholder":"Type some user data here...","on_key_press":on_key_press}),html.div(f"Data:{user_data.current}"),html.div(f"Data Loading:{user_data.loading}"),html.div(f"Set Data Loading:{set_user_data.loading}"),html.div(f"Error(s):{user_data.error}{set_user_data.error}"),    )

To get the conversation started, here's a few questions/concerns I have:

1. Does it make sense thatuser_data.current returns a dict?
2. Does splitting the interface intouser_data, set_user_data feel right?
3. Is theset_user_data interface clear and logical? The interface is identical touse_mutation.
4. Is theuser_data interface clear and logical? This interface is different thanuse_query interface in the fact that thedata attribute was renamed tocurrent (user_data.data looked weird to me).

I'll try and take a look in the next couple days.

Would you have time to look at the interface proposed in theabove comment this weekend?

This PR is fairly bulky and has a lot of Django-only jargon, so a PR review won't be needed.

Sure. I'll make time today or tomorrow.

My take is that the marginal UX improvements made by creating special wrappers for the query and mutation objects may be outweighed by requiring the user to learn something new. It seems easier to explain to the user thatuse_user_data returns a tuple with a query and a mutation.

To address some of the usability concerns in a slightly simpler way, we could consider adding a__call__ method to mutations and returning a named tuple fromuse_user_data so usage would be

user_data=use_user_data()# access datauser_data.query.datadefsome_callback():new_user_data=user_data.query.data| {...}user_data.mutation(new_user_data)

Agreed, will implement soon.