Powercycle 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 Powercycle app.
React and Cycle.js have separate advantages and compromises, and I wanted to bring the good parts together.
React
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
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 Powercycle.
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:
Obviously you can skip using JSX, if you really wish, but you'll still need the pragma.
$3
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.
`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
`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
powercycle 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
powercycle 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
powercycle 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
powercycle 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
withPower 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
sources.props. 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
scope 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
scope 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 [ get: state => JSON.stringify(state.foo.bar), set: (state, childState) => ({ ...state, foo: JSON.parse(childState)}) } }} /> { state: reducer$ } ] // will show "{\"baz\":5}" `
The
scope 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
noscope 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) } ]} `
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 then={value} else={otherValue} /> `
As an alternative way of defining the
then branch, instead of using the then prop, you can define the then children as the vdom subtree of the If component:`jsx {then value} /> `
####
if 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
if 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
#### 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,
Collection 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: {} }] } } */
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:
*
on={ { sink1: , sink2: , ...} }
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_.
*
on={}
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.
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 ( <>
value={get('color')} 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
useCycleState 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
map 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)}> }:
Note, that in props, you can only use it with the sources object, as inline components are not applicable as props.
* ####
get
The
get 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:
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.