State management in large applications

Hello everyone.

I wondering about what strategies people are using to manage component state and communicate changes among components. I find myself doing a lot of self.parent.parent.parent.raise_event, and trying to guess how many levels up the parent is, or when trying to communicate with siblings, doing self.parent...raise_event_in_children - and then having to listen for that event and keep passing it down until I hit the right level.

The docs say to use get_form() and then raise an event, but I often have lots of nested component, and the open form is just a master component.

These are issues for which there are good solutions in the JS world (e.g., redux or vuex), but I am curious if anyone has tried to implement something similar in Anvil.

If not, what are your strategies to manage state when you have a large application with many nested components?

Thank you for your help and thank you for sharing.

Cheers.

Anders.

Just a suggestion. Since event signals don’t flow up (or down) a form’s component hierarchy automatically, a formal, explicit publish-subscribe mechanism is probably the cleanest approach.

Thank you @p.colbert. That is the pattern used by redux and vuex. I am trying to figure out a good way of doing it in Anvil. Have you any experience implementing it in Python/Anvil?

I am going to try to translate this little tutorial to Python (https://levelup.gitconnected.com/learn-redux-by-building-redux-from-scratch-dcbcbd31b0d0), but if anyone already has some code to share, that would be greatly appreciated.

Thank you.

A little Googling has turned up a few different packages that might help. But, most seem stale at this point:

  1. PyDispatcher — stale
  2. Signals (in Django)
  3. PyPubSub — also seems stale

The suggestion in this post seems reasonable, but the store would still need to be initiated from the main form and some how passed down or accessed by all components.

Cheers. A.

I haven’t implemented it myself. But Python has terrific components for doing it, namely dict.

Is this of any use?

  • Accessible by all (client) components -> a self-contained module, using its own global variables. These will persist independently of any Form you might create and/or destroy.
  • I’d consider a Python library stale if it has needed changes recently, but hasn’t received any. For a minimal pub-sub framework, it might not have needed any changes for years.
  • The bigger issue is, is it simple enough to work inside the browser? That means pure Python (no machine-code libraries).
2 Likes

Thank you @david.wylie. I think that might do the trick nicely. I am trying it out now.

For me I try avoiding more that one level of parent as a rule of thumb, and no levels of parent if I can help it. Especially because changing components in and out can create havoc with that type of code in the future.

Lots of parent.parent is probably a good sign that it’s time for some abstraction into a global module, as @p.colbert suggests.

I may also, on occasion, pass an instance of the parent form to the child form’s init method so that it can call methods from the parent directly without having to use parent.parent.parent.