Update (02.02.2019) : more than two years ago, while experimenting with RxJS and React, I’ve created a library presented in this post. Please note that in the meantime, that library was deprecated . Using observables seems like . So why don’t we use it in apps more often? a good thing React With observables we can easily manage asynchronous data streams, but what is a stream in a React component? Streams in React To determine this, let’s start by analyzing a simple example: ClickCounter Simple React ClickCounter component This is a component describing asynchronous behavior. On every event on a tag, the state is changed. Or in other words, the state as a result of happening . click button changes events over time A sequence of ongoing events ordered in time is a definition of a — . stream So, instead of defining as an object which will later be overwritten, we can define it more declaratively: this.state Defining state as a stream Managing component streams However, even when defined like this, how will our component know when to update? Somebody still has to invoke . this.setState() There are some for achieving this, but it seemed a bit too complicated to me. existing solutions Other more popular options for using “Functional Reactive paradigm” requires you to use another framework or another language (like or ). programming Cycle.js elm But I didn’t like the idea of losing all good things React offers you. So, I created a small library called , which is my attempt at solving this issue. It converts “functional/reactive object description” into a React component. Recycle Here is how a looks like when defined using Recycle: ClickCounter It works by “monkeypatching” . Before a component is rendered, if a select query is matched with node element, recycle sets inline event listener defined in function. React.createElement update Each time event handler dispatches an event, it calls selectedNode.rxSubject.next(e) In short, Recycle creates a classical React component out of this object by creating inline event handlers and handles component local state by using “Redux style” reducer operator. Pros Greater separation of concerns between component presentation and component logic. Classical React component — mixing logic and structure You don’t need classes so each part of a component can be defined and tested separately. Component description is more consistent. There is no custom events or statements that you need to worry about. handleClick this.setState State is calculated the same way as for redux store: . state = reducer(state, action) Redux container looks like a normal component and it’s more clear what it does. Easy to use in an existing React application (choose components which you wish to convert). Cons Observables. They come with trade-offs. You don’t like the idea of selecting nodes using class names, ids or tags Yo need to use advanced React API (like or ) forceUpdate shouldComponentUpdate Yo need direct access to DOM elements (using ) for external plugins or similar this.refs Mailing list If posts like this are interesting to you, consider subscribing to my mailing list . Don’t worry, I wont spam you — usually it takes me about two months for a single post :)
