What is RxJS?

Reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change - Wikipedia

RxJS is a library for reactive programming using observables that makes it easier to compose asynchronous or callback-based code - RxJS docs

The essential concepts in RxJS are

• An Observable is a stream of data

• Observers can register up to 3 callbacks:

• next is called 1:M time to push new values to the observer

• error is called at most 1 time when an error occurred

• complete is called at most 1 time on completion

• Subscription "kicks off" the observable stream

Without subscribing the stream won't start emitting values. This is what we call a cold observable.

It's similar to subscribing to a newspaper or magazine... you won't start getting them until you subscribe. Then, it creates a 1 to 1 relationship between the producer (observable) and the consumer (observer).

What are RxJS operators?

Operators are pure functions that enable a functional programming style of dealing with collections with operations. There are two kinds of operators:

• Creation operators
• Pipeable operators: transformation, filtering, rate limiting, flattening

Subjects are a special type of Observable that allows values to be multicast to many Observers. While plain Observables are unicast (each subscribed Observer owns an independent execution of the Observable), Subjects are multicast. This is what we call a hot observable.

In this article, I will focus on the zip, combineLatest and forkJoin operators. These are RxJS combination operators, which means that they enable us to join information from multiple observables. Order, time, and structure of emitted values are the primary differences among them.

Let's look at each one individually.

zip()

• zip doesn’t start to emit until each inner observable emits at least one value
• zip emits as long as emitted values can be collected from all inner observables
• zip emits values as an array

Let’s imagine that you are with Mario and Luigi, two of your best friends, at the best Italian restaurant in Rome. Each one of you orders a drink, a pizza, and a dessert. You specify to the waiter to bring the drinks first, then the pizzas, and finally the desserts.

This situation can be represented with 3 different observables, representing the 3 different orders. In this specific situation, the waiter can use the zip operator to bring (emit) the different order items by category.

❗️❗️❗️Warning❗️❗️❗️

If you go back to the same Italian restaurant with your girlfriend, but she doesn’t want to eat, this is what will happen:

If the waiter$ uses the zip operator, you will only get your drink!

Why?

Because, when the waiter$ emits the drinks, the girlfriend$ observable is complete and no more value can be collected from it. Hopefully, the waiter$ can use another operator for us so we don't break up with our girlfriend ?

combineLatest()

• combineLatest doesn’t start to emit until each inner observable emits at least one value
• When any inner observable emits a value, emit the last emitted value from each

At the exact same restaurant, the smart waiter$ now decide to use combineLatest operator.

❗️❗️❗️Warning❗️❗️❗️

With combineLatest, the order of the provided inner observables does matter.

If you$ is provided first to waiter$, it will emit only one value ["Tiramisu", "Sprite"].

This is happening because combineLatest doesn’t start to emit until each inner observable emits at least one value. girlfriend$ starts emitting when the first inner observable emits its last value. Then, combineLatest emits the last values collected from both inner observables.

forkJoin()

• forkJoin emits the last emitted value from each inner observables after they all complete
• forkJoin will never emit if one of the observables doesn’t complete

When you go to the restaurant and order for a pizza, you don’t want to know all the steps about how the pizza is prepared. If the cheese is added before the tomatoes or the opposite. You just want to get your pizza! This is where forkJoin comes into play.

❗️❗️❗️Warning❗️❗️❗️

• If one of the inner observables throws an error, all values are lost
• forkJoin doesn’t complete

• If you are only concerned when all inner observables complete successfully, you can catch the error from the outside
• Then, forkJoin completes

• If you don’t care that inner observables complete successfully or not, you must catch errors from every single inner observable
• Then, forkJoin completes

Personally, when I go to a restaurant with friends, I don’t care if one of them receives a burnt pizza. I just want mine ? so I will ask the waiter$ to catch the errors from inner observables individually.

Wrap up

We covered a lot in this article! Good examples are important to better understand RxJS operators and how to choose them wisely.

For combination operators like zip, combineLatest, and forkJoin the order of inner observables that you provide is also critical, as it can drives you to unexpected behaviours.

There is much more to cover within RxJS and I will do it in further articles.

I hope you enjoyed this article! ?

? You can follow me on Twitter to get notified about new Angular/RxJS blog posts and cool tips!

ReactJS is an open-source framework that facilitates the development of UI interfaces for web and mobile applications. Developers globally use the framework to build state-of-the-art applications which subsequently generate revenues as well as expand the audience for businesses.

However, building a great UI with React isn’t enough, You’ve got to add that extra glitter to make the app more polished, functional and remarkably better than the competition.

This is exactly what I’m going to help you with as I describe some key methods to increase performance in React apps.

1. Making good use of Identities

When building mobile apps with React, it is possible to wrap functions and variables with React.useMemo. Doing so provides the ability to memoize them so they remain identical for renders in the future.

When functions and variables are not memoized, any references to them might vanish from future renders. Memoizing helps in negating wasteful processes and operations in every situation where you’d leverage functions and variables.

Example:

Say, we’re preparing a custom hook for a list of urls as arguments. Using the hook, we can collect them into an array of promise objects and resolve them with Promise.all. The results of this accumulation will enter the state and be passed the app component once done. The list of promises now map over the urls array from where it fetches the urls.

import React from 'react'
import axios from 'axios'

export const useApp = ({ urls }) => {
  const [results, setResults] = React.useState(null)

  const promises = urls.map(axios.get)

  React.useEffect(() => {
    Promise.all(promises).then(setResults)
  }, [])

  return { results }
}

const App = () => {
  const urls = [
    'https://clinicaltables.nlm.nih.gov/api/icd10cm/v3/search?terms=a',
    'https://clinicaltables.nlm.nih.gov/api/icd10cm/v3/search?terms=b',
    'https://clinicaltables.nlm.nih.gov/api/icd10cm/v3/search?terms=c',
  ]

  useApp({ urls })

  return null
}

export default App

Since we want to obtain data from 3 urls here, only 3 requests are supposed to be sent out, one for each url. However, when looking at it through the inspect element feature on Google Chrome, we find that 6 requests are sent instead of the supposed 3.
This happens because the urls argument did not retain its previous identity. When the app is re-rendered, it’s instantiating a new array each time, as React treats it as a different value.

To fix this problem, we can use React.useMemo as previously mentioned. When using React.useMemo, the array of promise objects won’t recompute in each new render unless the array with the list of urls changes. As long as it stays the same, the identities remain.

Here’s what happens when applying React.useMemo to this example:

const useApp = ({ urls }) => {
  const [results, setResults] = React.useState(null)

  const promises = urls.map((url) => axios.get(url))

  React.useEffect(() => {
    Promise.all(promises).then(setResults)
  }, [])

  return { results }
}

const App = () => {
  const urls = React.useMemo(() => {
    return [
      'https://clinicaltables.nlm.nih.gov/api/icd10cm/v3/search?terms=a',
      'https://clinicaltables.nlm.nih.gov/api/icd10cm/v3/search?terms=b',
    ]
  }, [])

  const { results } = useApp({ urls })

  return null
}

It will send 6 requests even now since we’ve only memoized the urls array. The promises variables are also instantiating when running the hook. So in order to send only 3 requests, we also have to memorize the promises variables as well.

const promises = React.useMemo(() => {
  return urls.map((url) => axios.get(url))
}, [urls])

After memoizing both the urls array and the promises variables, this is what we get:

2. Merging Props to Children

At times, developers get into situations where they prefer merging a prop with children before rendering. To facilitate the same, React allows viewing the props to all react elements including others, and also allows exposing their key.

So developers can choose to wrap the children element with a newer one, and insert new props there or they can simply merge the props with React.

Say, we have an app component that uses a useModal and offers the ability to manage modals by using controls such as open, close, opened and activated. Before merging props to children, we can pass them to a VisbilityControl component which provides some additional functionality.

import React from 'react'

const UserContext = React.createContext({
  user: {
    firstName: 'Kelly',
    email: 'frogLover123@gmail.com',
  },
  activated: true,
})

const VisibilityControl = ({ children, opened, close }) => {
  const ctx = React.useContext(UserContext)
  return React.cloneElement(children, {
    opened: ctx.activated ? opened : false,
    onClick: close,
  })
}

export const useModal = ({ urls } = {}) => {
  const [opened, setOpened] = React.useState(false)
  const open = () => setOpened(true)
  const close = () => setOpened(false)

  return {
    opened,
    open,
    close,
  }
}

const App = ({ children }) => {
  const modal = useModal()

  return (
    <div>
      <button type="button" onClick={modal.opened ? modal.close : modal.open}>
        {modal.opened ? 'Close' : 'Open'} the Modal
      </button>
      <VisibilityControl {...modal}>{children}</VisibilityControl>
    </div>
  )
}

const Window = ({ opened }) => {
  if (!opened) return null
  return (
    <div style={{ border: '1px solid teal', padding: 12 }}>
      <h2>I am a window</h2>
    </div>
  )
}

export default () => (
  <App>
    <Window />
  </App>
)

Using Visibility control allows developers to ascertain whether the control activated is true before allowing the control opened to be used by children. In case the Visibility Control feature is used via a secret route, there’s an option to prevent unactivated users from accessing the content.

3. Making a larger reducer

It is possible to combine to or more reducer to make a single, much larger reducer that can help boost a react app.

Say, you think of building a large app that provides access to a wide variety of small services. How would you go about the development of such an app?

There are two options:

1. We can give each microservice within the app a separate part of its own from where its state and context can be managed directly.

2. Or we can combine all states into a single large state and manage all of them within the same environment.

The first approach seems to highly tedious, so obviously, the second one is the way to go.

Now we have three reducers to combine -

frogsreducer.js, authreducer.js and finally, ownersreducer.js.

Let's start with authReducer.js

const authReducer = (state, action) => {
  switch (action.type) {
    case 'set-authenticated':
      return { ...state, authenticated: action.authenticated }
    default:
      return state
  }
}

export default authReducer

ownersReducer.js

ownersReducer.js

const ownersReducer = (state, action) => {
  switch (action.type) {
    case 'add-owner':
      return {
        ...state,
        profiles: [...state.profiles, action.owner],
      }
    case 'add-owner-id':
      return { ...state, ids: [...state.ids, action.id] }
    default:
      return state
  }
}

export default ownersReducer

frogsReducer.js

const frogsReducer = (state, action) => {
  switch (action.type) {
    case 'add-frog':
      return {
        ...state,
        profiles: [...state.profiles, action.frog],
      }
    case 'add-frog-id':
      return { ...state, ids: [...state.ids, action.id] }
    default:
      return state
  }
}

export default frogsReducer

Now we can put all three into the main app file and define their state:

App.js

import React from 'react'
import authReducer from './authReducer'
import ownersReducer from './ownersReducer'
import frogsReducer from './frogsReducer'

const initialState = {
  auth: {
    authenticated: false,
  },
  owners: {
    profiles: [],
    ids: [],
  },
  frogs: {
    profiles: [],
    ids: [],
  },
}

function rootReducer(state, action) {
  return {
    auth: authReducer(state.auth, action),
    owners: ownersReducer(state.owners, action),
    frogs: frogsReducer(state.frogs, action),
  }
}

const useApp = () => {
  const [state, dispatch] = React.useReducer(rootReducer, initialState)

  const addFrog = (frog) => {
    dispatch({ type: 'add-frog', frog })
    dispatch({ type: 'add-frog-id', id: frog.id })
  }

  const addOwner = (owner) => {
    dispatch({ type: 'add-owner', owner })
    dispatch({ type: 'add-owner-id', id: owner.id })
  }

  React.useEffect(() => {
    console.log(state)
  }, [state])

  return {
    ...state,
    addFrog,
    addOwner,
  }
}

