Recycle — Truly Functional and Reactive way of writing React apps

Update (04–22–2017)

New version of Recycle is much simpler than its first version presented in this blog post. You should probably check it out before reading this post.

Update (12-21-2016)

At the time of writing this post, Recycle was presented as a framework. But as of version 0.6.0, Recycle can be used as a standard React library!

JavaScript supermarket

JavaScript is like a giant supermarket.

It’s crowded, and you can easily get lost. You can buy almost anything you can think of, but every item has an expiration date and a price tag, and you have a limited budget.

And here I am, standing in a Frontend Section, talking about my new product — Recycle.

You are looking right at me. Sceptically.

How much does it cost?

Will probably be your first question.

Well, currency in this world is a combination of time, your knowledge and a product community support.

So, before looking into it, let’s determine its price tag.

Time and knowledge

Recycle promotes FRP paradigm for building web apps. So, if you’re familiar with functional or reactive programming, regarding the time you need to invest in learning it, this shouldn’t cost you much.

But, if FRP paradigm is new to you, it may be a good idea to learn it regardless of this library. I suggest you start by watching this.

Community support

This is not the first time “functional and reactive framework” is introduced in JavaScript, so why would you then choose Recycle? If you already have an app written in React, is it worth the risk of rewriting it to Recycle?

And what about its ecosystem? What should we do with all those great libraries like react-router or material-ui? Rewrite them as well?

The answer is — no. Since Recycle (by default) uses React, you can use React components in your Recycle app or Recycle components in your React app.

Think of it as a different way of writing React, and use it only for your future components.

Problems with React.js

If this library promotes a “new way” of writing React apps, what’s wrong with the “old way”?

It is not functional

It goes without saying, this is a problem only if you prefer FP to OOP.

Even though I’m aware that if you follow a list of guidelines like:

  • Hide classes with factory functions
  • Watch out not to inherit more than once
  • Don’t make super calls from methods

you will get the same benefits of functional programming and still use classes.

But, if you want to use a particular style of programming, is it better to adapt to a framework or should a framework adapt to you?

It mixes logic with presentation

When it was first introduced, in the official docs of React, there was a guide called “Why React?” which stated the following:

React is a JavaScript library for creating user interfaces by Facebook and Instagram. Many people choose to think of React as the V in MVC.

Well, many people are wrong.

The biggest issue developers had with React was JSX and the fact that View was “merged” into JavaScript. It was just hard to swallow, mostly because at the time everybody was so used to writing templates.

What surprises me is that we don’t seem to care about this anymore. Even though writing Views in JavaScript is better then using templates (easier to extend and maintain, no manual string concatenation etc.) this is not the whole story. There is another problem here.

Take this JSX code snippet for example:

As you begin to scan this code, line by line, it is probably the one with “onChange={this.handleChange}” on which you are likely to stop and take a closer look.

The reason why your eye is trained to look for lines like this one is because it contains important information about the behaviour of the component which is directly linked to your component logic. Everything else is a visual representation of the state.

Isn’t it strange to you that this things are mixed together?

It was strange for the people that have invented MVC back in 1979 when they wrote:

… a view should never know about user input, such as mouse operations and keystrokes.

Maybe they had a point?

Problems with Cycle.js

One of the most popular FRP JavaScript framework today is — Cycle.js.

Although, Recycle uses React, its actually inspired with Cycle.js. Recycle initial version had nothing to do with React and was made as an “opinionated version of Cycle.js”.

Flexibility comes with a price

Cycle.js is more flexible than Recycle. It’s probably more flexible than any other JavaScript framework used today. This is due to a decision made by its creator:

I didn’t want to build a framework or architecture that was predefined and always works in the same way. I wanted to allow flexibility and people to choose what they want to do.

But this comes with a price. If something is not predefined, it means that you have to define it every time you use it. That is ok, but only if this is not a repetitive task, in which case I encourage you to use Cycle.js.

But, as it turns out, defining components composed of a view, actions and functions responsible for modifying state is a model that can be described without the use of the main function, drivers or complex stream manipulations.

All of this can be abstracted and used as a framework which is why Recycle was made.

Show me the code!

By now, you are probably wondering, “what is your alternative then?”.

Of course, this is not my alternative. Even though I talked mostly about the problems of React and Cycle.js, you can probably figure out why is the name of this library composed of: “Re” and “cycle.”

Short TodoMVC example

Let’s say we are writing a TodoMVC app which is composed of a TodoList and Todo component.

In this post, I’ll focus only on a TodoList component.

As you can expect, a View function has a single responsibility, which is a — visual representation of the state. Child components are still invoked the same way as with React, but there are no inline event handlers so you or your friend — UI designer, can be more relaxed about changing its structure:

How are we going to define its actions then?

With actions function, of course.

TodoList component is in charge of:

  • toggling all todo items
  • deleting all completed todo items
  • keeping track of value user had provided
  • clearing input field on ESC_KEY
  • inserting new todo item on ENTER_KEY
  • clearing input field when item is inserted

Now take a look how this is defined in Recycle and compare it with the list above:

The last part of the cycle is to define how the component state should change based on this actions. In Recycle this is done with “reducers” (an equivalent of React this.setState):

Finally, we can define our TodoList component:

For more detail instructions which includes a Hello World example, components using WebSockets and multiple different ways of creating TodoMVC app, take a look at the official guide.

What about state management tools like Redux?

It is very easy to write plugins for Recycle, and currently, its only official plugin is a — store plugin, designed as a state management tool similar to Redux.

It is not identical to Redux (since in Recycle you are not passing callbacks using props) but if you decide to switch to Recycle and have an existing application using Redux, you should be able to use all your existing reducers.

To learn more about a store plugin, again, check the official docs and example of a TodoMVC implementation with a store.

Conclusion

This is the end of my product pitch. If you like it, please try it out and let me know how it goes. If your version of the Recycle copy breaks, I’ll take your claim, and we can try to fix it together. But if you wish to return it, unfortunately, due to a nature of our currency, I won’t be able to give your money back. Not before we invent a working flux capacitor.

Happy shopping and use the products you buy responsibly. If you don’t want them anymore, throw it out, but please, recycle. It’s good for the environment.