iter states

[benedikt-bartscher]

import asyncio
import datetime

import reflex as rx
from reflex.utils.prerequisites import get_app


class State(rx.State):
    async def invalidate(self) -> None:
        app = get_app()
        async for state in app.modify_states(from_state=self, substate_cls=State):
            pass

    @rx.var
    def time(self) -> str:
        return datetime.datetime.now().strftime("%H:%M:%S")


def index() -> rx.Component:
    return rx.container(
        rx.text(f"Current time: {State.time}"),
        rx.button("Invalidate State", on_click=State.invalidate),
    )


async def invalidate_lifespan() -> None:
    app = get_app()
    while True:
        async for state in app.modify_states(substate_cls=State):
            pass
        await asyncio.sleep(5)


app = rx.App(lifespan_tasks=[invalidate_lifespan])
app.add_page(index)

[benedikt-bartscher]

@masenf do you have any idea if there is a cool way to automatically detect if modify_states was called from an event handler to check for from_state=self for deadlock prevention?

[benedikt-bartscher]

@masenf do you have any idea if there is a cool way to automatically detect if modify_states was called from an event handler to check for from_state=self for deadlock prevention?

We could also add a BaseState.modify_states partial-like method which calls app.modify_states(..., from_state=self) and advise users to use self.modify_states in event handlers

[picklelo]

Sorry for the delay here. I think the changes look good - we need to rebase this onto main and implement it for StateManagerDisk which is becoming the default in 0.7.0

[benedikt-bartscher]

Sorry for the delay here. I think the changes look good - we need to rebase this onto main and implement it for StateManagerDisk which is becoming the default in 0.7.0

No worries, I just implemented it for StateManagerDisk

[picklelo]

Code works well for me. I'll wait for @masenf 's final approval to merge. What was the use case for this?

[benedikt-bartscher]

Code works well for me. I'll wait for @masenf 's final approval to merge. What was the use case for this?

You can use it for cache invalidation, f.e. to have all blog pages as infinitely cached computed vars and invalidate/reload them globally if a page changes.

Maybe we could later use it for some kind of state migration.

[benedikt-bartscher]

Will rebase if there is intention to merge this

[masenf]

the main problem i forsee with this feature is that it works great in testing/dev mode, and then once it's deployed prod with redis, some clients are not going to get deltas sent when their state is modified, because they're connected to a different instance of the app than where this API is used.

it's not a new problem, we've had it for a long time. but currently there is no mechanism for an app instance to send a delta to a client that is connected to a different instance. @Lendemor had a WiP to handle this, but i think it's closed without merging.

[masenf]

can we make this new function get_app_instance and leave get_app the way it was, to retain as much compatibility as possible

[masenf]

unfortunately this wont work anymore, because we started hashing the token to avoid file path limits on windows.

however, we should be able to use the same implementation here as we do for StateManagerMemory as the on-disk pickles are only read when the backend starts after a hot reload

[Lendemor]

Marking this as draft until ready for review.

[benedikt-bartscher]

it's not a new problem, we've had it for a long time. but currently there is no mechanism for an app instance to send a delta to a client that is connected to a different instance. @Lendemor had a WiP to handle this, but i think it's closed without merging.

Thanks for the review. Yes, that's currently a limitation, but i think it can be implemented with redis pub/sub and some maps.
Do you mean this PR #2819 ?