const App = () => {
  const { addFrog, addOwner } = useApp()

  const onAddFrog = () => {
    addFrog({
      name: 'giant_frog123',
      id: 'jakn39eaz01',
    })
  }

  const onAddOwner = () => {
    addOwner({
      name: 'bob_the_frog_lover',
      id: 'oaopskd2103z',
    })
  }

  return (
    <>
      <div>
        <button type="button" onClick={onAddFrog}>
          add frog
        </button>
        <button type="button" onClick={onAddOwner}>
          add owner
        </button>
      </div>
    </>
  )
}
export default () => <App />

This is what it looks like combining all three reducers into one large reducer, along with rootReducer

function rootReducer(state, action) {
  return {
    auth: authReducer(state.auth, action),
    owners: ownersReducer(state.owners, action),
    frogs: frogsReducer(state.frogs, action),
  }

This is what it looks like combining all three reducers into one large reducer, along with rootReducer.

Using Sentry for Analyzing Errors

Any mobile app development project can benefit greatly from Sentry. It provides everything a developer needs to handle errors and exceptions when building apps with React. Sentry identifies all errors and displays them at one central location so they can be accessed and analyzed all at once.

Getting started with Sentry on React is easy. Just use npm install @sentry/browser and set it up. Once done, developers can log in at sentry.io and analyze all error reports of a project on a single dashboard.

The error reports from sentry are incredibly detailed. They provide all sorts of important information which include the user’s device information, browser, URL, stack trace, how the error was handled, source code, IP address, breadcrumbs to trace the source of error, the error function name and much more.

5. Using Axios for HTTP requests

Though Axios is commonly used for HTTP requests. I felt it is important to mention this point because it's actually not common for developers to use other request libraries such as fetch for React apps.

Windows.fetch provides no support for Internet Explorer 11 (most don’t really care though). But for what it's worth, Axios does work there as well and offers the ability to cancel requests in mid-flight.

Final Words

The 5 mentioned methods can greatly help speed up your React app. It helps developers, the business you’re in and of course, those who’d be using it eventually. But honestly, the success of your React App mostly depends on those who work on them.

As a consumer, you’d want better performance from your app, so it is what denotes success. As a developer, these methods could make your app easier to develop, and efficiency is key to being more productive.

ValueCoders is an expert IT outsourcing company for software development. If you are looking for offshore React programmers or hire Android developers, feel free to get in touch.

Also, I hope this post helps you learn new things and get a deeper insight into what goes into making the perfect react application.

A Subject is a “special” type of observable that allows us to broadcast values to multiple subscribers. The cool thing about Subjects, is that it provides a real-time response.

For instance, if we have a subject with 10 subscribers, whenever we push values to the subject, we can see the value captured by each subscriber

This introduces a couple challenges; what if we push some values, and then subscribe, or vice-verse? Timing plays an important role, if we subscribe late, we won’t be able to access the values, similar to if someone enters a live-sport event on TV 30 minutes later.

Luckily, we have 4 types of Subjects that allows us to “time travel” in which we can access values even though we subscribe late or not.

Topics we’ll cover:

1. What is a Subject with a practical example
2. BehaviorSubject: Get the last message
3. ReplaySubject: Time travel
4. AsyncSubject: Once completed, get the last message

1. What is a Subject?

As mentioned, a Subject is nothing more like an observable with a few more characteristics. An observable is by definition an invokable collection that emits data once subscribed. Meanwhile, a Subject is where we control the state of “when to emit data” to multiple subscribers.

A Subject allows us to invoke methods like .next(), .complete() and .error() outside, while in an observable, we invoke these methods as callbacks.

// Creating an Observable
const observable = new Observable((observer) => {
    observer.next(10);
    observer.next(5);
    observer.complete();
});

// Creating a Subject
const subject = new Subject();
subject.next(10);
subject.next(5);
subject.complete();

Practical example: Let’s build a simple chat group using a Subject

Let’s imagine we are building a simple chat app where people can post messages to the chat group. The first step is to create an instance of the Subject, and then assign it to a chatGroup.

// Create subject "Observable"
const chatGroup = new Subject();

Now that our chat group (Subject) is created, the next thing to do is add messages. Let’s create a typical conversation between two friends.

// Push values to the stream
chatGroup.next('David - Hi, which hot series do you recommend?');
chatGroup.next('Peter - Game of Thrones, Bodyguard or Narcos are few of the good ones');
chatGroup.next('David - Interesting, which one is the hottest?');
chatGroup.next('Peter - Game of Thrones!');

So far so good — now we have 4 messages posted in our chat group, so what happens if we subscribe? Or let’s say a new friend named John wants to join the conversation. Is he be able to see the old messages?

// Print messages
chatGroup.subscribe((messages) => {
    console.log(messages)
})

Unfortunately not, John misses the conversation because he’s subscribes late. This is a perfect example of how reactive programming works — the idea of values passing over time, and thus, we must subscribe in the right time to access the values.

To further elaborate on the previous example, what if John enters in the middle of the conversation?

// Push values to the stream
chatGroup.next('David - Hi, which hot series do you recommend?');
chatGroup.next('Peter - Game of Thrones, Bodyguard or Narcos are few of the good ones');

// John enters the conversation 
chatGroup.subscribe((messages) => {
    console.log(messages)
});

chatGroup.next('David - Interesting, which one is the hottest?');
chatGroup.next('Peter - Game of Thrones!');

// OUTPUT
// David - Interesting, which one is the hottest?
// Peter - Game of Thrones!

Once John subscribes, he sees the two last messages. The Subject is doing what it’s intended to do. But what if we want John to view all messages, or just the last one, or get notified when a new message is posted?

In general, these Subjects are mostly similar, but each one provides some extra functionality, let’s describe them one by one.

2. BehaviorSubject: Get last message

The BehaviorSubject is similar to a Subject except it requires an initial value as an argument to mark the starting point of the data stream. The reason is because when we subscribe, it returns the last message. This is similar concept when dealing with arrays; where we do array.length-1 to get the latest value.

import {BehaviorSubject } from "rxjs";

// Create a Subject
const chatGroup = new BehaviorSubject('Starting point');

// Push values to the data stream
chatGroup.next('David - Hi, which hot series do you recommend?');
chatGroup.next('Peter - Game of Thrones, Bodyguard or Narcos are few of the good ones');
chatGroup.next('David - Interesting, which one is the hottest?');
chatGroup.next('Peter - Game of Thrones!');

// John enters the conversation
chatGroup.subscribe((messages) => {
    console.log(messages)
})

// OUTPUT
// Peter - Game of Thrones!

3. ReplaySubject: Time travel

The ReplaySubject, as the name implies, once subscribed it broadcasts all messages, despite if we subscribed late or not. It’s like time travel, where we can access all the values that were broadcast.

import { ReplaySubject } from "rxjs";

// Create a Subject
const chatGroup = new ReplaySubject();

// Push values to the data stream
chatGroup.next('David - Hi, which hot series do you recommend?');
chatGroup.next('Peter - Game of Thrones, Bodyguard or Narcos are few of the good ones');
chatGroup.next('David - Interesting, which one is the hottest?');
chatGroup.next('Peter - Game of Thrones!');

// John enters the conversation
chatGroup.subscribe((messages) => {
    console.log(messages)
})

// OUTPUT
// David - Hi, which hot series do you recommend?'
// Peter - Game of Thrones, Bodyguard or Narcos are few of the good ones'
// David - Interesting, which one is the hottest?'
// Peter - Game of Thrones!'

4. AsyncSubject: Once completed, get last message

The AsyncSubject is similar to BehaviorSubject in terms of emitting the last value once subscribed. The only difference is that it requires a complete() method to mark the stream as completed. Once that is done, the last value is emitted.

import { AsyncSubject } from "rxjs";

// Create a Subject
const chatGroup = new AsyncSubject();

// Push values to the data stream
chatGroup.next('David - Hi, which hot series do you recommend?');
chatGroup.next('Peter - Game of Thrones, Bodyguard or Narcos are few of the good ones');
chatGroup.next('David - Interesting, which one is the hottest?');
chatGroup.next('Peter - Game of Thrones!');

chatGroup.complete(); // <-- Mark the stream as completed

// John enters the conversation
chatGroup.subscribe((messages) => {
    console.log(messages)
})

// OUTPUT
// Peter - Game of Thrones!'

Summary

Back to our previous example with John, we can now decide if we want John to access the whole conversation (ReplaySubject), the last message (BehaviorSubject), or the last message once the conversation completes (AsyncSubject).

If you ever struggle to identify if a Subject is the right way to go, the article “To Use a Subject or Not to Use a Subject” by Dave Sixton describes when to use Subjects based on two criteria:

1. Only when one want to convert a cold Observable into a hot observable.
2. Generate a hot observable that passes data continuously.

In short, only creativity limits the potential use of reactive programming. There will be some scenarios where Observables do most of the heavy-lifting, but understanding what Subjects are, and what type of Subjects exists, will definitely improve your reactive programming skills.

If you are interested to learn more about the web-ecosystem, here are few articles I’ve written, enjoy.

• A comparison between Angular and React
• A practical guide to ES6 modules
• [How to perform HTTP requests using the Fetch API](http://A practical ES6 guide on how to perform HTTP requests using the Fetch API)
• Important web concepts to learn
• Boost your skills with these JavaScript methods
• Create custom bash commands

You can find me on Medium where I publish on a weekly basis. Or you can follow me on Twitter, where I post relevant web development tips and tricks.

One of the most challenging things for new developers to learn is the observer pattern. Understanding how to effectively use it with RxJS to deal with asynchronous data such as user events, HTTP requests or any other events that require waiting for something to complete is tricky.

What most people struggle with is the new approach. It requires a different mindset where visualization plays an important role. We think of data as a sequence of values that passes over time rather than as one single value that is retrieved once. This mindset is known as reactive programming.

Since the Observer pattern is a fairly large ecosystem consisting of many important parts, I’ve chosen to narrow it down by focusing on Observables only. I’ll share other articles soon that cover the rest of the Observer pattern, such as how to deal with RxJS.

Topics we’ll cover:

1. What does asynchronous really mean?
2. Which pattern to use (Observer or Promise)
3. How to create an Observable (code examples start here)
4. How to subscribe to an Observable
5. How to unsubscribe to an Observable

1. What does asynchronous really mean?

One of the things with the web, and the majority of languages, is that once you ask for data such as requesting a list of users from the server, you can’t guarantee that the data will be returned. There is an uncertainty issue.

One of the reasons may be that the data is not present, the server may be broken, or the HTTP URL is not valid because someone has changed the query string.

For that reason, along with a few others, we need to deal with such data asynchronously. We request the list of users, and wait until it is retrieved, but don’t stop the whole application for a simple operation.

It’s like telling a coworker to solve a task instead of sending the whole team; that would be an expensive and not a wise approach to take.

Let’s clarify a misconception: the terms synchronous or asynchronous have nothing to do with multi-threading, where operations are executed at the same time. It simply means the operations are either dependent on or independent from each other, that’s it.

Let’s compare the difference between synchronous and asynchronous to better understand how they really work.

What is Synchronous?

With Synchronous events, you wait for one to finish before moving on to another task.

Example: You are in a queue to get a movie ticket. You cannot get one until everybody in front of you gets one, and the same applies to the people queued behind you. Answered by themightysapien.

What is Asynchronous?

With asynchronous events, you don’t wait, you can move on to the next task until the data is available.

Example: You are in a restaurant with many other people. You order your food. Other people can also order their food, they don’t have to wait for your food to be cooked and served to you before they can order. In the kitchen, restaurant workers are continuously cooking, serving, and taking orders. People will get their food served as soon as it is cooked. Answered by themightysapien.

Alright, so in short, this allows us to either wait for operations to happen before we can move on, or not wait until the data is ready.

2. Which pattern to use (Observer or Promise)

First of all, both the observer pattern and the promise pattern deal with asynchronous operations. Operations such as user events or HTTP requests, or any other events that execute independently.

The majority of operations today need some type of asynchronous/synchronous handling, and understanding how it works plays an important role when building robust apps.

It’s not meant to make your life harder, but easier. However, it thus requires a learning-curve which may be a painful approach, but the reward at the end is well worth it.

Stay with one pattern

The difference lies in the complexity of the application. If you deal with a small app where the task is to simply get a list of users from the server, or to show active members, then promises with the Fetch API (read more) work fine.

But if you deal with a large application with many asynchronous operations that require changing the data, performing multiple operations on a data stream, or reusing it in multiple places, then the observer pattern works great.

Can I use both patterns in one project?

Yes, but it’s not recommended that you mix between two architectures which basically do the same thing (handle asynchronous events). Instead, stick with one, and learn more about it.

Boost your skills with RxJS

With RxJS, you have access to 189 operators with documentation + other great resources. And each of these operators are simply callbacks that do something on the data stream.

If you are familiar with JavaScript’s functional prototypes (methods) such as map(), filter(), and reduce(), you’ll find them in RxJS. Note, the concept is the same but the written code is not.

So what is the difference between these two patterns?

Observable vs Promise

Here’s a quick comparison between the observer pattern and the promise pattern. The key points are that a promise emits a single value(s) once the .then() callback is used, while an Observable emits multiple values as a sequence of data that passes over time. Another important point is that an Observable can be canceled or retried while a promise cannot. However, there are external packages that make it possible to cancel a promise.

3. How do we create an Observable?

Here are a couple of ways one can create an Observable:

• create an Observable from scratch
• turn a promise into an Observable
• or use a framework that does it for you behind the scenes, such as Angular.

Did you know that Angular uses the Observer pattern extensively? All asynchronous operations such as HTTP GET or listening for events or value changes follow the observer pattern.

If you ever want to mimic (test) a real-world scenario, so to say pass values over time, I highly recommend using the interval function. This passes values after x time in milliseconds. So if you have an interval where x is 2000ms — it passes each value (increments) after 2 seconds.

4. How do we subscribe to an Observable?

An Observable is simply a collection of data that waits to be invoked (subscribed) before it can emit any data. If you’ve worked with promises, then the way to access the data is to chain it with the then() operator or use the ES6 async/await.

So to follow the previous example, how does one access the data?

As shown above, when we subscribe, we tell the Observable to pass us whatever it holds. It can be an array, a collection of events, or a sequence of objects and so forth.

A common beginner-mistake I’ve seen among developers is that they do many operations on the Observable but get frustrated because they can’t see any results. You are not alone! I’ve made this mistake a couple of times and as a thumb-rule — always remember to subscribe.

5. How do we unsubscribe to an Observable?

It is important to unsubscribe, otherwise we end up with a memory leak which slows down the browser. If you’ve worked with Angular, there is a pipe named asyncPipe which subscribes and unsubscribes automatically for you.

The way we unsubscribe is that we create a reference to each Observable that is subscribed by creating a variable to preserve its current state. And then, for each variable, we chain it with the unsubscribe() method. Remember that you can only unsubscribe after you’ve subscribed. It’s fairly simple but often forgotten.

Notice, if you unsubscribe here, Observable_1 and Observable_2 will output the data before it is unsubscribe because these are cold Observables (not time-dependent), while Observable_3 and Observable_4 will not output anything because these are hot Observables (time-dependent).

Summary

As mentioned above, the most challenging part of learning the observer pattern is the mindset. A mindset where we look at values differently, such as a sequence of data that emits over time. In this article, we’ve covered types of ways we can create an Observable, as well as how to subscribe and unsubscribe.

I recommend using the observer pattern because it provides everything that the promise pattern offers, and much more. It also provides a few great operators to prevent users from sending thousands of unnecessary requests to the backend.

One of them is debonceTime which gives the user enough time to write a complete word, and then send one request instead of a request for every character. You can, of course, achieve this with a simple promise, but that requires some lines of code.

I’ll cover more about reactive programming in the near future, stay tuned!

If you are interested to learn more about the web-ecosystem, here are few articles I’ve written to boost your web skills, enjoy :)

• Boost your skills with these JavaScript methods
• A comparison between Angular and React
• A practical guide to ES6 modules
• [How to perform HTTP requests using the Fetch API](http://A practical ES6 guide on how to perform HTTP requests using the Fetch API)
• Important web concepts to learn

If you want to become a better web developer, start your own business, teach others, or improve your development skills, you can find me on Medium where I publish on a weekly basis. Or you can follow me on Twitter, where I post relevant web development tips and tricks.

P.S. If you enjoyed this article and want more like these, please clap ❤ and share with friends that may need it, it’s good karma.

I loved DragonBall Z as a kid, and still love it as an adult.

Among the ludicrous number of transformations, the original Super Saiyan remains my favorite.

Nothing quite like the original

I’m also loving RxJS the more I level up with it, so why not combine these two for the ultimate showdown?

Let’s Go Super Saiyan

With four sprite sheets and a bit of HTML, CSS, and RxJS, we can recreate this legendary transformation!

This is what we’ll be making. Exciting, right?! ?

Setup

Everything’s on my GitHub.

cd ./wherever-you-want
git clone [https://github.com/yazeedb/dbz-rxjs](https://github.com/yazeedb/dbz-rxjs)
cd dbz-rxjs

Open index.html in your favorite browser, and the project in your favorite text editor, and you’re ready to go!

No npm installs today ?

And going forward, I’ll use the acronym “SSJ” instead of “Super Saiyan” for brevity.

First Day of Training

You’ll notice that Goku’s already moving. Since we’re focusing on RxJS, we’ll just skim the project’s starting point.

Here’s the main HTML:

<div id="root">
  <div id="meter-container">
    <span>Hold any key to POWER UP!</span>
    <div id="meter"></div>
  </div>

  <div id="sprite" class="base"></div>
</div>

The bottom div has class="base", which corresponds to this CSS:

.base,
.ssj {
  width: 120px;
  height: 250px;
  animation: stand 0.8s steps(2) infinite;
}

.base {
  background-image: url('img/goku-standing-sheet.png');
}

This sets Goku’s width, height, and standing animation.

If you look at his base/ssj sprite sheets, it’s two different positions and we’re switching between them every 0.8 seconds.

The switching’s handled towards the bottom of style.css:

@keyframes stand {
  from {
    background-position: 0px;
  }
  to {
    background-position: -255px;
  }
}

Same thing for power up:

@keyframes powerup {
  from {
    background-position: 0px;
  }
  to {
    background-position: -513px;
  }
}

We’ll cover the power up meter when we manipulate it.

Mastering the DOM Elements

index.html already includes RxJS@6.2.1 via CDN, so you’re covered.

In app.js, let’s capture the DOM elements we’re interested in:

const sprite = document.querySelector('#sprite');
const meterContainer = document.querySelector('#meter-container');
const meter = document.querySelector('#meter');

I prefer to alias document.querySelector so using it doesn’t cause me wrist pain.

const $ = document.querySelector.bind(document);**
const sprite = $('#sprite');
const meterContainer = $('#meter-container');
const meter = $('#meter');

Next, we’ll create a main function and immediately call it.

// ...

const main = () => {
  // do something
};
main();

Powering Up

Here is main’s first code snippet:

const main = () => {
  const { fromEvent } = rxjs;

  const begin = fromEvent(document, 'keydown');
  const end = fromEvent(document, 'keyup');
};

Goku should power up when a key is held down, and stop when that key is let go. We can use the fromEvent operator to create two observables:

• begin: Notifies when the user presses a key down.
• end: Notifies whenever the user lets go of a key.

Then we can subscribe to these emissions and act upon them. To get the power up animation, give sprite the powerup class name.

begin.subscribe(() => {
  sprite.classList.add('powerup');
});

It works, but pressing a key causes him to power up forever…

We must also subscribe to the end observable, so we know when the key has been let go.

end.subscribe(() => {
  sprite.classList.remove('powerup');
});

Now he powers up and down at your command.

Building a Scouter

Any DBZ fan has seen a scouter, the little eyewear used to track power levels (until like episode 20…).

Obligatory > 9000 joke

As Saiyans power up, their power level grows. Inconceivable, right?

We need a way to track Goku’s power level as he ascends, and trigger the SSJ transformation after say, 100 points.

We can start his power off at 1, and increase it while the user holds a key down.

RxJS Operators

Operators are where RxJS really shines. We can use pure functions to describe how data should transform through the stream.

When the user holds a key down, let’s transform those emissions into a number that increases over time.

Scan

The scan operator is perfect for this. It’s like Array.reduce, but it emits as it’s reducing.

For example, if you have an array of numbers:

nums = [1, 2, 3, 4, 5];

And wish to add them up, reduce is a great choice.

nums.reduce((a, b) => a + b, 0);
// 15

What if you want to see each addition as it happens?

Enter scan. You can run this in our app’s console.

const { from } = rxjs;
const { scan } = rxjs.operators;

from([1, 2, 3, 4, 5])
  .pipe(scan((a, b) => a + b, 0))
  .subscribe(console.log);

// 1 (0 + 1)
// 3 (1 + 2)
// 6 (3 + 3)
// 10 (6 + 4)
// 15 (10 + 5)

See how the emissions increase over time? We can do that with Goku as he powers up!

const { fromEvent } = rxjs;
const { scan, tap } = rxjs.operators;

const begin = fromEvent(document, 'keydown');
const end = fromEvent(document, 'keyup');

begin
  .pipe(
    scan((level) => level + 1, 1),
    tap((level) => {
      console.log({ level });
    })
  )
  .subscribe(() => {
    sprite.classList.add('powerup');
  });

We start his level at 1 and increase it by 1 every time the keydown event fires.

And the tap operator operator lets us quickly log the value without disturbing the pipeline.

My power infinitely approaches MAXIMUM!

Going Super Saiyan

We’ve trained hard, it’s time to transform.

The scan operator tracks Goku’s power level. Now we need to go SSJ when it emits 100.

I built a map of levels: transformations. You can put it right above main.

const powerLevels = {
  100: {
    current: 'base',
    next: 'ssj'
  }
};

const main = () => {
  // ...
};

It’s overkill, but should simplify adding future transformations.

When the power level reaches a number in that powerLevels map, we’ll remove its current class from sprite and add the next class.

This lets us smoothly go from one transformation to the next.

Here’s the code.

const { fromEvent } = rxjs;
const { filter, map, scan, tap } = rxjs.operators;

const begin = fromEvent(document, 'keydown');
const end = fromEvent(document, 'keyup');

begin
  .pipe(
    scan((level) => level + 1, 1),
    tap((level) => {
      console.log({ level });
      sprite.classList.add('powerup');
    }),
    map((level) => powerLevels[level]),
    filter((level) => level && level.next)
  )
  .subscribe(({ current, next }) => {
    sprite.classList.remove(current);
    sprite.classList.add(next);
  });

Map and Filter

Adding the powerup class now happens inside of tap, because it should always happen. The SSJ transformation however, shouldn’t always happen.

Using map, the latest power level becomes an entry in the powerLevels map. We use filter to check if the entry exists and has a .next property.

If it does, that means Goku can go even further beyond! Our .subscribe will swap current and next as class names on sprite.

The end result?

Power Meter

You’re having as much fun as I am, right? Unfortunately, our user won’t.

They can’t see how high Goku’s power level is! They won’t know how to open the DevTools console. We must remedy this!

Let’s improve our UX by filling the power meter. You can put this above main.

const fillMeter = (level) => {
  const limit = 100;

  if (level >= limit) {
    return;
  }

  const containerWidth = meterContainer.offsetWidth;
  const newWidth = (level / limit) * containerWidth;

  meter.style.width = `${newWidth}px`;
};

And call it inside tap.

tap((level) => {
  console.log({ level });
  sprite.classList.add('powerup');
  fillMeter(level);
});

And here we go:

Going Even Further Beyond

Unlocking more transformations is just a matter of adding sprites, and updating our powerLevels map. If you’re interested, submit a PR on the repo and we’ll definitely talk.

Here’s the original sprite sheet. Enjoy!

The Flux architecture gained popularity after Facebook adopted it. It’s a way of managing the state of React components so that the flow of the data through the app is unidirectional.

The advantages of this approach are that the app is comprised of few stateful components that passes state down to nested child components. A feature of React that really complements this approach to state management is that React allows us to write UI as a function of state. This means that, as state percolates down the app’s component hierarchy, components automatically change the view to reflect the changes in state.

JSX, a templating system used by React, allows for the creation of reusable single file components.

It also lends itself really well to creating a demarcation between the structure of the DOM and the behaviours associated with it.

• JSX gives a clean view of the DOM structure that is more intuitive than the several lines of JavaScript required to create the same DOM structure.
• The behaviours associated with the DOM structure — eventHandlers like onClick, onHover — are handled as member functions of the component.
• Any changes to the DOM structure require the user to call setState to change the state of the component instead of directly mutating the DOM. This makes it easier to debug the application, and it also ensures that the application is always in a defined state.

As the complexity of the app grew, however, the Flux approach also began to show its limitations.

Few stateful components passing state down to child components seem fine for small apps. But, as the complexity of the component hierarchy increases, stateful components have to share state with each other.

While it is possible to share state across different components/classes in JavaScript through common variables or, preferably, the Observer pattern, as the number of components increases it becomes harder to maintain the application.

The simplicity of components reacting to changes in state is muddled with the complexities of object-oriented design.

Charts — why are they hard to make?

The advances that web apps have benefited from have not changed the way that charting libraries are made. A chart is also a presentational component, and can technically be termed as UI. A chart is also composed of DOM elements that control its visual appearance.

However, charts differ in one key aspect: developers don’t treat SVG as DOM. Technically, the <svg> tag is not even an HTMLElement like other DOM elements, and sits in a separate namespace. SVG is only known for its ability to scale to any viewport size and maintain the resolution of the image at a constant level. That’s the extent to which most developers know about it.

Also the tags used to create an SVG image like <point>, &lt;rect />, and sound very “math like.” This makes developers shy away from how SVG structures actually work.

Even those involved with applications that make heavy use of SVG are usually unaware of its inner workings. They utilise other libraries like snap or d3 to avoid the hassle of understanding what goes on under the hood.

Having avoided the underlying complexity of the SVG tag, it feels easy to model complex SVG constructs.

Geometry

Consider a bar chart, for example.

A nice bar chart.

We traditionally adopt a cookie cutter approach and split a chart into parts:

• x-axis
• y-axis
• bars

A seasoned developer would notice that the word axis was written twice in the above list. So lets create an abstraction layer called Axis that subclasses can inherit from.

To render the bars, we can create a separate class called Bar that utilises the scale provided by the axis class. As charts come in various shapes, it makes more sense to have an abstraction layer called Geometry that other classes can inherit from, namely Bar, Point, Line, and Area. As more complex charts are made, several new geometry types can be added to render different kinds of charts.

Following the above methodology, a chart comprises three or more stateful components that utilise each others’ properties to render a meaningful chart.

To update or enhance the chart, a developer is expected to know the state to mutate in each of these components. Since state is scattered across various components, even simple changes take a lot of time for new developers. The ordering of the state changes also becomes relevant.

In the above example, the geometry utilises the scale of the axes. For the chart to be resized, the range of each axis has to be updated before updating the Geometry.

Not following this ordering will lead to visual artefacts — because the geometry would be distorted due to an invalid scale. At worst, failure to carry out this ordered sequence of operations could leave the chart in an undefined state.

Having cross-connectivity between charts further compounds this problem. The orchestration of state changes spans multiple charts/interacting components.

Having so many interacting components with directed relationships can also lead to cyclic dependencies between components.

This was a problem that plagued UI development frameworks as well until developing web applications with a single source of truth became the standard. The most influential library in directing the shift to single source of truth webapps was Redux.

Note: The next section explains how using Redux makes web app development easier. Feel free to skip it if you already know about Redux.

Redux

Redux is a library developed by Dan Abhramov. It helps ease the burden of developers by providing an easy way to maintain the state of an application.

Redux introduced the concept of a state store that acted as the single source of truth for the entire application. Instead of components directly mutating the state, each component would dispatch an action that would commit a change to the unified state store.

Each action was identified by a unique enum that would be logged every time a change was committed to the state store. This made it easy to track how the state store was being mutated.

Once a change was committed to the state store, the new state would percolate down the component hierarchy. Components would re-render or ignore the change depending on whether the part of the state that changed was relevant to them. Components could no longer mutate the state in isolation. It had to be at a global level.

The main purpose is to isolate state management from side effects like rendering and fetching data from the server. Always leave the application in a defined state.

This lays the foundation for a deterministic view render. Given a sequence of state changes, you will always end up with the same rendered view.

This level of deterministic view rendering is especially helpful for offline applications. Here, the sequence of state mutations that happen while user is offline can be stored and replayed when connectivity is re-established to get back the same view.

The success of of the React-Redux model spawned a number of other libraries like Vue and Cycle, as well as several other implementations of the state store like MobX and Vuex.

A closer look at SVG

SVG stands for scalable vector graphics. The svg tag can optionally house various kinds of geometry, which expose a number of DOM attributes.

Circle: <circle />

Attributes:

• cx: x offset of circle in viewport
• cy: y offset of circle in viewport
• r : radius of circle

Polyline: <polyline />

Attributes:

• points: array of points (x, y) through which a line is drawn.

Polygon: <polygon />

Attributes:

• points: array of points (x, y) to construct a polygon.

Text: <text />

Attributes:

• x: x offset of text in viewport
• y: y offset of text in viewport
• innerText: The text to show.

Many more geometry types are available in the SVG standard, but for the purposes of charts, the above will suffice. These geometric elements can also be styled with normal CSS.

Finding a bridge

These are the guiding principles behind modern web application development and development of charting libraries. Let’s try to isolate where developing charting libraries differs from web applications:

• web apps are composed of DOM nodes. Charts are composed of SVG geometries.
• web apps can be broken down into reusable sections of DOM that can be modelled as components. Charts aren’t modelled as reusable set of geometries.
• web app frameworks are always coupled with a templating engine so that DOM structure can be modelled in markup and the behaviours can be separated from it and written in JavaScript. Charts have no such framework available.
• web app frameworks allow for a state store to be incorporated through the use of a plugin. Charts are usually modelled as stateful components.

Remodelling chart complexity

A chart is a visual tool that showcases variation across fields in the data using geometry.

So how does that work?

A nice scatter plot

Looking at the chart above, what do we see? Circles offset in the viewport based on fields present in the data.

What else?

• Ticks offset along the bottom based on a field in the data.
• Text labels offset along the bottom based on a field in the data.
• Same as above along the left side of the chart.

Let’s break it down to the level of geometries.

How do we render the circles in the scatterplot?

<circle cx=”horsepowerScale()” cy=”milesPerGallonScale()” cr=”const” />

What about the axes? X-Axes: Text + Ticks

<text x=”horsepowerScale()” y=”0”>{{ text value }}&lt;/text>

<tick x=”horsepwerScale()” y=”0” />

There is a similar SVG structure for the y-axis, except that the scale function changes and the x, y fields are inverted.

The common theme above is that the chart is viewed as a meaningful arrangement of geometry:

• each geometry in the SVG namespace exposes visual attributes
• the value of these attributes is bound to a calculated value
• the calculated value depends on the scale
• the scale depends on a field in the data and the range

What is a scale?

A scale is a function that maps data to a position in the viewport.

What is the input to scale?

• the domain of the field
• the length of the viewport to map to

Let R be the length of viewport and D be the domain of the data.

• Then we can define a scaling function S as:
• S = f(D, R) + b

where b is a constant.

How many scales does a chart need to have?

If you’re thinking two, then you’re wrong.

Scale doesn’t exist only along x- and y-axes. The axes themselves are only present in a chart as visual anchors so that users can line up data variations along multiple dimensions.

The axis is just geometry that is rendered using a scale.

How many dimensions are there?

It’s not two. The viewport is two-dimensional but that has nothing to do with the dimensionality of the chart. The dimensionality of a chart is defined by the number of scaling functions used.

The overarching concept comprises of two simple terms: Geometry and Scale.

Each geometry exposes visual attributes that control its appearance.

The value of these attributes can be hooked up to scaling functions. The scaling function is tied to a particular field in the data.

This lends itself to the idea that every visual attribute in a chart can only be tied to one field in the data table.

Given this decomposition of charts we can model the scatter plot above as follows:

The field Horsepower is used to create a scaling function called horsepowerScale().

The field Acceleration is used to create a scaling function called accelerationScale().

Since we are not varying the size of the circles, only two scaling functions are required.

Any circle i in the scatterplot can be represented as

<circle cx="horsepowerScale(ti)" cy="accelerationScale(ti)" cr="5" />

where ti is the ith tuple in the Datatable.

Given that only two scaling functions were used, the dimensionality of the above chart becomes two.

If we also modulated the size of each circle, using a scaling function tied to another field, then the dimensionality would be three.

Doing so would result in what is known as a “bubble chart”.

Grammar of Graphics

This is similar to the Grammar of Graphics (GOG) approach, where every chart is defined by a mark (geometry) and the visual encodings used by the mark.

In a GOG approach the scatterplot would be represented as:

{

    mark: 'circle',

    encoding: {

        x: 'horsepower',

        y: 'acceleration'

    }

}

Notice that there is a one-to-one mapping between the encoding of a GOG geometry and the visual attributes exposed by the geometry in SVG.

The axis can also be rendered similarly:

• The x-axis is a tick geometry with its x-offset attribute tied to horsepowerScale() and its y-offset set to 0.
• The y-axis is a tick geometry with its y-offset attribute tied to accelerationScale() and its x-offset set to 0.

To render the scatterplot with all its elements, the following snippet of code would suffice:

Decomposition of charts into an association between visual attributes and a scaling function allows us to view a chart as a web app.

Web Application frameworks model UI as a function of state.

Charts Frameworks should model geometry as a function of scale.

So the idea that makes web applications easy to develop can easily be extended to creating charts:

• Initially, tabular data is supplied as input.
• For every field in the Data array, a scaling function is created. The scaling function selectively recomputes values when a field in the column is tied to changes. The same scaling function is percolated throughout the application.
• Every geometry is modelled as a component that exposes visual attributes.
• The value of these visual attributes is tied to a scaling function that reacts to changes in data.
• The collections of geometry can be represented in markup using a templating engine of choice like hyperHTML, mustache, or handlebars. Ideally, the templating engine should be introduced as a plugin so that we can avoid writing bindings for different libraries like React and Angular.
• The state store that selectively computes scales should also be introduced as a plugin.

Let’s see what putting a chart together using the above principles would look like:

We are using React as a templating engine and Redux as the state store in the above example.

The above approach is just a rough implementation of what a framework that can model charts as webapps would would like like.

Notice the separation of the templating engine and state store from the actual rendering logic.

Final points

Ideally, geometries/charts that we create should be available as components in the framework of the user’s choice along with their state store. If it seems unthinkable that something like this could even be done, stay calm. It’s been done before.

SkateJS is a compiler that creates web components but allows user to switch internal rendering engines.

Users can choose between React, Preact, lit-html or extend the Renderer interface to write their own. The default renderer just mutates the DOM directly.

We can be even more ambitious with what we choose once we have synchronous rendering coupled with state management.

Imagine a TickProvider component that allows for rendering only small clusters of geometry in a given animation frame as well as allowing us to identify bottlenecks in our rendering pipeline.

Given that a chart is meaningful arrangement of geometry, it follows that meaningful clusters of geometry should render together.

In the scatter plot example, for every group of circles that render, the corresponding sections of the x/y axis geometry should also render simultaneously.

If we break the rendering into chunks, where each chunk consists of one meaningful cluster of geometry as modelled above, we can support beautiful transitions that add to the visual appeal of the chart.

Another advantage of a TickProvider is that we can profile and ensure that each cluster of geometry renders completely in the time allotted per tick. This will help avoid freezing of the UI when the geometry count to be rendered is very large. Instead of running a render loop over the entire geometry collection, we could batch the render calls in sync with the animation frames.

We can also break down the calculation of visual attribute values.

Consider a data table that has N fields being used to render dashboards with the above approach.

Since we are using a centralised state store, we can calculate the values of the N scaling function and memorize them. They only need to be re-calculated when the associated data table field changes.

Also, consider the equation below that computes the value of m visual attributes based on the scaling functions.

The 0th value for a visual attribute V, that is bound to field 0 of N, can be calculated as follows:

V(0) = S(d0, R) + b0

• where d0 is the 0th data tuple from the data table
• R is the range supplied as a prop to the component
• b0 is constant

If we write a series of such equations together we see this:

V(0) = S(d0, R) + b0

V(1) = S(d1, R) + b1

V(2) = S(d2, R) + b2

..

V(m) = S(dm, R) + bm

The scaling function itself can be expressed as a linear equation. We have a set of linear equations that can be batch computed to calculate the value for visual attributes.

How so?

The above arrangement looks suspiciously like a matrix.

Computations in the browser are slow, but matrix computations can be sped up by leveraging GPU acceleration.

Modelling the chart as geometry as a function of scale could therefore help us render charts much faster, as well handle larger volumes of data with a fast first render.

Data Visualisation is something that help us glean insights from large quantities of data. The impact that it has on decision making is slowly going up with multiple organisations looking to make data driven decisions.

Safe to say, we need a more robust, accessible and maintainable way of developing visualisations.

What do you think?

RxTest and RxBlocking are part of the RxSwift repository. They are made available via separate pods, however, and so require separate imports.

RxTest provides useful additions for testing Rx code. It includes TestScheduler, which is a virtual time scheduler, and provides methods for adding events at precise time intervals.

RxBlocking, on the other hand, enables you to convert a regular Observable sequence to a blocking observable, which blocks the thread it’s running on until the observable sequence completes or a specified timeout is reached. This makes testing asynchronous operations much easier.

Let’s look at each one now.

RxTest

As described above, RxTest is part of the same repository as RxSwift. There is one more thing to know about RxTest before we dive into some RxTesting: RxTest exposes two types of Observables for testing purposes.

• HotObservables
• ColdObservables

HotObservables replay events at specified times using a test scheduler, regardless of whether there are any subscribers.

ColdObservables work more like regular Observables, replaying their elements to their new subscribers upon subscription.

RxBlocking

If you are familiar with expectations in XCTest, you will know that it’s another way to test asynchronous operations. Using RxBlocking just happens to be way easier. Let’s start with a small implementation so we can see how to take advantage of this library while testing asynchronous operations.

Testing with RxBlocking

We will start a new test and create an Observable of 10, 20, and 30, as follows:

func testBlocking(){        let observableToTest = Observable.of(10, 20, 30)    }

Now we will define the result as equal to calling toBlocking() on the observable we created:

let result = observableToTest.toBlocking()

toBlocking() returns a blocking Observable to a straight array, as you can see here:

We will need to use the first method if we want to discover which is a throwing method. So we will wrap it in a do catch statement, and then we will add an AssertEquals statement if it is successful, as follows:

func testBlocking(){        let observableToTest = Observable.of(10, 20, 30)        do{            let result = try observableToTest.toBlocking().first()            XCTAssertEqual(result, 10)        } catch {        }    }

Alternatively, an Assert fails if it’s not this:

do{            let result = try observableToTest.toBlocking().first()            XCTAssertEqual(result, 10)        } catch {            XCTFail(error.localizedDescription)        }

That’s it! Let’s run the test, and you will see that the test passes. We can simplify this test with just two lines of code by forcing the try.

Again, this is more acceptable on test than production code. We will comment out the do catch statement and then write the assert equals in a single line, as follows:

XCTAssertEqual(try! observableToTest.toBlocking().first(), 10)

Rerun the test, and you will see that the test passes once again. The overall code with comments looks like this:

func testBlocking(){        let observableToTest = Observable.of(10, 20, 30)//        do{//            let result = try observableToTest.toBlocking().first()//            XCTAssertEqual(result, 10)//        } catch {//            XCTFail(error.localizedDescription)//        }        XCTAssertEqual(try! observableToTest.toBlocking().first(), 10)    }

How’s that for succinct? Truth be told, that Observable sequence would actually be synchronous already if we printed emitted elements in a subscription to it followed by a marker. The marker will be printed after the subscription’s completed event.

To test an actual asynchronous operation, we will write one more test. This time, we will use a concurrent scheduler on a background thread, as follows:

func testAsynchronousToArry(){        let scheduler = ConcurrentDispatchQueueScheduler(qos: .background)    }

Now, we will create an Observable of the simple sequence of integers. We will use map to double each value, as follows:

let intObservbale = Observable.of(10, 20, 30)            .map{ $0 * 2 }

Then, we will subscribe on the scheduler:

let intObservbale = Observable.of(10, 20, 30)            .map{ $0 * 2 }            .subscribeOn(scheduler)

Now we will write a do catch statement that is similar to the last test and calls toBlocking on the Observable, which should be observed on the main scheduler, as follows:

do{   let result = try intObservbale.observeOn(MainScheduler.instance).toBlocking().toArray()   } catch {   }

Then, we will add the same assertions as the previous example:

do{   let result = try intObservbale.observeOn(MainScheduler.instance).toBlocking().toArray()            XCTAssertEqual(result, [20, 40, 60])        } catch {            XCTFail(error.localizedDescription)        }

Now we will run the test, and you will note that it passes with the green check mark in the gutter.

Note that the marker is printed before the emitted elements in the console, as shown:

This is because these operations were executed asynchronously.

For other updates you can follow me on Twitter on my twitter handle @NavRudraSambyal

To work with examples of hot and cold observables, you can find the link to my book Reactive programming in Swift 4

Thanks for reading, please share it if you found it useful :)

Phone Number Authentication

Many mobile applications require membership. Most of them provide user authentication. This is because you need to check whether the user in use is the same as the subscriber when preventing duplicate subscriptions or changing passwords.

Most mobile applications use a phone number to authenticate users, since they run on mobile phones. Phone number authentication consists of several steps, which means state management is required. You must also change the UI accordingly. This also requires asynchronous event handling, such as requesting a verification code and passing user-entered code to the server.

Therefore, phone number authentication can be a very good topic for writing about development skills. In this article, I will first implement phone number authentication in the usual way. Then I will introduce Reactive Programming.

UI flow of Phone Number Authentication

During the authentication process, you must change the user interface for each step. For example, the related Button should be activated depending on the presence of the input value. And the UI component should be displayed or hidden according to the authentication step. Also, the Tip should be displayed to suit the situation. This article focuses on the following three cases.

• Activate [Request verification code] Button when entering a phone number (Step 1)
• Hide [Verification code] TextField and [Authenticate] Button when authentication is successful (Step 4)
• Display related message (tip) when authentication is completed or failed (step 5)

Basic structure

First, we’ll define an Enum with five states for each authentication step as follows. We declare it as a property of the Swift class and it has a didSet observer. We’ll add the code that changes the UI according to the authentication step here.

enum PhoneNumberVerifyStep {    case inputPhoneNumber, inputVerifyNumber, verifying, succeed, failed}

UI components consist of two TextFields, two Buttons, and one Label as follows. All are created through InterfaceBuilder and connected to IBOutlet. As mentioned earlier, we’ve declare a class property for storing the authentication step named verifyStep, and we’ve added a didSet observer to handle UI changes.

Change UI based on authentication step

Here is the part that actually changes the UI. Set the isHidden property of the [Verification code] TextField and the [Authentication] Button according to the changed value of verifyStep, and change the text of the [Tip] Label.

After calling the Restful API from the [Authentication] Button’s action method, set the appropriate value for verifyStep according to the response. Since we used the didSet observer for changing the UI, there is an advantage to separating the UI code and data processing code.

Whether the [Request verification code] Button is active depends on the real-time input value of the [Phone number] TextField, not the authentication step. Therefore, we add an action handler to phoneNumberTextField that sets the isEnabled of requestVerifyNumberButton according to the input value.

In this way, we’ve implemented the UI changes according to the phone number authentication step in the usual way. Now, after looking at some of the disadvantages of the old method, I will modify the example and do it in the Reactive way, which is the subject of this article.

First, the internal implementation of the didSet observer in verifyStep may be too large. And the code that sets up one View can exist across multiple cases in the Switch statement. Many parts need to be modified to remove a specific View or add a new View. Above all, it is hard to read if the code gets longer.

Changing the enable property of the Button according to the input value of TextField can be inconvenient: the text input event handler should be added continuously if the number of the TextField and Button that need similar processing is increased. If you need to add real-time validation logic to the input value in the TextField, the inside of the event handler can be complicated.

Now, let’s improve these shortcomings by applying Reactive Programming. Here we use the open source library ReactiveCocoa.

Reactive Programming

Reactive Programming is the process of constructing a program using a function that responds to the stream of data in a time-sequential manner. The basic concept is not new — consider the following use cases. For example, the Button’s click event is basically observing asynchronous events and subscribing through callbacks. In addition, Cocoa has already provided a number of tools to implement Observer Patterns for data as well as UI Events.

Reactive programming is programming with asynchronous data streams.

In a way, this isn’t anything new. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. Reactive is that idea on steroids. You are able to create data streams of anything, not just from click and hover events

However, Reactive Programming goes beyond just using the tools mentioned above, to the use of Observer Pattern as the core of programming.

It abstracts the flow of all types of primitive data handled by the UI — Control Action, Notification, Delegate, and KVO, which are basic tools provided by Cocoa, as a stream. It also provides functions to process and filter the data flowing through it, which can be easily used in various areas.

In other words, reactive programming is a more integrated and easier way to handle chain reaction processing (and programming based on it) due to state changes than traditional methods.

Basically, its function-oriented coding aims to perform a single role in a function connected to a stream. This avoids complicated stateful programs such as the verifyStep didSet observer of the previous example, and makes it easy to handle error handling and concurrency control of asynchronous processing. See ReactiveX.io for more information.

Implement Reactive Programming

Ok, it’s time to stop explaining long, boring theories. From now on, let’s improve the phone number authentication example using the open source library ReactiveCocoa.

First of all, we remove the code that changes the UI according to the authentication step of the previous example, and only the basic skeleton of ViewController is left. We also remove the didSet observer for verifyStep, the editing action handler for the TextField, and the action method for the [Authenticate] Button.

Implement the following code using ReactiveCocoa based on the skeleton. The entire code was attached because it was not long. Let’s first look at Property of ReactiveSwift, and let’s look at the implementation by dividing the authentication step process into three types as shown in the previous example.

(Mutable) Property of ReactiveSwift

Property is a class provided by ReactiveSwift, which is the base of ReactiveCocoa. It provides the ability to handle data as a stream. For example, in the example code, verifyStep is a Holder for PhoneNumberVerifyStep type data. It can generate a signal when changing the value, or change the value in response to other data changes.

var verifyStep = MutableProperty<PhoneNumberVerifyStep(...)

That is, when the value of Property (verifyStep) changes, the UI can be changed. Or when the input value of TextField is changed, the value of variable (verifyStep) can be changed with it. The didSet observer of the Swift class property provides similar functionality. However, MutableProperty has the advantage of being able to change or filter the values ​​passed through the stream as described above, and to connect with the UI change code much more concisely.

UI Binding and <~ operator of ReactiveCocoa

ReactiveCocoa provides Binding to easily handle UI changes due to Property changes. The UI component can create a BindingTarget for each of its configurable attributes. And this has a form of Command Pattern.

For example, ReactiveCocoa provides BindingTarget, which is the command that changes UILabel’s text. The BindingTarget is executed when a Signal is generated from the stream and sets the received value to the text of the UILabel.

The <~ operator is provided to make it easier to connect the Signal to the BindingTarget. For example, the code below sets the value (input value) passed from the Signal (that is generated when the value of textField changes) to the text of the label.

label.reactive.text <~ textField.reactive.continuousTextValues

label.reactive.text returns a BindingTarget instance that changes the text, and textField.reactive.continuousTextValues ​​returns a Signal instance that raises an event when the input value changes. The BindingTarget instance and the Signal instance are bound through &lt;~, so when the input value of the textField changes, the text of the label changes with it.

ReactiveCocoa’s UI Binding is also an important concept playing a key role in implementing the MVVM design. This is because it is possible to separate the data processing code from the UI processing code by binding the properties of the ViewModel with the UI components in the View.

Reactive Chain Reaction

Now go back to the example code and see how the Property and UI Binding are being used. Let’s start with the process of activating the [Request verification code] Button when a phone number is entered. The Button’s BindingTarget subscribes to the input value change Signal generated by the continuousTextValues ​​of the TextField described above.

requestVerifyNumberButton.reactive.isEnabled <~     phoneNumberTextField.reactive.continuousTextValues    .map { !($0?.isEmpty ?? true) }

The isEnabled BindingTarget of requestVerifyNumberButton was bound to the input value change Signal of phoneNumberTextField and the <~ operator was used in the process.

The isEnabled property of the Button is a Bool type property. The input value of TextField is a string type, so the value can not be directly assigned.

Therefore, when the string value is passed, it is changed to a Bool type through Signal’s map method. It is clear that stream data, which is a key advantage of Reactive Programming, is easy to process and can be expressed in a short and concise manner.

Let’s take a look at the state change of Button, TextField, and Label depending on the value of verifyStep which occupies the greater part of the example.

var verifyStep = MutableProperty<PhoneNumberVerifyStep>(...)

First, verifyStep is declared as a MutableProperty. verifyStep can now serve as a data stream, and UI Components can subscribe to a value change Signal from it. The value property returns the primitive value of verifyStep.

The following is UI Component Bindings to the Signal of verifyStep. Similarly, the <~ operator connects the BindingTarget that changes the isHidden and text properties of the UI Components with the Signal from verifyStep. That is, if the value of verifyStep is changed, the UI attributes such as isHidden and text are changed accordingly.

verifyNumberTextField.reactive.isHidden <~ verifyStep    .map { $0 == .succeed }

verifyButton.reactive.isHidden <~ verifyStep.map { $0 == .succeed }

statusLabel.reactive.isHidden <~ verifyStep.map { !$0.isVerifiedStep }

statusLabel.reactive.text <~ verifyStep.signal    .filter { $0.isVerifiedStep }.map { $0 == .succeed ? ... }

Use the map method to bind the Enum type value called PhoneNumberVerifyStep to the Bool type property. Use the filter method to ensure that the text in the statusLabel changes only when verifyStep is .succeed or .failed.

Up to this point, the chain reaction between data and UI has been improved in a reactive way during the implementation of Phone Number Authentication. No more didSet observers are needed. Complex UI change methods have also disappeared.

The Reactive approach allows us to define how a single UI component will change in the future with a concise representation. It also improves the readability of the code. Also, there are fewer things to change when adding or removing UI components.

Finally, let’s look at how to handle the UI Control Event through ReactiveCocoa.

Handling UI Control Events with ReactiveCocoa

ReactiveCocoa also provides a way to handle UI control events as streams. Like the continuousTextValues ​​of the TextField we saw earlier, ReactiveCocoa has added a property that returns a Signal instance for the control event of the UI component. The Signal for the UI Event can be bound to the BindingTarget, or it can have an observer directly.

verifyButton.reactive.controlEvents(.touchUpInside).observeValues {     self.api.getUsersVerify(...)        .on(value: { _ in            self.verifyStep.value = .succeed        })        .on(failed: { error in            self.verifyStep.value = .failed        })}

In the example, we added the Observer directly to the UI Event Signal. The controlEvents method returned a Signal for the touchUpInside event, and the observer handler was added via the observeValues ​​method.

The simple process of changing the Label’s text when the Button is touched is possible by binding through the <~ operator.

label.reactive.text <~ button.reactive.controlEvents(.touchUpInside)    .map { _ in "hello" }

Let’s recap the process so far. If a signal occurs while subscribing to a stream of the UI Event, it calls the Remote API. Change the value of MutableProperty according to the value passed to the response handler of the asynchronous call. At the same time, a value change signal is generated from the stream of MutableProperty, and the UI that is bound to the change signal is changed.

Now we’ve changed the Phone Number Authentication example to conform to the definition of Reactive Programming. Most of the processing is done with stream subscription and UI binding.

Conclusion

We have changed the traditional Phone Number Authentication to use Reactive programming. It’s not a new concept — Swift and Cocoa already provide many tools for asynchronous processing, UI event handling, and observer pattern implementation. However, using the Reactive way is more elegant and concise than the classic way. Also, there is an advantage that it can be used to design program structure like MVVM.

Everything in the programming world is related to how well we understand the code. It is important that it is easy it is to maintain. In this respect, adopting the reactive approach is a very smart decision. It is true that it is rather difficult to use for the first time. However, I am convinced that if you get used to it, you can code much more succinctly than before, and easily implement UI and user logic.

Let’s look again at the advantages of Reactive programming:

• The code that responds to changes in specific data or UI components is simplified.
• Because you do not have to create a huge method of focused code that changes the UI, it becomes easier to deal with new states or add or remove UI components.
• Functional coding allows you to write code that can focus on situations and roles.
• With Observing and Binding, you can separate ViewController into ViewModel and View, which is a key factor in applying MVVM design.

I hope that many developers will be able to code more happily through Reactive Programming. Thank you for reading this story.

I am writing about developing iOS applications using Swift. I would also appreciate your interest in the following articles.

Promise Syntax with ReactiveSwift
_Use ReactiveSwift to write code similar to Promise in JavaScript._medium.comUsing Enums in Swift
_How to handle the constants, raw values, and expressions of an Enum type through Swift._medium.comPassing parameters to Restful API with Swift Codable
_How not only the data received from the Restful API, but also the data to be transmitted, can be handled easily through…_medium.com

FRP represents an intersection of two programming paradigms. But, before we dig deeper into the concepts, we need to know a bit more about some basic terms.

FRP: reacting to events

Imperative programming

Traditionally, we write code that describes how it should solve a problem. Each line of code is sequentially executed to produce a desired outcome, which is known as imperative programming. The imperative paradigm forces programmers to write “how” a program will solve a certain task. Note that in the previous statement, the keyword is “how.”

Here’s an example:

let numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9]var numbersLessThanFive = [Int]()for index in 0..<numbers.count     {    if numbers[index] < 5         {        numbersLessThanFive.append(numbers[index])        }    }

As you can see, we sequentially execute a series of instructions to produce a desired output.

Functional programming

Functional programming is a programming paradigm where you model everything as a result of a function that avoids changing state and mutating data. We will discuss concepts such as state and data mutability and their importance in subsequent sections, but for reference:

• consider state as one of the different permutations and combinations that your program can have at any given time during its execution
• data mutability is the concept where a given dataset might change over a given course of time during program execution.

The same example that was given using imperative programming can be used in the following way using the functional approach:

let numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9]let numbersLessThanFive = numbers.filter { $0 < 5 }

We feed the filter function with a closure containing a certain criterion. That criterion is then applied to each element in the numbers array, and the resulting array contains elements that satisfy our criteria.

Notice the declaration of the two arrays in both the examples.

In the first example, the numbersLessThanFive array was declared as a var, whereas in the second example, the same array was declared as a let.

Does it ring some bells?

Which approach is better, which array is safer to work with?

What if more than one thread is trying to work with the same array and its elements?

Isn’t a constant array more reliable?

Reactive programming

Reactive programming is the practice of programming with asynchronous data streams or event streams. An event stream can be anything like keyboard inputs, button taps, gestures, GPS location updates, accelerometer, and iBeacon. You can listen to a stream and react to it accordingly.

You might have heard about reactive programming, but it might have sounded too intimidating, scary, or cryptic to even try out. You might have seen something like this:

var twoDimensionalArray = [ [1, 2], [3, 4], [5, 6] ]let flatArray = twoDimensionalArray.flatMap { array in    return array.map { integer in        return integer * 2    }}print(flatArray)Output : [2, 4, 6, 8, 10, 12]

At first glance, the preceding code might feel a bit obscure, and this might be the reason you turned your back on this style of programming. Reactive programming, as we mentioned earlier, is programming with event streams.

However, the bigger question still remains unanswered. What is functional reactive programming (FRP)?

FRP is the combination of functional and reactive paradigms. In other words, it is reacting to data streams using the functional paradigm. FRP is not a utility or a library — it changes the way you architect your applications and the way you think about your applications.

In the next blog I will talk about basic building blocks of reactive programming — till then stay tuned and enjoy reading:)

