Instead of augmenting _get_imports with a weird, slow, recursive crawl and
dictionary reconstruction, just use the imports that we compile into the
components.js file to install frontend packages needed by the custom
components.
Same effect, but adds essentially zero overhead to the compilation.
* Get `client_ip` from `asgi.scope`
It seems like REMOTE_ADDR is always 127.0.0.1, which is not super useful when
trying to figure out where the websocket connection is originating from.
Of course this isn't a silver bullet because most-likely the WS will be passed
through a reverse proxy anyway... in that case, the client IP is likely in the
headers under `x_forwarded_for`
* client_ip: fallback to REMOTE_ADDR
Control whether multiprocessing is used and the number of processes or threads
that should be used.
This will allow users to opt-in to the new, potentially hazardous,
multiprocessing mode, which results in much faster compiles, but has already
been reverted 4 times. Lets leave the code in this time, but use the thread
pool executor by default.
Limiting the number of threads or processes to 1 can also aid in debugging
issues that arise during compile time.
* Make @rx.memo work with state vars passed as props
Seems like this was a regression from the StatefulComponent refactor, because
trying to pass a state Var to a CustomComponent gave undefined, likely due to
`_get_vars` not accounting for `self.props` in CustomComponents.
With this change, it works.
Integration test added to `test_var_operations.py`
* Allow CustomComponent props to be Component
Avoid calling `.json()` on all Base types because the Var serializer already
does that, but this way, more specific types (like Component) can be serialized
differently.
When the type is Component, attach a VarData with the imports and hooks to when
the Var is rendered, it also carries the correct imports/hooks and does not
throw frontend errors.
* [REF-2158] Enable state when `on_load` or event_triggers are set.
Basically all events in a reflex app require the backend to be up, even the
built-in server side events round trip to the backend and require "state" even
if no user-defined state classes are declared.
test_app_state_determination: checking that state is enabled at the right time
* Clear out DECORATED_PAGES when initializing a new app
* rebase
* pass include_children kwarg in radix FormRoot
* respect include_children
* ruff fixes
* readd statemanager init, run pyi gen
* minor performance imporovements, fix for state changes
* fix pyi and pyright
* pass include_children for chakra
* remove old state detection
* add test for unused states in stateless app
---------
Co-authored-by: Masen Furer <m_github@0x26.net>
* [REF-1368] Move common form functionality to rx.el.forms
Allow plain HTML Form element to have magic on_submit event handler.
* Chakra and Radix forms inherit `on_submit` functionality from rx.el.form
Consolidate logic in the basic HTML form and use it in both Radix and Chakra
form wrappers.
* from __future__ import annotations for py38
* [REF-2098] Allow overlay Close components to have on_click handlers
The child of the Radix *Close components are passed `asChild`, meaning they are
treated as the direct child of the Close itself. This causes the `on_click`
handler attached to such an element to override the default `on_click` behavior
of the Close, which is to close the overlay, thus breaking the desired behavior
of the Close component.
When creating a Close component, if the child has an `on_click` handler, then
internally wrap it in a `Flex` so that the `Flex` gets the `asChild` treatment,
and both the default on_click and the child's on_click are both fired.
Bonus fix: pass `asChild` when constructing the `DrawerClose` to avoid a
<button> in <button> warning in the browser console, because the Drawer does
NOT pass `asChild` to the Close by default.
* Move Trigger logic to RadixThemesTriggerComponent base class
Apply trigger logic to Trigger, Close, Cancel, and Accept components; including
hover_card and dropdown_menu.
The ThemePanel fights with the ThemeProvider when the user color preference key differs from the `appearance` prop specified in the theme. To avoid issues when using the ThemePanel (in development), clear out the user color preference before loading the page and before unloading the page (to ensure it does not freeze on reload).
Clearing the user preference isn't ideal production behavior, but typically the
ThemePanel is only used during development for trying out different styles, and
having it not freeze the app is better dev behavior.
Fix#2650
* types: remove runtime imports from `is_generic_alias`
Reduce try/except contexts for better performance.
* _decode_var optimizations:
* compile the regex once at module scope
* fast path string scan for REFLEX_VAR_OPENING_TAG before doing more complex logic
* Avoid repeated `hasattr` check in `is_union`
`is_union` gets called a lot, and the hasattr check can be resolved at import
time for better performance.
* Expose `on_drop` event trigger for rx.upload component.
If `on_drop` is provided, it should be an EventSpec accepting the special
rx.upload_files() arg.
When `on_drop` is provided, it will be called immediately when files are
selected. The default functionality of saving a file list to be uploaded later
will not be available.
* update pyi file
* Undeprecate explicit EventChain
* [REF-2087] Better rx.progress styling integration with radix themes
Support the `radius` prop on `ProgressRoot`, via data-radius and CSS tokens
Support the `color_scheme` on `ProgressIndicator`, via data-accent-color and CSS token
Move high-level `Progress` to a real `Component` subclass to get better pyi hinting
Allow overriding the background color of the `ProgressIndicator` via low-level api
Remove `value` and `max` props from `ProgressRoot` (these only apply to `ProgressIndicator`)
* Progress: do not pass `value` or `max` to ProgressRoot
* progress: use background_color instead of background-color
* Expose reflex.utils.exec.is_prod_mode
Formalize runtime checking of the app's `--env` parameter.
* app_module_for_backend: wait for _compile in prod mode
Prod mode uses separate worker processes that fork from the main process.
If the app is not fully compiled when the fork occurs, any further changes to
the app (like mounting the _upload endpoint) will not be reflected in the
workers. This is not a performance hit because compile is skipped anyway
for backend processes and hot reload is not in the picture for prod mode.
* remove _is_dev_mode and replace it with calls to is_prod_mode()
_is_dev_mode was a private function in the compiler, but now that utils.exec
exposes is_prod_mode, we should use that throughout for consistency
* docker-example overhaul
Update docker-example with a more realistic multi-compose deployment, and
also a more simplistic single-image deploy.
* Use `uv` for faster bootstrapping
* Separate simple and production-ready docker files
* Split compose.yaml into 3 parts
* Persist sqlite db and tls keys
* Include postgres and redis
* Include Adminer and redis-commander for adminstration
* Suppose upload persistence
* Update documentation
* Update Caddyfile for compatibility with new Upload API
* Simple Dockerfile: keep `reflex export --frontend-only`
Pre-pack the resulting image with npm dependencies to reduce startup time
* Simplify simple docker file to just use pip
* test_potentially_dirty_substates: when a state named State should be computed
Catch a regression introduced in 0.4.3a1
* _potentially_dirty_substates: qualify substate name
When looking up substate classes, ensure the qualified name is used to avoid
issues with same-named substates.
