Skip to content

Requestor 1.2.0
Compare
Choose a tag to compare
@reinert reinert released this 01 Oct 18:43
· 65 commits to master since this release
1.2.0
df89a21

This new release adds important improvements to the Store.

Now, we can set a TTL (time-to-live) long when saving data into the store. It represents how long the data is going to be valid. After this period, the data expires and gets removed from the store.

Also, now there are some Store Events that allow us to react when modifications happen to a key.

The existing store events are:

  • Saved Event - it's fired when a new data is saved into the store.
    • It provides us access to the newData that's being saved and also the oldData that was in the key's slot before (null if there was none).
    • We can listen to this event by registering a handler with the onSaved method.
  • Removed Event - it's fired when a data is removed from the store.
    • It provides us access to the oldData that's being removed.
    • We can listen to this event by registering a handler with the onRemoved method.
  • Expired Event - it's fired when a data TTL expires.
    • It provides us access to the oldData that has expired.
    • We can listen to this event by registering a handler with the onExpired method.

In order to listen to any of these events, we need to bind a Store.Handler to a key, like in session.onSaved( "aKey", event -> {} ).

The Store.Handler is a functional interface that receives a Store.Event as the argument. This event object allows us to access both the old data that's being removed/replaced/expired (with event.getOldData()) and the new data that's being saved (with event.getNewData()).

The Store.Data is an object that holds:

  • the value that was saved into the store,
  • the key it was bound to,
  • the ttl that was set for it (default 0) and
  • the createdAt time that it was saved.

Additionally, the Store.Handler provides a cancel() method that we can call to deregister (unsubscribe) the handler from the store.

The Store Events now empower a complete communication-centric approach to building client apps. The basic idea behind it is to share one Session object among all UI components (graphical or not), and use this session to make requests and cache data that must be accessible to everyone. Each UI component can register handlers to listen when data is made available (or unavailable) in the session. We can even break down our session into lower-scope Service objects. People find it useful when they want to follow a subject-oriented design.

Remember Sessions, Services, and Requests have embedded Stores (they wrap their own stores and expose the Store methods). Still, all stores intercommunicate together in a tree structure. Check the Store documentation for more info about it.

Assets 2
Loading