Track state variable and attribute usage #2429
Conversation
benedikt-bartscher
force-pushed
the
track-used-vars
branch
from
ebe49d6 to
b9b26c2
Compare
|
Will have to continue holding off on this one for the time being, because it breaks with the reflex.dev website. Flexdown currently redefines State classes multiple times per doc file, so they lose their _is_used markers. |
benedikt-bartscher
force-pushed
the
track-used-vars
branch
from
63720e8 to
e6b4d5e
Compare
benedikt-bartscher
force-pushed
the
track-used-vars
branch
from
8191379 to
63bf792
Compare
benedikt-bartscher
force-pushed
the
track-used-vars
branch
from
63bf792 to
b5db17f
Compare
benedikt-bartscher
changed the title
|
Needs #3214 for flexdown |
The import needs to occur inside the function, because the function body is taken out of context and placed into a separate app module. Nothing outside of the function will be in-scope. Additionally `mark_used` on the FormSubmitName test app as well.
benedikt-bartscher
force-pushed
the
track-used-vars
branch
from
25b3680 to
89fa7b2
Compare
@masenf I just rebased onto main and tested this locally with flexdown branch benedikt-bartscher/per-block-module, and it seems to work fine. However, reflex-web ci is still failing |
Co-authored-by: coolstorm <manas.gupta@fampay.in>
When a parent state proxy is set, also allow child StateProxy._self_mutable to override the parent's `_is_mutable()`.
…plate during init (reflex-dev#3750)
|
@masenf did you release a new flexdown version yet? |
|
@benedikt-bartscher I just cut a new version of flexdown 0.1.5a10 off the latest main |
|
Thank you, @picklelo. I just raised reflex-dev/reflex-web#855 |
|
Finally, reflex-web ci is passing, thanks again @picklelo and @masenf. |
|
Converted to draft because #3743 was merged. This needs some love to work with the new Immutable Vars |
|
@masenf @adhami3310 do you have any hints/ideas on how to implement this for ImmutableVar's? |
Since immutable vars can't have such fields, it could be possible to have a state-level mapping between vars and if they are used or not, although it will be fairly tricky to implement. I'm not sure however how this will be that strong of an optimization considering that in an ideal application (almost) all vars will be used somewhere in the code, rendering all of the operations we do to figure out if a variable is being used unnecessary. Another issue is that it would slow down compile times (even further). Is there unseen advantages I'm missing? |
|
Thanks for your feedback. You are right, it might introduce some additional compile time. But I think it should be possible without too much overhead, and (at least for us) runtime performance is more important.
Some examples:
Another advantage of usage tracking is automatic serialization of python/sqla/... properties if they are used in the frontend. |
|
@adhami3310 I completely forgot about one of the biggest benefits. Sorry, it has been a long time since I started this PR. Reflex currently always serializes complete root-level vars. Meaning, if you have f.e. a |
|
Closing this, continue here: #3845 |
Track if
rx.Vars and their attributes are used (directly or via var operations) and only include used variables in the state dict. This should result in reduced initial state payloads and network traffic for var changes, which are not really needed in the frontend.My plan is to write a second PR based on this one, which includes "used" properties (normal python properties with
@propertydecorator) in the serialization. This allows users to use those properties in the frontend without always computing all properties for a given class. (related to my comment here)Co-Author: @macmoritz