Learn reactive programming
A BehaviorSubject can remember the latest value emitted, but what if we wanted Observer B to see all the previous values emitted in the past? We can't do that with BehaviorSubject, but there is ReplaySubject, which allows us to do that. This lessons teaches you everything you need to know about ReplaySubjects.
The way we use publish() (or multicast with an RxJS Subject) makes the shared Observable not reusable if the shared execution happens to complete or emit an error. In this lesson we will see how to use a simple Subject factory function in order to create a new Subject, one for each shared execution, whenever connect() is called.
Because using multicast with a new Subject is such a common pattern, there is a shortcut in RxJS for this: the publish() operator. This lesson introduces publish() and its variants publishReplay(), publishBehavior(), publishLast(), share(), and shows how they simplify the creation of multicasted Observables.
ConnectableObservable has the connect() method to conveniently dictate the start of the shared execution of the source Observable. However, we need a mechanism to dictate the stop of the shared execution, otherwise a leak happens. This lesson will teach you how to do that, and it's all about Subscriptions.
With the connect() method on a ConnectableObservable, the programmer is responsible for avoiding leaked executions of shared RxJS Observables. This lesson will teach you about refCount(), a handy operator that creates an automatically connected Observable, to avoid manually using connect().
We have seen how Subjects are useful for sharing an execution of an RxJS observable to multiple observers. However, this technique requires some laborious setting up. In this lesson we will learn about the multicast() operator which helps solve the same problem with less code, and with a neater API.
This lesson teaches you how a Subject is simply a hybrid of Observable and Observer which can act as a bridge between the source Observable and multiple observers, effectively making it possible for multiple observers to share the same Observable execution.
Let's conclude this course by reviewing what an Observable is: a way of representing many values being delivered in push-style from a lazy producer to a consumer. Let's also see how the Observable alone is not everything in RxJS. It serves as the foundation to operators, which are the most useful feature of RxJS.
As developers, we tend to carry over ideas from past experience and try to reapply them to something new. This lesson teaches you about why you should usually favor
subscribe and why thinking about
subscribe as an event handler can lead to problems.
This lesson shows what can be learned next as a continuation of this course, and gives a recap on the core concepts: main for pure logic, drivers for side effects, run() to connect main and drivers, sources for read effects, sinks for write effects, and nesting Cycle.js apps to work as components.
Our app is not yet a BMI calculator, because it only has two sliders, but doesn't show the calculated BMI number. In this lesson we will learn how to export any stream from a child component and use it in the parent component, in order to display the BMI calculation on the DOM.
We added classNames to pre-processing and post-processing steps when calling the LabeledSlider, in order to instances independent of each other. It would be better if we could hide these steps away. This lesson introduces the isolate() helper function to achieve that.
We have made a Cycle.js app for generic labeled slider which can be configured through props, but how can we reuse it in other Cycle.js apps? This lesson shows how we can embed any Cycle program inside a larger Cycle program in a very simple manner.
We are starting to get a better architecture for these UI apps. But we still have a problem of repeating code for the sliders, since they share so much in common in looks and functionality. This lessons shows how we can create a generic labeled slider as a main() function receiving properties as sources.
We built the BMI calculator all inside one function: main(). As apps scale, we don't want main() to grow. We need an organized pattern where each function focuses on doing one thing. This lesson shows how we can easily refactor the main() function into three parts: Intent, Model, and View.
Usually we use template languages like Handlebars, JSX, and Jade to create. One simple way we can create our own template language is to write a function that returns these objects for us. This lessons shows how we can use these functions as a DSL to create our DOM description objects.
What if we wanted to change the behavior of our app reset the timer every time the mouse hovers over it? Currently we only support clicks, and they are hard coded in the DOM Driver. This lesson will introduce DOMSource.selectEvents(), a way of making the DOM Source rich and allowing the main() function to determine which read effects it needs.
Our previous toy DOM Driver is still primitive. We are only able to send strings as the textContent of the container element. We cannot yet create headers and inputs and all sorts of fancy DOM elements. In this lesson we will see how to send objects that describe what elements should exist, instead of strings as the DOM sink.
Our application was able to produce write effects, through sinks, and was able to receive read effects, through the DOM sources. However, the main function only gets the DOMSource as input. This lessons shows how we can generalize main to receive an object of sources, containing all kinds of read effects that we can use.
So far we only had effects that write something to the external world, we are not yet reading anything from the external world into our app. This lesson shows how we can change the DOM Driver to return a "DOM Source" representing read effects, such as click events. We will leverage that to create an interactive application.
The last part of the code we wrote is neither logic nor effects. It is code which ties together logic (main) with effects. We can encapsulate that in a run() function. This lesson shows how we can structure these pieces together, and generalize effect handling with "drivers".
Yolk is a small library that works in tandem with RxJS to render handle events and render out HTML using JSX. If you already understand RxJS, Yolk is a very simple addition to your front-end toolbelt. If you're just learning RxJS, Yolk is also an excellent way to practice using Observable and figuring out how they work together by building familiar UI applications.