To have a solid grasp over reactive concepts and write iOS applications in RxSwift you can read my book: Reactive programming in Swift 4.

More of my projects and downloadable code are in my public github repos

You can read more about the topic here

Thanks for reading, please share it if you found it useful :)

Dealing with asynchronous non-blocking processing has always been the norm in the JavaScript world, and now is becoming very popular in many other contexts. The benefits are clear: an efficient use of resources. But the benefits come at a cost: a non-trivial increase in complexity.

Over time, vendors and the open source community have tried to find ways to reduce such complexity without compromising the benefits.

Asynchronous processing started with ‘callbacks’, then came Promise and Future, async and await. Recently another kid has come to town — ReactiveX with its various language implementations — bringing the developers a new powerful tool, the Observable.

In this article, we want to show how Observables implemented by RxJs (the JavaScript embodiment of ReactiveX) can simplify code to be executed with Node.js, the popular server-side JavaScript non-blocking environment.

A simple use case — Read, Transform, Write, and Log

To make our reasoning concrete, let’s start from a simple use case. Let’s assume we need to read the files contained in **Source Dir**, transform their content and write the new transformed files in a **Target Dir**, while keeping a log of the files we have created.

Read — Transform — Write — Log

Synchronous implementation

The synchronous implementation of this use case is pretty straightforward. In a sort of pseudo code representation, we could think of something like:

