Composable Cycle.js with seamless React interop
npm install cyrenaCyrena is a transpositional extension for the wonderful framework Cycle.js. Transposition means that instead of only having views defined in streams, we're allowed to have streams defined in views as well! It powers up Cycle.js to the next level so it almost looks like a new framework! It puts the view in the center, to make composition as easy and trivial as it is in React - while keeping all the benefits of a purely functional-reactive environment. Any regular Cycle.js and React component can be included seamlessly in a Cyrena app.
``jsx`
function Timer(sources) {
return (
Timer: {xs.periodic(1000)}
)
}
Basic examples:
* Hello World
* Timer
* Counter
* Scope
* Todo List - simple
* Todo List - advanced
* React component with Cycle state
App examples:
* Tic Tac Toe
* TMDb UI
* Testing dashboard
React and Cycle.js have separate advantages and compromises, and I wanted to bring the good parts together.
React's benefits are that it's view-based, and imperative. Imperative means that the developer works with first-order values and nudges the application further by calling setState imperatively. This is by far the most accessible way for developers to proceed and get things done.
Being view-based means, that when we see a piece of React code, we immediately recognize the structure of the app or component by having a glimpse on the JSX part.
But all this comes at the price of an unconventional programming model, where the render function gets called many times by the runtime. And having the ability to return with completely different output VDOMs based on different inputs, defeats the purpose of the JSX as a structural overview. In idiomatic React code, most of the JSX is conceptually a static hierarchy, which contains changing bits and pieces. But in reality, not just the changing parts, but all the conceptually static parts, too, are re-evaluated and matched with the previous output. Sometimes it needs special awareness. And this reasoning goes for the logic as well, with the well-known Rules of Hooks. This might not be a big deal, you might think, but what I think is that we can do it better.
Cycle.js is a purely functional-reactive framework, and I won't detail how useful this fact is. It's also quite mature in its current state. Components are static, they're called once, and not by a runtime, but simply by the app author. The downside of it is that it's not view-based. Sure, we do have the view part, and it can even be JSX, but unfortunately this view part is not in the static scope. It's in the same iteratee-realm in which React is. But here it comes with a serious consequence: there's no easy composition! You can't throw in components in the VDOM tree. You have to do cumbersome boilerplate even for basic composition.
This led me to explore the possibilities to make something as simple and composable as React, but as right in its programming model as Cycle.js. This pursue resulted in Cyrena.
1. Installation
1. Getting Started
1. Static VDOM composition
1. Streams and components everywhere
1. Scopes
1. Conditionals
1. Collection
1. Event props
1. React realms
1. Helpers, Shortcuts and Tips
Install Cyrena and its peer dependencies:
npm install powercycle @cycle/react react xstream
Install the usual Cycle/react dependencies:
npm install @cycle/run @cycle/react-dom @cycle/state
#### JSX
Besides following the Installation steps, make sure that your setup can handle JSX, because Powercycle was made with JSX in mind. Powercycle has its own JSX pragma:
`jsx`
import withPower from 'powercycle'
/* @jsx withPower.pragma /
/* @jsxFrag withPower.Fragment /
Obviously you can skip using JSX, if you really wish, but you'll still need the pragma.
We've seen the default import above named withPower, but let's forget that for now. Powercycle's core utility is the powercycle function, which takes 3 arguments, and returns a regular Cycle.js _sinks_ object. (Don't pick on the name powercycle; at the end of the day, you won't even need to use this function.)
1. The first argument is a static VDOM, which can contain streams and other components (even inline components! We'll see them later).
1. The second argument is the sinks object, which contains all of the sinks for the current component, _except the view_.
1. The third argument is the sources object which Powercycle will pass to the components during the VDOM traversal.
Let's see a basic example of an atomic component:
`jsx
// Regular Cycle.js component
function Cmp(sources) {
const state$ = sources.state.stream
return {
react: state$.map(state =>
It turns into:
jsx
function Cmp(sources) {
const state$ = sources.state.stream return powercycle(
{state$},
null,
sources
)
}
`At the moment it doesn't seem to be much useful, but what happens when you want to include a child component, for example a Panel, in which you want to wrap the content. It leads to serious boilerplate:
jsx
function Cmp(sources) {
const state$ = sources.state.stream const panelSinks = Panel({ ...sources, props: { title: 'State' }})
return {
react: panelSinks.react.map(panelVdom =>
State in a panel:
{panelVdom}
)
}
}
`With Powercycle, it remains an atomic step:
jsx
function Cmp(sources) {
const state$ = sources.state.stream return powercycle(
State in a panel:
{state$}
null,
sources
)
}
`You can see the limitation in the first version: you can't put content and pass props to the Panel component in the VDOM. Wrapping a section of a content into a container is not a trivial action – you have to declare and manually invoke every related component separately from the VDOM. In the Powercycle example you might now have an idea how easy it can go with composition. The
function will invoke the Panel component with passing the sources object to it (given as the 3rd parameter). Whenever the Panel component's view stream updates, the outer component will update as well. We'll see more powerful examples in the next sections, but let's not rush ahead.How do we define our other sinks then, which are not the view? This is what the second argument is for:
`jsx
function Cmp(sources) {
const state$ = sources.state.stream return powercycle(
State in a panel:
{state$}
{
state: ...,
HTTP: ...
},
sources
)
}
`Let's wrap up what the
function does exactly:1. It traverses the VDOM and searches for streams and components (see section Streams and components everywhere for details).
1. It creates a view stream for the outer component which combines all the view streams in the given VDOM, and updates with the original VDOM structure.
1. It collects all the non-view sink channels which were found in the inner components' sinks objects, and merges them all by channel. It also adds the sinks of the second argument to the merges. The result sinks object will be the return value of the
powercycle function.#### Shorthand return from components
From the last example of the previous section we learned that the VDOM traversal stops at the Panel component. The Panel component can do anything with the state$ stream which it received through
sources.props.children. It can even dismiss it. This is the same behavior as you can find in React. In order to see the state in the app, the Panel component must include its sources.props.children in its VDOM:`jsx
function Panel(sources) {
return powercycle(
{sources.props.title}
{sources.props.children}
,
null,
sources
)
}
`One important fact to realize here is that the Panel component is not invoked by the app developer, but by Powercycle. So Powercycle sees its output, and it can automatically call the powercycle function on it, so we have less to type:
jsx
function Panel(sources) {
return [
{sources.props.title}
{sources.props.children}
,
null,
sources
]
}
`This convenience shortcut changes the regular signature of a Cycle.js component's output, but we'll see how it hugely pays off. We can even omit the sources object too, because Powercycle already has it from the first
call. If there's no non-view sink channel for the component, we can omit the second parameter too and the array wrapping, so this results in as simple as this:`jsx
function Panel(sources) {
return (
{sources.props.title}
{sources.props.children}
)
}
`#### withPower
Every component which returns with the shortcut return format, conveys the same amount of information as a regular Cycle.js component, it's just 'controlled' by Powercycle. The only thing we have to watch out for, is to have a root
call to have the VDOM 'controlled'. It turns out, we can wrap our main component in a higher order function to do this:`jsx
import withPower from 'powercycle'
/* @jsx withPower.pragma /
/* @jsxFrag withPower.Fragment /// ...
run(withPower(main), drivers)
`With the
function, you don't ever need to use the powercycle function! You can just return with the VDOM, or with an array containing the VDOM and the event sinks object.$3
Powercycle collects streams and components from the VDOM according to the following rules:
1. When it finds a stream as a _VDOM child_, it collects the stream:
`jsx
function main (sources) {
// ...
return (
{state$}
)
}
`2. When it finds a stream in a prop of a _plain DOM (e.g. a 'div') element_, it collects the stream:
jsx
function main (sources) {
// ...
return (
...
)
}
`3. When it finds a _component (e.g. Panel) element_, it invokes it with the sources objects, and collects its sinks. It doesn't continue the traversal under the component element. It passes the props object as
. The inner component can access the children as sources.props.children:
`jsx
function Panel (sources) {
return (
<>
{sources.props.title}
{sources.props.children}
} function main (sources) {
return (
...
)
}
`4. When it finds a _function as a VDOM child_, it's interpreted as an _inline component_. Powercycle will invoke the component with the sources object and collects its sinks, just like as it were a component element:
jsx
function main (sources) {
return (
{sources => {
return [
...,
{ state: ... }
]
}}
)
}
`$3
Any VDOM node can have a
prop, which will act as a regular Cycle.js isolation scope for the given element. As components act as boundaries in the Powercycle traversal, a scope will not just affect the component, but the complete sub-VDOM under it as well.`jsx
function ShowState(sources) {
return (
{sources.state.stream.map(JSON.stringify)}
)
}function main(sources) {
const reducer$ = xs.of(() => ({
foo: { bar: { baz: 5 } }
}))
return [
{ state: reducer$ }
]
// will show {"bar":{"baz":5}}"
}
`Unlike the regular Cycle.js scope parameter, the
prop can be a nested lens:`jsx
return [
{ state: reducer$ }
]
// will show {"baz":5}"
`And of course it can be a full scope object:
jsx
return [
set: (state, childState) => ({ ...state, foo: JSON.parse(childState)})
} }} />
{ state: reducer$ }
]
// will show "{\"baz\":5}"
`The
prop can be used on a DOM element as well. In this case, the scope
will be applied to all the other props
(for get and onChange, see Helpers, Shortcuts and Tips).
If there's both an if and scope prop on the element, their precedence will be
defined by their definition order on the node!`jsx
// state: { todos: [{ text: 'todo1' }, { text: 'todo2' }, { text: 'todo3' }]}
...
() => value} />
`#### Automatic view scoping
By default, every component in Powercycle is scoped on the view channel. If you need to lift this rule occasionally, you can provide a
prop on the component. The reason for this rule is to make string VDOM selectors safe by default. String VDOM selectors are useful, because they eliminate the necessity of boilerplate Symbol declarations. Take a look at this inline component, which is inside a Collection item:`jsx
{src => [
,
{ state: src.sel.remove.click.mapTo(COLLECTION_DELETE) }
]}
`$3
####
component:Wraps the
then or else value in a Fragment based on the cond property. The
cond property can be either a stream or a stream callback. then and else values
can any vdom child.`jsx
else={otherValue}
/>
`As an alternative way of defining the
branch, instead of using the then prop,
you can define the then children as the vdom subtree of the If component:`jsx
{then value}
/>
`####
prop (applies to Component and DOM elements):Controls the existence of the element based on the
if condition:`jsx
Remove
`If there's both an
and scope prop on the element, their precedence will be
defined by their definition order on the node!
$3
Powercycle has a
Collection component which makes handling dynamic lists easy and trivial. By default, you don't need to provide any props to Collection. It uses the state channel as its input, so make sure that you scope down the state either on the Collection component or somewhere above. The Collection component will take its VDOM children as a fragment as its item component, so you can put anything between the opening and closing tags. The Collection package also has a const for item removal reducer:`jsx
{src => [
,
{ state: src.sel.remove.click.mapTo(COLLECTION_DELETE) }
]}
`#### Reaching out to the outer state from the items
There are cases when you need to interact with the outer state from the items. For example, you need to duplicate an item, or set some state somewhere else, based upon the current item's state. For these cases,
automatically provides an extra stream in the items' sources object: outerState (the name can be specified with outerstate prop). Items can also leave reducers in their outerState sink. In order to interact with not just the collection array itself, even outer states, use the for prop on the Collection. The for prop works exactly like scope in specifying the collection's array, but it doesn't scope down the component, so outerState can see beyond the list.`jsx
/*
{
globalColor: "blue",
foobar: {
list: [{ color: "white", id: {} }, { color: "blue", id: {} }]
}
}
*/
Set color:
{src => [
,
{
outerState: src.sel.set.click
.compose(sampleCombine(src.state.stream))
.map(([click, state]) => outerState => ({
...outerState,
globalColor: state.color
}))
}
]}
See the Todo app for an example
$3
Powercycle makes use of _onClick_-style even props on elements. Event props are basically shortcuts
for inline components. There are 2 types of event props:
*
When the event prop value is an object, it is treated as a special sinks object, where the values are mappers
between the event _stream_ to the sink _stream_.
*
When the event prop value is a function, it is handled as a mapper between the event object and the state (reducer). The
state will be consumed by the state sink.
Examples:
jsx
{src => [
Last click position: {get()}
,
{
state: src.el.click.map(ev => () => ${ev.clientX},${ev.clientY}),
HTTP: src.el.click.mapTo({ url: '?you-clicked' })
}
]}
`With using event props, this can be rewritten as below. You can see that there's
no more need to wrap the fragment in an inline component:
jsx
Last click position: {get()}
state: ev$ => ev$.map(ev => ${ev.clientX},${ev.clientY}),
HTTP: ev$ => ev$.mapTo({ url: '?you-clicked' })
}}
>Make a request
`Most of the times we're only concerned about the state sink. For this, the
callback shortcut is even better:
jsx
`Let's see another example. Here, we want to use a reducer with a
In this case, by the time the reducer will be called, the event object will be nullyfied
by React, and React will throw an error related to the synthetic event. Destructuring
the arguments helps to overcome this problem:
jsx
function Combobox (sources) {
return (
<>
onChange={({ target: { value }}) => prev => ({ ...prev, color: value })}
>
)
}
`$3
React components can be included in the VDOM by wrapping them in the ReactRealm component. To use the state from the Cycle.js environment, Powercycle offers the
hook. You can put any content inside the opening and closing tags, they won't be traversed by Powercycle. That part of the VDOM will go directly into the React engine:`jsx
import { ReactRealm, useCycleState } from 'powercycle/util/ReactRealm'function ReactCounter(props) {
const [count, setCount] = useCycleState(props.sources)
return (
Counter: {count}
)
}function main(sources) {
const state$ = sources.state.stream
const reducer$ = xs.of(() => ({
counter: 5
}))
return [
We're under a React realm!
{state$.map(JSON.stringify)}
,
{ state: reducer$ }
]
}
`$3
* #### Event props
* ####
The utility function is a handy helper to get the state in the VDOM. It has 2 signatures:
* map(mapperFn, If the sources object is provided as the second parameter, the
function returns with a stream which maps sources.state.stream over the mapperFn, so it's a shortcut for :
`jsx
function ShowState(sources) {
return (
{map(JSON.stringify, sources)}
{/ {sources.state.stream.map(JSON.stringify)} /}
)
}
` *
If the sources object is omitted, then the
function returns with an inline component, which has the content of sources.state.stream, mapped over mapperFn, so it's a shortcut for { sources => <>{map(mapperFn, sources)} }:
`jsx
function ShowState(sources) {
return (
{map(JSON.stringify)}
{/ {sources => <>{map(JSON.stringify, sources)}} /}
)
}
` Note, that in props, you can only use it with the sources object, as inline components are not applicable as props.
* ####
The
function works exactly like map regarding its signature. The only difference is that it uses a Lodash getter as the mapperFn. It's a convenient shortcut for getting a chunk of the state:
`jsx
function ShowColor(sources) {
const reducer$ = xs.of(() => ({
color: 'red'
})) return (
It's {get('color')}
)
}
` When the
function is called with no or empty parameter, it returns with the state object itself:
`jsx
function ShowColor(sources) {
const reducer$ = xs.of(() => ({
color: 'red'
})) return (
It's {get()}
#### sources.sel[]*
View selection has a convenience shortcut. Instead of writing
You can write just:
Example:
jsx
{src => [
,
{ state: src.sel.remove.click.mapTo(COLLECTION_DELETE) }
]}
{src =>
}
` #### sources.el*
On a relative root element, you can even leave
and just write sources.el,
which will refer to the root element:
`jsx
{src => [
,
{ state: src.el.click.mapTo(COLLECTION_DELETE) }
]}
``
#### How to opt-out from the Powercycle control?*
You can opt-out from Powercycle at any place in the VDOM by just returning a regular sinks object. The underlying components will not be controlled by Powercycle.