π Glossary
This glossary provides comprehensive definitions for key concepts in reactive programming with samber/ro. Use this as a quick reference when exploring the documentation.
Reactive Programmingβ
A programming paradigm focused on event-driven applications, data streams and the propagation of change. This is the foundation that libraries like samber/ro are built upon.
See About for a detailed introduction to reactive programming concepts.
Observableβ
A source that emits a sequence of data or events over time. This is the core building block of reactive programming in samber/ro.
Learn more about Observables in the basics guide.
Observerβ
An entity that subscribes to an Observable to receive updates or notifications. Observers handle the three types of events: Next, Error, and Complete.
See Observer documentation for detailed implementation patterns.
Subscriptionβ
Represents the relationship between an Observable and an Observer, enabling the flow of data. Proper subscription management is crucial for preventing resource leaks.
Learn about Subscription management best practices.
Subscriberβ
An entity that reacts to values, errors, or completion signals from an Observable.
Subjectβ
A hybrid type that acts as both an Observable and an Observer, enabling multicasting. Subjects are essential for creating hot observables and shared streams.
Explore different Subject types and their use cases.
Streamβ
A sequence of asynchronous events or data values emitted over time.
Event Loopβ
A loop that waits for and dispatches events or messages in a reactive system.
Hot vs Coldβ
Classification of Observable based on whether emission occurs independently (hot) or per Subscription (cold). Understanding this distinction is crucial for proper stream behavior.
See getting started guide for practical examples.
Hot Observableβ
An Observable that emits values regardless of subscriptions; shared among all subscribers. Useful for events like mouse clicks or sensor data.
Learn how to create hot observables using Subjects.
Cold Observableβ
An Observable that starts emitting values only when a Subscriber connects, producing a fresh sequence each time. This is the default behavior in samber/ro.
Backpressureβ
A strategy to handle situations where data is produced faster than it can be consumed. In samber/ro, backpressure is handled naturally through blocking behavior.
See Backpressure for more details.
Operatorβ
A function or method that transforms, filters, or combines data streams. Operators are the building blocks that make reactive programming powerful and expressive.
Explore the complete Operators reference and usage guide.
Multicastingβ
Sharing a single stream of data with multiple subscribers.
Streams processingβ
The continuous processing of data as it flows through a system, often in real time and distributed fashion, allowing applications to react to events, transform data, and trigger actions immediately as data arrives. Unlike batch processing, which handles data in large chunks, stream processing works on individual events or small windows of data.
Batch processingβ
A data processing approach where large volumes of data are collected and processed together as a single unit or βbatch.β Unlike stream processing, which handles data continuously in real time, batch processing executes tasks on the accumulated data at scheduled intervals.
Asynchronousβ
Execution that happens independently of the main program flow, often without blocking. samber/ro is mostly synchronous.
Event-Drivenβ
A programming style where changes in state or external events trigger the execution of code. This is central to reactive programming and samber/ro's design.
Read more about reactive programming concepts in the About section.
Push Modelβ
A data flow model where producers push updates to consumers automatically. This is where reactive programming library such as samber/ro sit.
Compare with Pull Model and see Observer for practical implementation.
Pull Modelβ
A model where consumers request data from producers when needed.
Completionβ
A signal indicating that an Observable has finished emitting values.
Error Handlingβ
Mechanisms to manage errors that occur during the emission of data streams. Proper error handling is essential for building robust reactive applications.
Learn about error handling patterns in the troubleshooting guide.
Replayβ
A technique where a stream retains past values and can replay them to new subscribers.
Collectorβ
Capturing the values of a stream so the main thread can immediately use it.
Schedulersβ
Components controlling when and where stream events are emitted and observed. samber/ro has no scheduler, since Go offer first-class citizen concurrency.
This differs from other reactive libraries that require explicit scheduling for concurrency management.
Concurrencyβ
Executing multiple tasks simultaneously in a reactive system.
Non-blockingβ
Designing operations so they donβt block the main execution thread.
Transformation operatorsβ
Converting one stream of data into another, often using operators. This is one of the most common operations in reactive programming pipelines.
See Operators guide for examples and best practices.
Filtering operatorsβ
Selecting specific data from a stream based on certain criteria. Essential for reducing data volume and focusing on relevant information.
Explore filtering operators in the Operators reference.
Composition operatorsβ
Combining multiple streams or operations to create more complex reactive behavior. Composition is key to building sophisticated data processing pipelines.
Learn about stream composition in the getting started guide.