JavaScript for Line of Business Applications

Cerebral is a framework. It provides concepts for handling application state and depends on React for its UI. Routing, http requests etc. are separate tools you choose based on what the project needs. Technically Cerebral does not need React to work.

So why would you even consider Cerebral? Before going into the thoughts behind Cerebral I want to point out that this is not another “FLUX framework” with its own take on actions, dispatchers and stores. I am certainly not talking down those frameworks, many of them are really great, but Cerebral is a new take on how to handle application state alltogether. It is inspired by Flux and more recent solutions like Baobab. So big thanks to all the brilliant people working on tools to make web application development more fun than frustrating!

• An architecture inspired by Flux and Baobab
• A single object for all application state
• One way flow of state
• Has complete control of your application state flow using signals
• Can retrace state changes live in the UI
• Specific concepts for handling asynchronous code and relational data
• Immutable data
• A functional approach to interactions
• Gives errors on invalid code
• Requires React as your UI layer

Many people that use ReactJS as their renderer are using some kind of the
Flux architecture to store data, react to actions and notify components
about changes. After a University project involving Scala and RxJava, I wanted
to use these ideas together with ReactJS views. Besides that I found two things
missing in the Flux architecture:

composing different kinds of data easily
interaction with the server

Of course there are ways to solve this, but perhaps reactive streams can help
ease these shortcomings.

n this post we build a small example UI following a data-first approach. What the user sees is just a representation of a piece of data, the app state. And when she interacts with the interface, she is just applying transformations to that piece of data.

Isomorphic apps are almost like “normal” apps when creating them with the FRP. Because the FRP encourages you to always pass the entire state object to the rendering function, nothing prevents you to do the same in the backend as well.

If you have read other tutorials you may already know that React has a “backend-compatible” function called renderToString. It behaves exactly like render but doesn’t call componentDidMount and returns the rendered HTML as a string instead of placing it into a DOM node. Component & model in → HTML out. Couldn’t be simpler?

Well… actually, it could be. There are two gotchas you should know before trying to use renderToString:

1. Your backend must understand JSX syntax
2. Your front-end modules must be CommonJS compatible

Arch is a front-end functional style application framework using React as a UI layer. Arch applications are isomorphic out of the box, including form processing. This means you write your application as if it was client-side only and Arch will manage the server-side portion.

This also means you don’t get any control over the code running server-side, which is a design decision. The theory behind it is that any server-side code you need to run should sit in a separate server application which you talk to over an API.

Baobab gives you the same “one way flow” of state in FLUX, only it reduces a lot of the complexity. 

The point is that your components never mutate the tree and the actions never return state from the tree. Any change to state is done through an action which changes the tree, which notifies about the change to any components listening to that part of the tree. Baobab handles this very well and it integrates very well with React.

First of all we have to get a notion of what we are trying to solve. Even though Baobab up until version 1.0 gave us a great concept for handling state it was challenging to handle “shared data”. Let me explain.