List of things to see
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.
Now you should have a good idea what Cycle.run does, and what the DOM Driver is. In this lesson, we will not build a toy version of Cycle.js anymore. Instead, we will learn how to use Cycle.js to solve problems. We will start by making a simple Hello world application.
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".