Open Hyperclaw79 opened 3 years ago
What's the use case? The persistent views are only exposed for persistency (i.e. to save to a database)
On use case would be stopping stale views based on changes in the state of the client. For example, if I dynamically disable/reload a particular category of commands, I would want to stop all the views created by the commands from that particular category.
Another use case would be statistical. I could schedule a task which regularly checks for the total number of Views and could calculate the deltas.
Currently I'm using a workaround by manually saving them into a dictionary, but it feels more maintainable if it were a part of the Client itself.
Summary
Ability to access all dispatched views as an attribute of the Client class.
What is the feature request for?
The core library
The Problem
Currently, there seems to be no way to keep a track of all the dispatched (non-persistent) views from the Client's attributes. Adding the ability to iterate over all of them, would be helpful in stopping the required ones using custom logic. For example, if I reload a cog, I would want the ability to stop all the views dispatched from that particular cog.
The Ideal Solution
Have a flag
persistent
which defaults to True in theClient.add_view
which will give us the ability to add non-persistent views as well when required. Then aClient.views
with thepersistent
flag again to get the required ones. This could replace the existingClient.persistent_views
The Current Solution
No response
Additional Context
No response