This is the 29th day of my participation in the August More Text Challenge

In the previous article we covered some of the basic concepts, and in this article we continue to explore RxJS with a real case study.

What new problems do they bring up?

Reactive Extensions (Rx) is a great coding pattern to work with, but we need to look at it in a real business scenario.

  1. Do team members have a high level of abstract thinking, because it’s a functional, responsive programming paradigm, and can team members quickly learn to move into development?
  2. RxJS is best at handling asynchronous events, so is our business scenario really that complex?
  3. RxJS code is highly abstract, and it is understandable that abstract code is not as readable as imperative code, so how do we organize our business code?

Functional programming paradigm

By the way, the functional programming paradigm is a constrained programming paradigm:

  1. Declarative (Declarative)

Declarative, as opposed to imperative, we can see how the code is different:

const arr = [1.2.3.4.5]
/ / imperative
for (let i = 0; i < arr.length; i++) {
    console.log(arr[i])
}

/ / the declarative
arr.map((item) = > {
    console.log(item)
})
Copy the code

It’s not hard to see that with declarative, the code is much cleaner, there’s no for, there’s no extra variable declaration.

  1. Pure Function

Function calls have no additional side effects (IO operations, DOM operations, network requests, etc.), and each input has a uniquely validated output.

  1. Immutability of data

Do not change the source data, for example:

const arr = [1.2.3.4.5]
// Change the source data
arr.push(6)

// New elements are added, but the original data is not changed, in accordance with the principle of data immutability
function push2(source, item) {
    return [...source, item]
}
Copy the code

Based on actual business scenarios

This is an example THAT I did recently and I think it would be appropriate to combine RxJS with IM chat session pages.

Let’s start with the logic:

Events:

  1. Pull the historical session list through HTTP GET.
  2. Receive messages in real time through Websocket protocol;
  3. Input events;
  4. Send content events;
  5. Click content events (such as picture preview, video play, voice play, etc.);

In combination with UI interaction and logical layer organization, it is not difficult to find:

  1. For the [chat content display area], it is obviously the subscriber, what are the characteristics of the subscriber? As mentioned above, subscribers are only responsible for completing their own business logic after receiving the notification, not the source of the message.

  2. Who are the publishers?

    • Messages pushed via WebSocket (asynchronous events)
    • Messages pulled via HTTP GET (asynchronous events)
    • The user clicks on the sent message (synchronous event)

Does a subscriber support subscribing to multiple event streams? RxJS certainly supports that we can merge event flows, transform event flows, and so on to achieve our goals.

The code is not posted here, interested students can follow the above ideas to practice.

summary

There are many RxJS concepts that are not covered in this article, such as:

  • Hot Observable and Cold Observable are used to solve the problem that there are multiple subscribers and someone is late
  • The classic pinball notation allows us to clearly see the flow of events
  • Multicast, used to deal with the problem of having multiple subscribers to an event stream
  • Exception handling, how to deal with upstream data error
  • .

If you are interested in the point, also welcome to discuss.