package rxblocks
- Alphabetic
- Public
- All
Type Members
- class BlockHashPublisher extends SimplePublisher[EthHash, EthHash, BlockFilter]
- class BlockNumberPublisher extends SimplePublisher[BigInt, BigInt, Dummy.type]
- class ConfirmedLogPublisher extends Publisher[Recorded] with Parent[Recorded]
- class LogPublisher extends SimplePublisher[Log, Log, Filter]
- abstract class SimpleProcessor[FROM, TO] extends Processor[FROM, TO] with Parent[TO]
- abstract class SimplePublisher[T, S, F <: Filter] extends Publisher[T] with Parent[T]
- class SimpleSubscription[T] extends Subscription
- final class StubEventProcessor extends SimpleProcessor[Recorded, (SolidityEvent, Metadata)]
- class TestSubscriber extends Subscriber[Any]
Value Members
- object BlockNumberPublisher
- object ConfirmedLogPublisher
- object LogPublisher
- object SimpleProcessor
-
object
SimplePublisher
Unless the chosen filter supports a "fromBlock", there is no way to control precisely at what block a subscription begins.
Unless the chosen filter supports a "fromBlock", there is no way to control precisely at what block a subscription begins. A subscriber receives events "as they happen", and even if they subscribe very quickly after e.g. contract deployment, there can be no guarantee that they won't miss anything.
Fortunately, the most important filters (log filters) do support "fromBlock"
Unfortunately, it seems that clients don't pay attantion to an already-past "fromBlock" in the eth_getFilterChanges most implementations will rly upon.
T is the type that subscribers will receive. S is an intermediate type, that might be acquired then transformed to T. If this is not necessary, just define S to the same type as T. F is the Client.Filter type of the object usually used to specify the items that will get published. (Filter.Dummy can be acquired and left unused if no filter is necessary.)
- object SimpleSubscription