9 |
10 |
11 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | The MIT License (MIT)
2 |
3 | Copyright (c) 2015 Andre Staltz
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Cycle.js documentation site
2 |
3 | cyclejs.github.io
4 |
5 | Built with Jekyll
6 |
7 | [](http://js.org)
8 |
9 | ## Why are Issues unavailable?
10 |
11 | We use only one repository for issues. [**Open the issue at Cycle Core repo.**](https://github.com/cyclejs/core/issues)
12 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | title: "Cycle.js"
2 | author: "Andre Staltz"
3 | description: "A functional and reactive JavaScript framework for predictable code"
4 | more: "read more"
5 | url: "http://cycle.js.org/"
6 | permalink: none
7 |
8 | excerpt_separator: "\n\n\n"
9 | defaults: [{scope: {path: ""}, values: {layout: "default"}}, {scope: {path: "", type: "posts"}, values: {comments: true}}]
10 | gems:
11 | - octopress-autoprefixer
12 | - kramdown
13 | - jekyll-redirect-from
14 | whitelist:
15 | - jekyll-redirect-from
16 |
--------------------------------------------------------------------------------
/_includes/footer.html:
--------------------------------------------------------------------------------
1 |
6 |
--------------------------------------------------------------------------------
/_includes/homepage-content.md:
--------------------------------------------------------------------------------
1 |
Your app and the external world as a circuit
2 |
3 |
4 | {% include /img/cycle-nested-frontpage.svg %}
5 |
6 |
7 | Cycle's core abstraction is your application as a pure function `main()` where inputs are read effects (*sources*) from the external world and outputs (*sinks*) are write effects to affect the external world. These I/O effects in the external world are managed by *drivers*: plugins that handle DOM effects, HTTP effects, etc.
8 |
9 | The internals of `main()` are built using Reactive Programming primitives, which maximizes separation of concerns and provides a fully declarative way of organizing your code. The *dataflow* is plainly visible in the code, making it readable and traceable.
10 |
11 | ## Example
12 |
13 | {% highlight text %}
14 | npm install xstream @cycle/xstream-run @cycle/dom
15 | {% endhighlight %}
16 |
17 | {% highlight js %}
18 | import {run} from '@cycle/xstream-run';
19 | import {div, label, input, hr, h1, makeDOMDriver} from '@cycle/dom';
20 |
21 | function main(sources) {
22 | const sinks = {
23 | DOM: sources.DOM.select('.field').events('input')
24 | .map(ev => ev.target.value)
25 | .startWith('')
26 | .map(name =>
27 | div([
28 | label('Name:'),
29 | input('.field', {attrs: {type: 'text'}}),
30 | hr(),
31 | h1('Hello ' + name),
32 | ])
33 | )
34 | };
35 | return sinks;
36 | }
37 |
38 | run(main, { DOM: makeDOMDriver('#app-container') });
39 | {% endhighlight %}
40 |
41 |
42 |
43 |
44 | ## Functional and Reactive
45 |
46 | Functional enables "predictable" code, and Reactive enables "separated" code. Cycle.js apps are made of pure functions, which means you know they only take inputs and generate predictable outputs, without performing any I/O effects. The building blocks are reactive streams from libraries like [xstream](http://staltz.com/xstream), [RxJS](http://reactivex.io/rxjs) or [Most.js](https://github.com/cujojs/most/), which greatly simplify code related to events, asynchrony, and errors. Structuring the application with streams also separates concerns, because all [dynamic updates to a piece of data are co-located](/observables.html#reactive-programming) and impossible to change from outside. As a result, apps in Cycle are entirely `this`-less and have nothing comparable to imperative calls such as `setState()` or `update()`.
47 |
48 |
49 |
50 | ## Simple and Concise
51 |
52 | Cycle.js is a framework with very few concepts to learn. The core API has just one function: `run(app, drivers)`. Besides that, there are **streams**, **functions**, **drivers** (plugins for different types of I/O effects), and a helper function to isolate scoped components. This is a framework with very little "magic". Most of the building blocks are just JavaScript functions. Usually the lack of "magic" leads to very verbose code, but since functional reactive streams are able to build complex dataflows with a few operations, you will come to see how apps in Cycle.js are small and readable.
53 |
54 |
55 |
56 | ## Extensible and Testable
57 |
58 | Drivers are plugin-like simple functions that take messages from sinks and call imperative functions. All I/O effects are contained in drivers. This means your application is just a pure function, and it becomes easy to swap drivers around. The community has built drivers for [React Native](https://github.com/cyclejs/cycle-react-native), [HTML5 Notification](https://github.com/cyclejs/cycle-notification-driver), [Socket.io](https://github.com/cgeorg/cycle-socket.io), etc. Sources and sinks can be easily used as [Adapters and Ports](https://iancooper.github.io/Paramore/ControlBus.html). This also means testing is mostly a matter of feeding inputs and inspecting the output. No deep mocking needed. Your application is just a pure transformation of data.
59 |
60 |
61 | ## Explicit dataflow
62 |
63 | In every Cycle.js app, each of the stream declarations is a node in a dataflow graph, and the dependencies between declarations are arrows. This means there is a one-to-one correspondence between your code and *minimap*-like graph of the dataflow between external inputs and external outputs.
64 |
65 |
95 |
96 | In many frameworks the flow of data is *implicit*: you need to build a mental model of how data moves around in your app. In Cycle.js, the flow of data is clear by reading your code.
97 |
98 | ## Composable
99 |
100 | Cycle.js has components, but unlike other frameworks, every single Cycle.js app, no matter how complex, is a function that can be reused in a larger Cycle.js app.
101 |
102 |
103 | {% include /img/nested-components.svg %}
104 |
105 |
106 | Sources and sinks are the interface between the application and the drivers, but they are also the interface between a child component and its parent. Cycle.js components can be simply GUI widgets like in other frameworks, but they are not limited to GUIs only. You can make Web Audio components, network requests components, and others, since the sources/sinks interface is not exclusive to the DOM.
107 |
108 | ## Learn it in 1h 37min
109 |
110 |
23 | {% if page.path %}
24 | Edit on GitHub
25 | {% endif %}
26 |
27 |
28 | {{ content }}
29 |
30 |
31 |
32 | {% if page.next %}{% endif %}
33 | {% if page.previous %}{% endif %}
34 |
35 |
36 |
37 |
38 | {% if page.next %}{% endif %}
39 | {% if page.previous %}{% endif %}
40 |
41 |
42 | {% include footer.html %}
43 |
44 |
45 |
--------------------------------------------------------------------------------
/_posts/2015-01-21-community.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Community"
3 | tags: chapters
4 | ---
5 |
6 | To engage with the community around Cycle.js, follow these resources:
7 |
8 | * The GitHub organization, [cyclejs](https://github.com/cyclejs), is the default location for finding most of the packages you'll need.
9 | * Ask, "_How do I...?_" questions in Gitter: [](https://gitter.im/cyclejs/cyclejs)
10 | * Report bugs, discuss, and propose significant changes as a [GitHub issue](https://github.com/cyclejs/cyclejs/issues).
11 |
12 | ### Resources
13 |
14 | Visit [Awesome Cycle.js](https://github.com/cyclejs-community/awesome-cyclejs) to see a curated list of examples, presentations, blog posts, utilities and resources built by the community.
15 |
16 | ### Acknowledgements
17 |
18 | - This project is a grateful recipient of the [Futurice Open Source sponsorship program](http://futurice.com/blog/sponsoring-free-time-open-source-activities).
19 | - [@TylorS](https://github.com/TylorS) and [@Frikki](https://github.com/Frikki/) for fantastic contributions and involvement with Cycle.js.
20 | - [@dobrite](https://github.com/dobrite) for [boilerplate reduction ideas](https://github.com/cyclejs/core/issues/56).
21 | - [Nick Johnstone](https://github.com/Widdershin/) for writing libraries and spreading the word about Cycle.js.
22 | - [@erykpiast](https://github.com/erykpiast) for pull requests and great ideas.
23 | - [@pH200](https://github.com/pH200) for pull requests and amazing contributions.
24 | - [@cgeorg](https://github.com/cgeorg), [@laszlokorte](https://github.com/laszlokorte), and others in the Gitter chat for ideas, feedback, and active involvement with Cycle.js.
25 | - Organizers and sponsors of [CycleConf](http://cycleconf.com/) for bringing the community together in one place.
26 |
--------------------------------------------------------------------------------
/_posts/2015-01-22-documentation.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Documentation"
3 | tags: chapters
4 | ---
5 |
6 | Cycle.js is split in packages. Each package has its own API documentation, while this website covers how to integrate them all together.
7 |
8 | ## Run
9 |
10 | You will always need a `run()` function matching your stream library of choice. In the following list you can find documentation for these specific packages.
11 |
12 | - [`@cycle/xstream-run`](https://github.com/cyclejs/cyclejs/tree/master/xstream-run) [](https://www.npmjs.com/package/@cycle/xstream-run)
13 | - [`@cycle/rxjs-run`](https://github.com/cyclejs/cyclejs/tree/master/rxjs-run) [](https://www.npmjs.com/package/@cycle/rxjs-run)
14 | - [`@cycle/rx-run`](https://github.com/cyclejs/cyclejs/tree/master/rx-run) [](https://www.npmjs.com/package/@cycle/rx-run)
15 | - [`@cycle/most-run`](https://github.com/cyclejs/cyclejs/tree/master/most-run) [](https://www.npmjs.com/package/@cycle/most-run)
16 |
17 | ## Drivers
18 |
19 | The following are official Cycle.js drivers and links to their documentation.
20 |
21 | - [`@cycle/dom`](https://github.com/cyclejs/cyclejs/tree/master/dom) [](https://www.npmjs.com/package/@cycle/dom)
22 | - [`@cycle/http`](https://github.com/cyclejs/cyclejs/tree/master/http) [](https://www.npmjs.com/package/@cycle/http)
23 | - [`@cycle/jsonp`](https://github.com/cyclejs/cyclejs/tree/master/jsonp) [](https://www.npmjs.com/package/@cycle/jsonp)
24 |
25 | ## Utilities
26 |
27 | - [`@cycle/isolate`](https://github.com/cyclejs/cyclejs/tree/master/isolate) [](https://www.npmjs.com/package/@cycle/isolate)
28 | - [`@cycle/collection`](https://github.com/cyclejs/collection/blob/master/README.md) [](https://www.npmjs.com/package/@cycle/collection)
29 |
--------------------------------------------------------------------------------
/_posts/2015-01-23-drivers.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Drivers"
3 | tags: chapters
4 | ---
5 |
6 | Throughout this documentation site we have extensively used *drivers*. The DOM Driver has been the most common one, but also the HTTP driver was used.
7 |
8 | What are drivers and when should you use them? When should you create your own driver, and how do they work? These are a few questions we will address in this chapter.
9 |
10 | #### Drivers are functions that listen to sink streams (their input), perform imperative side effects, and may return source streams (their output).
11 |
12 | They are meant for encapsulating imperative side effects in JavaScript. The rule of thumb is: whenever you have a JavaScript function such as `doSomething()` which returns nothing, it should be contained in a driver.
13 |
14 | Let's study what drivers do by analyzing the most common one: the DOM Driver.
15 |
16 | >
Why the name "driver"?
17 | >
18 | > In Haskell 1.0 Stream I/O, similar in nature to Cycle.js, there is a cyclic interaction between the program's `main` function and Haskell's `os` function. In operating systems, drivers are software interfaces to use some hardware devices, which incur side effects in the external world.
19 | >
20 | > In Cycle.js, one can consider the "operating system" to be the execution environment surrounding your application. Roughly speaking, the DOM, the console, JavaScript and JS APIs assume the role of the operating system for the web. We need *software adapters* to interface with the browser and other environments such as Node.js. Cycle.js drivers are there as adapters between the external world (including the user and the JavaScript execution environment) and the application world built with Cycle.js tools.
21 |
22 |
DOM Driver
23 |
24 | The DOM Driver is the most important and most common driver in Cycle.js. When building interactive web apps, it is probably the most important tool in Cycle.js. In fact, while Cycle *Run* function is only about 200 lines of code, Cycle *DOM* is at least 4 times larger.
25 |
26 | It's main purpose is to be a proxy to the user using the browser. Conceptually we would like to work assuming the existence of a `human()` function, as this diagram reminds us:
27 |
28 |
29 | {% include /img/human-computer-diagram.svg %}
30 |
31 |
32 | However, in practice, we write our `main()` function targeted at a `domDriver()`. For a user interacting with a browser, we only need to make our `main()` interact with the DOM. Whenever we need to show something to the user, we instead show that to the DOM, and the DOM together with the browser shows that to our user. When we need to detect the user's interaction events, we attach event listeners on the DOM, and the DOM will notify us when the user interacts with the browser on the computer.
33 |
34 |
35 | {% include /img/main-domdriver-side-effects.svg %}
36 |
37 |
38 | Notice there are two directions of interaction with the external world through the DOM. The *write* effect is the renderization of our Snabbdom VNodes to DOM elements which can be shown on the user's screen. The *read* effect is the detection of DOM events generated by the user manipulating the computer.
39 |
40 | The `domDriver()` manages these two effects while allowing them to be interfaced with the `main()`. The *input* to `domDriver()` captures instructions for the *write* effect, and the *read* effect is exposed as the *output* of `domDriver()`. The anatomy of the `domDriver()` function is roughly the following:
41 |
42 | {% highlight js %}
43 | function domDriver(vdom$) {
44 | // Use vdom$ as instructions to create DOM elements
45 | // ...
46 | return {
47 | select: function select(selector) {
48 | // returns an object with two functions: `events()`
49 | // and `elements()`. Function `events(eventType)`
50 | // returns the stream of `eventType` DOM events
51 | // happening on the elements matched by `selector`.
52 | // Function `elements()` is the stream of DOM
53 | // elements matching the given `selector`.
54 | }
55 | };
56 | }
57 | {% endhighlight %}
58 |
59 | The input `vdom$` is the output from `main()`, and the output of `domDriver()` is the input to `main()`:
60 |
61 | {% highlight js %}
62 | function main(sources) {
63 | // Use sources.DOM.select(selector).events(eventType)
64 | // ...
65 | // Create vdom$ somehow
66 | // ...
67 | return {
68 | DOM: vdom$
69 | };
70 | }
71 | {% endhighlight %}
72 |
73 | As a recap:
74 |
75 | - `main()`: takes **sources** as input, returns **sinks**
76 | - `domDriver()`: takes **sinks** as input, performs write and read effects, returns **sources**.
77 |
78 |
Isolating side effects
79 |
80 | Drivers should always be associated with some side effect. As we saw, even though the DOM Driver's main purpose is to represent the user, it has write and read effects.
81 |
82 | In JavaScript, nothing stops you from writing your `main()` function with side effects. A simple `console.log()` is already a side effect. However, to keep `main()` pure and reap its benefits like testability and predictability, it is better to encapsulate all side effects in drivers.
83 |
84 | Imagine, for instance, a driver for network requests. By isolating the network request side effect, your application's `main()` function can focus on business logic related to the app's behavior, and not on lower-level instructions to interface with external resources. This also allows a simple method for testing network requests: you can replace the actual network driver with a fake network driver. It just needs to be a function that mimics the network driver function, and makes assertions.
85 |
86 | Avoid making drivers if they do not have effects to the external world somehow. Especially do not create drivers to contain business logic. This is most likely a code smell.
87 |
88 | Drivers should focus solely on being an interface for effects, and usually are libraries that simply enable your Cycle.js app to perform different effects. Sometimes, though, a one-liner driver can be created on the fly instead of being a library, for instance this simple logging driver:
89 |
90 | {% highlight js %}
91 | run(main, {
92 | log: msg$ => { msg$.addListener({next: msg => console.log(msg)}) }
93 | });
94 | {% endhighlight %}
95 |
96 |
Read-only and write-only drivers
97 |
98 | Most drivers, like the DOM Driver, take *sinks* (to describe a *write*) and return *sources* (to catch *reads*). However, we might have valid cases for write-only drivers and read-only drivers.
99 |
100 | For instance, the one-liner `log` driver we just saw above is a write-only driver. Notice how it is a function that does not return any stream, it simply consumes the sink `msg$` it receives.
101 |
102 | Other drivers only create source streams that emit events to the `main()`, but don't take in any `sink` from `main()`. An example of such would be a read-only Web Socket driver, drafted below:
103 |
104 | {% highlight js %}
105 | function WSDriver(/* no sinks */) {
106 | return xs.create({
107 | start: listener => {
108 | this.connection = new WebSocket('ws://localhost:4000');
109 | connection.onerror = (err) => {
110 | listener.error(err)
111 | }
112 | connection.onmessage = (msg) => {
113 | listener.next(msg)
114 | }
115 | },
116 | stop: () => {
117 | this.connection.close();
118 | },
119 | });
120 | }
121 | {% endhighlight %}
122 |
123 |
How to make drivers
124 |
125 | You should only be reading this section if you have clear intentions to make a driver and expose it as a library (unless it's a one-liner driver). Typically, when writing a Cycle.js app, you do not need to create your own drivers.
126 |
127 | Consider first carefully which side effects your driver is responsible for. And can it have both read and write effects?
128 |
129 | Once you map out the read/write effects, consider how diverse those can be. Create an empathic API which covers the common cases elegantly.
130 |
131 | The **input** to the driver function is expected to be a single stream. This is a practical API for the app developer to use when returning the `sinks` object in `main()`. Notice how the DOM Driver takes a single `vdom$` stream as input, and how sophisticated and expressive VNodes from Snabbdom can be. On the other hand, don't always choose JavaScript objects as the values emitted in the Observable. Use objects when they make sense, and remember to keep the API simple rather than overly-generic. Don't over-engineer.
132 |
133 | As a second, optional, argument to the driver function, you can expect `runStreamAdapter`. A "Stream Adapter" is a library that knows how to convert between one specific stream library (like xstream or RxJS) to a generic adapter interface used internally in Cycle.js. This is needed for those cases your driver function needs to return a sophisticated source object which can create arbitrary streams using the same stream library that your application uses. If your app uses `@cycle/xstream-run`, then it uses under the hood `@cycle/xstream-adapter`, which is the argument `runStreamAdapter` given to drivers. If your app uses `@cycle/rxjs-run`, then `runStreamAdapter` is `@cycle/rxjs-adapter`, and so forth. Hence the driver function signature is:
134 |
135 | {% highlight js %}
136 | function myDriver(sink$, runStreamAdapter /* optional */)
137 | {% endhighlight %}
138 |
139 | The **output** of the driver function can either be a single stream or a *queryable collection* of streams.
140 |
141 | In the case of a single stream as output source, depending on how diverse the values emitted by this stream are, you might want to make those values easily filterable (using the xstream or RxJS `filter()` operator). Design an API which makes it easy to filter the stream, keeping in mind what was provided as the sink stream to the driver function.
142 |
143 | In some cases it is necessary to output a queryable collection of Observables, instead of a single one. A **queryable collection of Observables** is essentially a JavaScript object with a function used to choose a particular stream based on a parameter, e.g. `get(param)`.
144 |
145 | The DOM Driver, for instance, outputs a queryable collection of streams. The collection is in fact lazy: none of the streams outputted by `select(selector).events(eventType)` existed prior to the call of `events()`. This is because we cannot afford creating streams for *all* possible events on *all* elements on the DOM. Take inspiration from the lazy queryable collection of streams from the DOM Driver whenever the output source contains a large (possibly infinite) amount of streams.
146 |
147 | You most likely will need `runStreamAdapter` only for queryable collections of streams **and** if you want your driver usable by any other stream library. If you are building your driver only for your own use, then just write the driver using the same stream library that your application uses.
148 |
149 |
Example driver implementation
150 |
151 | Suppose you have a fake real-time channel API called `Sock`. It is able to connect to a remote peer, send messages, and receive push-based messages. The API for `Sock` is:
152 |
153 | {% highlight js %}
154 | // Establish a connection to the peer
155 | let sock = new Sock('unique-identifier-of-the-peer');
156 |
157 | // Subscribe to messages received from the peer
158 | sock.onReceive(function (msg) {
159 | console.log('Received message: ' + msg);
160 | });
161 |
162 | // Send a single message to the peer
163 | sock.send('Hello world');
164 | {% endhighlight %}
165 |
166 | **How do we build a driver for `Sock`?** We start by identifying the effects. The *write* effect is `sock.send(msg)` and the *read* effect is the listener for received messages. Our `sockDriver(sink)` should take `sink` as instructions to perform the `send(msg)` calls. The output from `sockDriver()` should be `source`, containing all received messages.
167 |
168 | Since both input and output should be streams, it's easy to see `sink` in `sockDriver(sink)` should be a stream of outgoing messages to the peer. And conversely, the source should be a stream of incoming messages. This is a draft of our driver function:
169 |
170 | {% highlight js %}
171 | function sockDriver(outgoing$) {
172 | outgoing$.addListener({
173 | next: outgoing => {
174 | sock.send(outgoing);
175 | },
176 | error: () => {},
177 | complete: () => {},
178 | });
179 |
180 | return xs.create({
181 | start: listener => {
182 | sock.onReceive(function (msg) {
183 | listener.next(msg);
184 | });
185 | },
186 | stop: () => {},
187 | });
188 | }
189 | {% endhighlight %}
190 |
191 | The listener of `outgoing$` performs the `send()` side effect, and the stream returned based on `sock.onReceive` takes data from the external world. However, `sockDriver` is assuming `sock` to be available in the closure. As we saw, `sock` needs to be created with a constructor `new Sock()`. To solve this dependency, we need to create a factory that makes `sockDriver()` functions.
192 |
193 | {% highlight js %}
194 | function makeSockDriver(peerId) {
195 | let sock = new Sock(peerId);
196 |
197 | function sockDriver(outgoing$) {
198 | outgoing$.addListener({
199 | next: outgoing => {
200 | sock.send(outgoing));
201 | },
202 | error: () => {},
203 | complete: () => {},
204 | });
205 |
206 | return xs.create({
207 | start: listener => {
208 | sock.onReceive(function (msg) {
209 | listener.next(msg);
210 | });
211 | },
212 | stop: () => {},
213 | });
214 | }
215 |
216 | return sockDriver;
217 | }
218 | {% endhighlight %}
219 |
220 | `makeSockDriver(peerId)` creates the `sock` instance, and returns the `sockDriver()` function. We use this in a Cycle.js app as such:
221 |
222 | {% highlight js %}
223 | function main(sources) {
224 | const incoming$ = sources.sock;
225 | // Create outgoing$ (stream of string messages)
226 | // ...
227 | return {
228 | sock: outgoing$
229 | };
230 | }
231 |
232 | run(main, {
233 | sock: makeSockDriver('B23A79D5-some-unique-id-F2930')
234 | });
235 | {% endhighlight %}
236 |
237 | Notice we have the `peerId` specified when the driver is created in `makeSockDriver(peerId)`. If the `main()` needs to dynamically connect to different peers according to some logic, then we shouldn't use this API anymore. Instead, we need the driver function to take instructions as input, such as "connect to peerId", or "send message to peerId". This is one example of the considerations you should take when designing a driver API.
238 |
239 |
Drivers make Cycle.js extensible
240 |
241 | Cycle *Core* is a very small framework, and Cycle *DOM*'s Driver is available as an optional plugin for your app. This means it is simple to replace the DOM Driver with any other driver function providing interaction with the user.
242 |
243 | You can for instance fork the DOM Driver, adapt it to your preferences, and use it in a Cycle.js app. You can create a driver to interface with sockets. Drivers to perform network requests. Drivers meant for Node.js. Drivers that target other UI trees, such as `