Allow users to react to certain events
- Vorherrschende Sprache
- Rust
- Sterne
- 78
- Forks
- 129
- Ø Merge
- 4 T. 14 Std.
- Gemergte PRs (30 T.)
- 52
Beschreibung
As a user, you might be interested in note flows and lifecycles specific to your application only. In this sense, the client does not currently provide many mechanisms to programmatically react to events in a specific manner. In other words, in order to update the local view of the blockchain, the user needs to periodically call the `Client::sync_state()` API which updates the local entities based on the information that it requests and receives. These information is, in turn, based on the previous state (for example, nullifiers are requested for any note that the store is tracking as `Committed`) and tags (which can be added and removed by the user).
It would be useful for the user to have a way to react to certain events. In general, any received updates might be of interest to the user depending on the application, but some that come to mind as important are:
- Notes matched by tags: It might be of interest to the user to update some other part of the application state based on received notes, or decide which received notes are stored, since tags only partially provide this functionality. This is somewhat related to the `NoteScreener` which already does this filtering, so perhaps it could be solved by adding a way to programmatically add checks here.
- Notes being consumed (matched nullifiers).
- Transactions getting committed/canceled: This might not be as important, since reacting to updates is currently virtually similar to just manually searching for transactions after syncing. Perhaps this can be solved with just changing the APIs accordingly (for instance, just returning a list of rejected and accepted transactions after a sync).
The mechanisms through which the user could react to these events (event queues that can be consumed, trait objects, callbacks, channels, etc.) can be discussed separately.
Beitragsleitfaden
Rechercherichtung
Betrachten Sie die Client::sync_state()-API und den NoteScreener, um den aktuellen Aktualisierungsfluss zu verstehen. Untersuchen Sie, wie Notes, Nullifiers und Transaktionen im Store verfolgt werden. Bestimmen Sie, wo Callbacks oder Event-Queues eingefügt werden sollen, und entwerfen Sie ein Trait oder eine Channel-Schnittstelle für Benutzerreaktionen. Tests umfassen das Simulieren von Blockchain-Ereignissen und die Überprüfung, ob Benutzer-Callbacks ausgelöst werden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- rust
- Bereich
- backend-api-design
- Issue-Typ
- Feature
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100