Settings
Overview¶
These are ReactPy-Django's default settings values. You can modify these values in your Django project's settings.py
to change the behavior of ReactPy.
Note
The default configuration of ReactPy is suitable for the vast majority of use cases.
You should only consider changing settings when the necessity arises.
General Settings¶
REACTPY_URL_PREFIX
¶
Default: "reactpy/"
Example Value(s): "rp/"
, "render/reactpy/"
The prefix used for all ReactPy WebSocket and HTTP URLs.
REACTPY_DEFAULT_QUERY_POSTPROCESSOR
¶
Default: "reactpy_django.utils.django_query_postprocessor"
Example Value(s): "example_project.postprocessor"
, None
Dotted path to the default reactpy_django.hooks.use_query
postprocessor function.
Postprocessor functions can be async or sync. Here is an example of a sync postprocessor function:
def postprocessor(data):
del data["foo"]
return data
Set REACTPY_DEFAULT_QUERY_POSTPROCESSOR
to None
to disable the default postprocessor.
REACTPY_AUTH_BACKEND
¶
Default: "django.contrib.auth.backends.ModelBackend"
Example Value(s): "example_project.auth.MyModelBackend"
Dotted path to the Django authentication backend to use for ReactPy components. This is only needed if:
- You are using
settings.py:REACTPY_AUTO_RELOGIN=True
and... - You are using
AuthMiddlewareStack
and... - You are using Django's
AUTHENTICATION_BACKENDS
setting and... - Your Django user model does not define a
backend
attribute.
REACTPY_AUTO_RELOGIN
¶
Default: False
Example Value(s): True
Enabling this will cause component WebSocket connections to automatically re-login users that are already authenticated.
This is useful to continuously update last_login
timestamps and refresh the Django login session.
Performance Settings¶
REACTPY_DATABASE
¶
Default: "default"
Example Value(s): "my-reactpy-database"
Multiprocessing-safe database used by ReactPy for database-backed hooks and features.
If configuring this value, it is mandatory to configure Django to use the ReactPy database router:
DATABASE_ROUTERS = ["reactpy_django.database.Router", ...]
REACTPY_CACHE
¶
Default: "default"
Example Value(s): "my-reactpy-cache"
Cache used by ReactPy, typically for caching disk operations.
We recommend using redis
, memcache
, or local-memory caching
.
REACTPY_BACKHAUL_THREAD
¶
Default: False
Example Value(s): True
Configures whether ReactPy components are rendered in a dedicated thread.
This allows the web server to process other traffic during ReactPy rendering. Vastly improves throughput with web servers such as hypercorn
and uvicorn
.
This setting is incompatible with daphne
.
REACTPY_ASYNC_RENDERING
¶
Default: False
Example Value(s): True
Configures whether to use an async ReactPy rendering queue. When enabled, large renders will no longer block smaller renders from taking place. Additionally, prevents the rendering queue from being blocked on waiting for async effects to startup/shutdown (which is typically a relatively slow operation).
This setting is currently experimental, and currently no effort is made to de-duplicate renders. For example, if parent and child components are scheduled to render at the same time, both renders will take place even though a single render of the parent component would have been sufficient.
REACTPY_DEFAULT_HOSTS
¶
Default: None
Example Value(s): ["localhost:8000", "localhost:8001", "localhost:8002/subdir"]
The default host(s) that can render your ReactPy components.
ReactPy will use these hosts in a round-robin fashion, allowing for easy distributed computing. This is typically useful for self-hosted applications.
You can use the host
argument in your template tag to manually override this default.
REACTPY_PRERENDER
¶
Default: False
Example Value(s): True
Configures whether to pre-render your components via HTTP, which enables SEO compatibility and reduces perceived latency.
During pre-rendering, there are some key differences in behavior:
- Only the component's first paint is pre-rendered.
- All
connection
hooks will provide HTTP variants. - The component will be non-interactive until a WebSocket connection is formed.
- The component is re-rendered once a WebSocket connection is formed.
You can use the prerender
argument in your template tag to manually override this default.
Stability Settings¶
REACTPY_RECONNECT_INTERVAL
¶
Default: 750
Example Value(s): 100
, 2500
, 6000
Milliseconds between client reconnection attempts.
REACTPY_RECONNECT_BACKOFF_MULTIPLIER
¶
Default: 1.25
Example Value(s): 1
, 1.5
, 3
On each reconnection attempt, the REACTPY_RECONNECT_INTERVAL
will be multiplied by this value to increase the time between attempts.
You can keep time between each reconnection the same by setting this to 1
.
REACTPY_RECONNECT_MAX_INTERVAL
¶
Default: 60000
Example Value(s): 10000
, 25000
, 900000
Maximum milliseconds between client reconnection attempts.
This allows setting an upper bound on how high REACTPY_RECONNECT_BACKOFF_MULTIPLIER
can increase the time between reconnection attempts.
REACTPY_RECONNECT_MAX_RETRIES
¶
Default: 150
Example Value(s): 0
, 5
, 300
Maximum number of reconnection attempts before the client gives up.
REACTPY_SESSION_MAX_AGE
¶
Default: 259200
Example Value(s): 0
, 60
, 96000
Maximum seconds a ReactPy component session is valid for. Invalid sessions are deleted during ReactPy clean up.
ReactPy sessions include data such as *args
and **kwargs
passed into your {% component %}
template tag.
Use 0
to not store any session data.
Auto-Clean Settings¶
REACTPY_CLEAN_INTERVAL
¶
Default: 604800
Example Value(s): 0
, 3600
, 86400
, None
Minimum seconds between ReactPy automatic clean up operations.
After a component disconnection, the server will perform a clean up if this amount of time has passed since the last clean up.
Set this value to None
to disable automatic clean up operations.
REACTPY_CLEAN_SESSIONS
¶
Default: True
Example Value(s): False
Configures whether ReactPy should clean up expired component sessions during automatic clean up operations.
REACTPY_CLEAN_USER_DATA
¶
Default: True
Example Value(s): False
Configures whether ReactPy should clean up orphaned user data during automatic clean up operations.
Typically, user data does not become orphaned unless the server crashes during a User
delete operation.