read the names of the files of Source Dir
   for each file name
      read the file
      transform the content
      write the new file in Target Dir
      log the name of the new file
   end for
console.log('I am done')

There is nothing special to comment here. We can just say that we are sure of the sequence of execution of each line and that we are sure that things will happen as described by the following flow of events. Each circle corresponds to the completion of an I/O operation.

The sequence of events in a synchronous world

What happens in an asynchronous non-blocking environment like Node.js

Node.js is an asynchronous non-blocking execution environment for JavaScript. Non-blocking means that Node.js does not wait for I/O or Network operations to complete before moving to the execution of the next line of code.

Processing one file

Reading and writing files are I/O operations where Node.js shows its non-blocking nature. If a Node.js program asks for a file to read, it has to provide a function to be executed when the file content is available (the so called callback) and then immediately move on to the next operation to execute.

Let’s consider the case of just one file. Reading, transforming, writing one file and updating the log in Node.js looks something like this:

import * as fs from 'fs'; // Node module to access file system
const fileName = 'one-file.txt';
fs.readFile(fileName, callback(err, data) => {
   const newContent = transform(data);
   const newFileName = newFileName(fileName); // calculate new name
   fs.writeFile(newFileName, newContent, err => {
      if(err) {// handle error};
      fs.appendFile('log.txt', newFileName  + ' written', err = {
         if (err) {// handle error}
      });
   });
})

The syntax may look a bit convoluted with 2 levels of indentation, but if we think of what happens in terms of events we can still precisely foresee the sequence:

Sequence of events in Node while transforming 1 file

The paradise of Promise

This is the use case where JavaScript Promise shines. Using Promise we can make the code look again sequential, without interfering with the asynchronous nature of Node.js.

Assuming we can access functions that perform read and write operations on file and return a Promise, then our code would look like:

const fileName = 'my-file.txt';
readFilePromise(fileName)
.then(data => {
   const newContent = transform(data);
   const newFileName = newFileName(fileName); // build the new name
   return writeFilePromise(newFileName, newContent)
})
.then(newFileName => appendFile('log.txt', newFileName))
.then(newFileName => console.log(newFileName + ' written'))
.catch(err => // handle error)

There are several ways to transform Node.js functions in Promise based functions. This is one example:

function readFilePromise(fileName: string): Promise<Buffer>{
   return new Promise(function(resolve, reject) {
      fs.readFile(fileName, function(err, data: Buffer) {
         if(err !== null) return reject(err);
         resolve(data);
      });
   });
}

Processing many files

If we return to the original use case, where we have to transform all the files contained in a Directory, the complexity increases and Promises start showing some limits.

Let’s look at the events the Node.js implementation needs to manage:

Sequence of events when transforming many files in parallel

Each circle represents the completion of one I/O operation, either read or write. Every line represents the processing of one specific file, or a chain of Promises.

Given the non-blocking nature of Node.js, there is no certainty on the sequence in time of such events. It is possible that we will finish writing **File2** before we finish reading **File3**.

The parallel processing of each file makes the use of Promises more complex (at the end of this article, a Promise based implementation is provided). This is the scenario where ReactiveX — RxJs in particular — and Observable shine and allow you to build elegant solutions.

What are Observables and what can you do with them?

There are many places where formal definitions of Observables are detailed, starting from the official site of ReactiveX.

Here I just want to remind you of a couple of properties that have always gotten my attention:

• Observable models a stream of events
• Observable is the “push” brother of Iterable, which is “pull”

As the “push” brother of Iterable, Observable offers developers many of the cool features provided by Iterables such as:

• Transform “streams of events” or Observables, via operators such as map, filterand skip
• Apply functional programming style

One additional very important thing that Observable offers is subscription. Via subscription, the code can apply “side effects” to events and perform specific actions when specific events happen, such as when errors occur or the stream of events completes.

The subscribe interface of Observable

As you can see, the Observable interface gives developers the possibility to provide three different functions which define what to do respectively when: an event is emitted with its data, an error occurs, or the stream of events completes.

I guess all of the above may sound very theoretical to those who have not yet played with Observable, but hopefully the next part of the discussion, which is focused on our use case, will make these concepts more concrete.

Implementation of the Read, Transform, Write, and Log use case via Observable

Our use case starts with reading the list of files contained in **Source Dir**. So, let’s start from there.

Read all the file names contained in a Directory

Let’s assume we have access to a function which receives as input the name of a directory and returns an Observable which emits the list of file names of the directory once the directory tree structure has been read.

readDirObservable(dirName: string) : Observable<Array<string>>

We can subscribe to this Observable and when all file names have been read, start doing something with them:

Subscription to an Observable which emits when the directory has been read

Read a list of files

Let’s assume now that we can access a function which receives as input a list of file names and emits each time a file has been read (it emits the content of the file Buffer, and its name string).

readFilesObservable(fileList: Array<string>) 
   : Observable<{content: Buffer, fileName: string}>

We can subscribe to such Observable and start doing something with the content of the files.

Combining Observables — switchMap operator

We have now two Observables, one that emits a list of file names when the directory has been read and one that emits every time a file is read.

We need to combine them to implement the first step of our use case, which is: when readDirObservable emits, we need to switch to readFilesObservable .

switchMap operator

The trick here is performed by the switchMap operator. The code looks like:

readDirObservable(dirName)
.switchMap(fileList => readFilesObservable(fileList))
.subscribe(
      data => console.log(data.fileName + ‘ read’), // do stuff with the data received
      err => { // manage error },
      () => console.log(‘All files read’)
)

We must mention that the switchMap operator is more powerful than this. Its full power though can not be appreciated in this simple use case, and its full description is outside the scope of this post. If you are interested, this is an excellent article that describes in detail switchMap.

Observable generating a stream of Observables

We have now a stream of events representing the completion of a read operation. After the read we need to do a transformation of the content that, for sake of simplicity, we assume to be synchronous, and then we need to save the transformed content in a new file.

But writing a new file is again an I/O operation, or a non-blocking operation. So every ‘file-read-completion’ event starts a new path of elaboration that receives as input the content and the name of the source file, and emits when the new file is written in the Target Dir (the event emitted carries the name of the file written).

Again, we assume that we’re able to access a function that emits as soon as the write operation is completed, and the data emitted is the name of the file written.

writeFileObservable(fileName: string, content: Buffer) :            Observable<string>

In this case, we have different “write-file” Observables, returned by the writeFileObservable function, which emits independently. It would be nice to merge them into a new Observable which emits any time each of these “write-file” Observables emit.

A stream of Observables we would like to merge

With ReactiveX (or RxJs in JavaScript) we can reach this result using the mergeMap operator (also known as a flatMap). This is what the code looks like:

readDirObservable(dir)
.switchMap(fileList => readFilesObservable(fileList))
.map(data => transform(data.fileName, data.content))
.mergeMap(data => writeFileObservable(data.fileName, data.content))
.subscribe(
      file => console.log(data.fileName + ‘ written’),
      err => { // manage error },
      () => console.log(‘All files written’)
)

The mergeMap operator has created a new Observable, the writeFileObservable as illustrated in the following diagram:

Observable returned by mergeMap operator

So what?

Applying the same approach, if we just imagine that we have a new function of writeLogObservable, that writes a line on the log as soon as the file is written and emits the file name as soon as the log is updated, the final code for our use case would look like:

readDirObservable(dir)
.switchMap(fileList => readFilesObservable(fileList))
.map(data => transform(data.fileName, data.content))
.mergeMap(data => writeFileObservable(data.fileName, data.content))
.mergeMap(fileName => writeLogObservable(fileName))
.subscribe(
      file => console.log(fileName + ‘ logged’),
      err => { // manage error },
      () => console.log(‘All files have been transformed’)
)

We do not have indentations introduced by the callbacks.

Time flows along the vertical axis only, so we can read the code line by line and reason about what is happening line after line.

We have adopted a functional style.

In other words, we have seen the benefits of Observable in action.

Create Observable from functions with callbacks

I hope you now think that this looks pretty cool. But even in this case you may have one question. All the functions that make this code cool just do not exist. There is no readFilesObservable or writeFileObservable in standard Node.js libraries. How can we create them?

bindCallback and bindNodeCallback

A couple of functions provided by Observable, namely bindCallback(and bindNodeCallback) come to our rescue.

The core idea behind them is to provide a mechanism to transform a function f which accepts a callback cB(cBInput) as input parameter into a function which returns an Observable obsBound which emits cBInput. In other words, it transforms the invocation of the cB in the emission of cBInput.

The subscriber of obsBound can define the function which will process cBInput (which plays the same role as cB(cBInput)). The convention applied is that the callback function cB(cBInput) must be the last argument off.

It is probably easier to understand the mechanism looking at the following diagram:

From a function to an Observable

The starting point, the function f(x, cb) is the same in the two cases. The result (what is printed on the console) is the same in the two cases.

What is different is how the result is obtained. In the first case the result is determined by the callback function passed as input. In the second case it is determined by the function defined by the subscriber.

Another way of considering how bindCallback works is to look at the transformation it performs, as illustrated in the diagram below.

Transformation performed by bindCallback

The first argument of f becomes the value passed to the new function fBound. The arguments used as parameters of the callback cb become the values emitted by the new Observable returned by fBound.

bindNodeCallback is a variation of bindCallback based on the convention that the callback function has an error parameter as the first parameter, along with the Node.js convention fs.readFile(err, cb).

Create Observables from non-callback functions

bindNodeCallback has been designed to work with functions which expect a callback as the last argument of their input, but we can make it work also with other functions.

Let’s consider the standard Node.js function readLine. This is a function used to read files line by line. The following example shows as it works:

readLine function

Each line read is pushed into the lines array. When the file is completely read, the function processLinesCb is called.

Imagine now that we define a new function,_readLines, which wraps the logic defined above as shown by the following snippet:

readLine function wrapped by a callback function

Once all lines are read, they are processed by the function processLinesCb, which is the last input parameter of _readLines. _readLines is therefore a function that can be treated by bindCallback. Through this trick we can transform the Node.js function fs.readLine into an Observable using the usual bindCallback function as follows:

readLine as Observable

Conclusion

Asynchronous non-blocking processing is complex by nature. Our minds are used to think sequentially — this is true at least for those of us who started coding few years ago. We often find it challenging to reason about what is really happening in these environments. The callback-hell is just around the corner.

Promises and Futures have simplified some of the most frequent cases such as ‘one time’ asynchronous events, the ‘request now — respond later’ scenario typical of HTTP requests.

If we move from ‘one time’ events to ‘event streams’ Promises start showing some limitations. In such cases we may find ReactiveX and Observables a very powerful tool.

As promised: the Promise-based implementation of our use case

This is an implementation of the same use case based on Promises:

const promises = new Array<Promise>();
readDirPromise(dir)
.then(fileList => {
   for (const file of fileList) {promises.push(
         readFilePromise(file)
         .then(file_content => transform(file_content))
         .then(file => writeLogPromise(file))
      );
   }
   return promises;
}
.then(promises => Promise.all(promises))
.then(() => console.log(‘I am done’))
.catch(err => { // manage error })

If the operators could talk, how exactly would they tell us what they do?

In order to take full advantage of Rx, you need a clear understanding of what Rx Operators are and what they do.

This is what the Operators would be telling the observables if they could talk when we use them.

For this article, I’ll assume that you already know what Rx is. If not, go read this. Or just simply google Rx and you’ll find a ton of helpful articles, tutorials, and videos.

Creational Operators

Create

I tell you what to emit, when to terminate, and what error to throw. ‘Cause I’m the boss.

Defer

You only get to “create” yourself once someone subscribes to you. And it’ll be a brand new version of yourself every single time.

Empty

Hm. Emit nothing. And then die, please.

Never

Emit nothing. And don’t… ever… terminate.

Throw

Emit nothing, and then throw an error, OK?

From

I’ll give you some objects, then you emit them right back at me.

Interval

How about this: you emit items. But not immediately. Send them back, one by one, after certain “intervals.”

Just

I need just one thing back from you. Just one.

Range

I give you a range of integers, then you emit back all the values in that range.

Repeat

How about you emit that same object repeatedly.

Start

Ok. I have a function. When it returns, you start emitting. But only when it returns. Got it?

Timer

So you got an item. Don’t emit it just yet. I’ll tell you the exact time when you should emit it. Don’t jump the gun.

Transformational Operators

Buffer

Ok, so here’s the deal. Whatever it is you normally emit, well don’t emit that. Instead ,collect the items into bundles over time. And send bundles instead. ‘Cause I want bundles!

FlatMap

So, like, if you have lists of items and there’s another observable that’s full of items, can you please “flatten” yourself and that observable so you can just send items?

Map

Transform each item into another item.

Scan

Transform each item into another item, like you did with map. But also include the “previous” item when you get around to doing a transform.

Filtering Operators

Debounce

Only emit if a certain amount of time is passed.

Distinct

Emit only distinct items. All right?

ElementAt

I tell you the index. You emit the item at that index.

Filter

I give you a criteria. You give me items that pass the criteria.

First

Just give me back the first item.

IgnoreElements

Do not, I repeat, do not emit a single item. And then die.

Last

Just give me back the last item.

Sample

I give you an interval. You give me only the most recent items from that that interval.

Skip

OK, skip the first n items, would you?

SkipLast

Skip the last n item s. Yeah, those ones.

Take

Emit only the first n items.

TakeLast

Emit only the last n items.

Combining Operators

Merge

Here are two observables. Let’s pretend they’re only one observable.

StartWith

Here are two observables. But I get to tell you which one to start with.

CombineLatest

Here are two observables. Between the two, make pairs of the latest items.

Zip

Here are two observables. But I tell you how to combine their items (through a function, of course).

Handling Errors

Catch

After an error is thrown, continue on with the emits.

Retry

After an error is thrown, restart from the very beginning.

Utility

Delay

Just add a delay before you start emitting, OK?

ObserveOn

“Observational” code should run on this particular thread.

SubscribeOn

“Subscription” code should run on this particular thread.

Subscribe

You can start emitting now. music intensifies

TimeInterval

OK, so observables send back items, right? Instead, I want you to send the time intervals back. Like the time differences between each emission.

TimeOut

Set a TimeOut on each emission. And if an item doesn’t get emitted within that time, just throw an error ?

Conditional and Boolean

All

If all items fulfill a certain criteria, return true.

Amb

Here are at least two observables. Give me the one that starts emitting first.

Contains

If I ask for an item, can you tell me whether you already have it?

DefaultIfEmpty

When you have nothing to emit, here’s a default value that you can send back.

SequenceEqual

Here are two observables. Return true if their items (and their sequence) are the same.

SkipUntil

Here are two observables. Skip the items of the first one until the second one starts emitting.

SkipWhile

I give you a condition. You emit items until that condition becomes false.

TakeUntil

Here are two observables. Only give me the items of the first one until the second one starts emitting.

Mathematical Operators

Average

Give me an average of your Integer items.

Count

Give me a count of your items.

Max

Emit only the maximum-valued item.

Min

Emit only the minimum-valued item.

Reduce

Do a scan, but only emit the final value.

Sum

Return the sum of all your items.

Conversion Operators

To

Convert an observable into a List, Map or Array, or whatever I tell you to.

That’s it for now. There are other operators as well, which you can find here. You can also check out RxMarbles, which has cool diagrams for demonstrating each operator.

Anyway, thank you for reading. I hope the article helped you better understand what each of these commands does in a fun way.

Happy coding!

Functional reactive programming is laden with unfamiliar terminology to the newcomer: pure functions, immutability, monads, etc. But beneath these concepts is a deeper principle — one debated long before Charles Babbage and the first computers. I argue the difference between object-oriented programming (OOP) and functional reactive programming (FRP) is as much about interpretations of reality as it is about structures of programs.

Here’s a thought experiment we’ve all likely heard:

If a tree falls in the middle of a forest, and no one is there to hear it, does it make a sound?

There are many of ways to attack this question as ill-posed. Ignoring them for the moment, this question is poking at a fundamental aspect of reality: causality. Is existence dependent on, or independent of, observation? Let’s translate this thought experiment into code. Here’s a tree:

class Tree {     constructor(){         this._fell = false;     }     set fell(state){         this._fell = state;     }     get fell(){         return this._fell;     }}

var tree = new Tree();tree.fell = true;

To make the tree fall we set its fallen state to true. This is textbook object-oriented programming. Its patterns are getters, setters, and state. Simple enough, but in the context of our thought experiment there is a lurking interpretation: if one questions whether the tree fell, even if they didn’t observe it, the answer is a resounding “Yes!” One only needs to check that tree.fell is true. Those that answer yes to our philosophical question do so because they can return to the forest, see the fallen tree, and deduce it fell in the past. Here is the codified equivalent. Looks like we’ve solved that centuries-old riddle.

Not so fast! Let’s look at a different approach. Here’s another tree:

class Tree extends EventEmitter {}var tree = new Tree();tree.emit('fall');

This is the “reactive” tree. Its patterns are events and transforms. In its purest form our tree maintains no state. We make it fall by broadcasting a fall event. Alas, the message falls on deaf ears! No state has changed, no evidence is left. There is no way to deduce the past by querying reality. Did the tree fall? shrug

Descartes and Berkeley

The object-oriented and reactive approaches give two different answers to our thought experiment because they embody two contradictory philosophies of epistemology: Rationalism, popularized by Descartes in the late 1600s, and Empiricism popularized by Berkeley in the early 1700s.

Descartes takes as a short break from writing a Java interface

Descartes, in a streak of fanatical skepticism, found he could only be sure of one thing: his own existence. He came to this conclusion because he couldn’t doubt the existence of his thoughts and concluded there must be some entity doing the thinking, thus coining the phrase, cogito ergo sum: I think therefore I am. In other words: by acknowledging that there is some internal state that is changing, there must be some agent for whom the state belongs. To Descartes, changes of state is proof of existence — just like our first tree.

Berkeley seen pondering Haskell type definitions

Soon after Descartes comes George Berkeley. Berkeley denounced the realist’s view. To Berkeley, it made no sense for material objects, like trees, to have existence. Existence only comes to us through thoughts (mental as opposed to physical experience), and thoughts must assimilate in the mind to exist. Material objects are deceptions; their essence is not their physicality but their ability to transform the immaterial. If a thought is not assimilated in the mind, it has no existence. Thus he popularized the Latin phrase esse percepi: to be is to be perceived.

Let’s translate Berkeley’s reality into code. For our second tree to make a sound a mind must interpret it. We will create a chain of causality, starting from the tree falling, to the air vibrating, to the ear creating an electrical stimulus, to the brain interpreting it as sound.

When the tree falls, the air vibrates.

class Air extends EventEmitter {    constructor (){        super();                function mapFall (fall){...}        this.on('fall', (fall) => {            var vibration = mapFall(fall);            this.emit('vibrate', vibration);        };    }}

When the air vibrates, the ear converts it to an electrical stimulus.

class Ear extends EventEmitter {    constructor (){         super();                function mapFrequency (frequency){...}        this.on('vibrate', (frequency) => {            var stimulus = mapFrequency(frequency);            this.emit('stimulus', stimulus);        };    }}

When ear creates a stimulus, the brain interprets it as sound.

class Brain extends EventEmitter {    constructor (){        super();        function mapStimulus (signal){...}        this.on('stimulus', (signal) => {            var sound = mapStimulus(signal);            this.emit('sound', sound);        };    }}

We have effectively set up a chain of causality, which we make explicit by building a pipeline:

tree.pipe(air).pipe(ear).pipe(brain);

Now, when the tree falls it makes an impression on a mind:

brain.on('sound', (sound) => {    // We exit the system. You have been heard!    console.log(sound); });

tree.emit('fall', fallData);

Berkeley called this concept Subjective Idealism. Idealism because it asserts only thoughts or ideas exist, and subjective because reality is dependent on the subjects that perceive it. In my opinion, Subjective Idealism is the philosophy underpinning reactive programming. Berkeley writes,

It is indeed an opinion strangely prevailing amongst men, that houses, mountains, rivers, and in a word all sensible objects have an existence natural or real, distinct from their being perceived by the understanding. …For what are the fore-mentioned objects but the things we perceive by sense…and is it not plainly repugnant that any one of these or any combination of them should exist unperceived?

I love this quote for its self-assured audacity. Berkeley is essentially calling us crazy for thinking that houses, mountains and rivers exist. In our example, trees, air, ears and brains are false idols; the only reality is mapFall, mapFrequency and mapStimulus. Reality is then never consumed, as it is with objects when they retain state. Reality is merely transformed.

Subjective Idealism in Practice

In OOP we create objects that encapsulate some kind of behavior. We then construct programs which are networked relationships of these objects. Our program is structurally a graph.

In FRP we create pipelines of functions that encapsulate causal relationships. Pipelines are then merged and branched to give the graph-like structure of an object-oriented program. However, there is an important limitation on the types of functions. Only pure functions are allowed. That is, functions that cannot effect anything outside themselves. In our example, the Ear object cannot change how the Air object vibrated. This constraint ensures that our pipelines have a well-defined direction from cause to effect. In terms of structure, this means our program is a directed acyclic graph (DAG).

To reason about software, we must think of it as a sequence of causal relationships. We must be able to order the program. Mathematically, a graph can be ordered if and only if it is a DAG. This is true no matter how you write your program. Whether you choose OOP, FRP or XYZ. What’s special about FRP, though, is that ordering is enforced by the pattern.

In OOP, ordering is left unspecified. Objects can call methods on other objects. Objects can change the state of other objects. Everything has read and write privileges by default. Specifying an order is done manually by the developer. It is up to them to relate the sequential ordering of lines in a program to an ordering of the objects’ causal relationships.

Unfortunately, this is all too easy to mess up. Notice that in OOP, when two objects write to the same shared state, you have a race condition. In FRP, when two functions try to affect one another you have an infinite loop. This is but one example of a theoretical pattern enforcing a practical result.

The bottom line is that it is not enough to encapsulate state. A well-written program will also encapsulate dependency.

Tradeoffs

“Programmers know the benefits of everything and the tradeoffs of nothing.”— Rich Hickey

You’d think after all this FRP praising and OOP bashing, I’d be firmly in the FRP camp. You’d be wrong! FRP is a programming pattern, and patterns serve to constrain solutions. If the ideal solution doesn’t satisfy the constraints, you’ll be wasting energy fighting against the pattern.

To be concrete, there are a few simple annoyances of FRP. Take immutability — you are always creating more memory. You can never, say, sort a list in place. You will always be creating a new list. In theory, immutability is a good pattern to observe. In practice, you may be memory constrained, and it may be a good idea to swim against the FRP current.

But this is not the glaring problem. The glaring problem is that FRP becomes an anti-pattern when you don’t know when two parts of a codebase will interact. Take, for example, a first person shooter game. Somewhere is a bullet object, and somewhere else is a player object. A bullet may hit a player, but it’s unclear when this will happen. These objects need to retain state (velocity of the bullet, health of the player, etc.) so it is available at the moment they interact. Perhaps in the abstract the entire game can be thought of as one causal pipeline, but that sounds more daunting to me than thinking in terms of decoupled objects and state.

To put on my philosophical hat once more, physics may decree that reality is one causal pipeline whose time evolution is governed by deterministic physical laws, and whose initial conditions (or probabilities) are provided by the big bang. But this is hardly how humans reason about cause and effect. We naturally slice up reality into higher-level objects and reason about their inter-relations. It can be simpler that way, even though it’s error prone!

I feel this is why FRP hasn’t been been wholly embraced by the programming community, even after seeing its many advantages. The best we should hope for when writing programs is to use FRP principles in places where its patterns fit the solution, and let them inspire OOP patterns where its patterns do not. To me this is a distinction between solutions that can be thought of as pipelines, and solutions that shouldn’t be.

Conclusion

In philosophy the objective is not to solve our deepest problems, but to have a shared language and historical precedent to debate them. So when a new problem emerges, we don’t have to start over. Similarly for programming patterns. They are not used to decide right and wrong, as if these concepts have universal appeal. They are used to classify problems and their approaches.

We should also look to other disciplines, much older than computer science, to see whether their shared language and historical precedent can inspire our own. Then we may see that the question, “did the tree fall?” is not answered with a yes or a no. That instead it questions a perspective. One that can frame our philosophy of epistemology or our architecture of programs. And one to which the answer lies between a state of mind, and a flow of thought!

Preview of Part II

There is still a nagging dilemma in our thought experiment. Even if there are no people to experience the sound, surely when the tree falls the air must vibrate! Right? In Part II we will go further down the rabbit hole to see that FRP can give a surprising interpretation here too. We’ll think of data flows in terms of push vs pull and see how this appears in concepts like lazy evaluation, algorithms like ray tracing, and applications like Excel.