您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關(guān)RxJS有什么用的內(nèi)容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
RxJS簡介
通常,對RxJS的解釋會是這么一些東西,我們來分別看看它們的含義是什么。
Reactive
Lodash for events
Observable
Stream-based
什么是Reactive呢,一個比較直觀的對比是這樣的:
比如說,abc三個變量之間存在加法關(guān)系:
a = b + c
在傳統(tǒng)方式下,這是一種一次性的賦值過程,調(diào)用一次就結(jié)束了,后面b和c再改變,a也不會變了。
而在Reactive的理念中,我們定義的不是一次性賦值過程,而是可重復的賦值過程,或者說是變量之間的關(guān)系:
a: = b + c
定義出這種關(guān)系之后,每次b或者c產(chǎn)生改變,這個表達式都會被重新計算。不同的庫或者語言的實現(xiàn)機制可能不同,寫法也不完全一樣,但理念是相通的,都是描述出數(shù)據(jù)之間的聯(lián)動關(guān)系。
在前端,我們通常有這么一些方式來處理異步的東西:
回調(diào)
事件
Promise
Generator
其中,存在兩種處理問題的方式,因為需求也是兩種:
分發(fā)
流程
在處理分發(fā)的需求的時候,回調(diào)、事件或者類似訂閱發(fā)布這種模式是比較合適的;而在處理流程性質(zhì)的需求時,Promise和Generator比較合適。
在前端,尤其交互很復雜的系統(tǒng)中,RxJS其實是要比Generator有優(yōu)勢的,因為常見的每種客戶端開發(fā)都是基于事件編程的,對于事件的處理會非常多,而一旦系統(tǒng)中大量出現(xiàn)一個事件要修改視圖的多個部分(狀態(tài)樹的多個位置),分發(fā)關(guān)系就更多了。
RxJS的優(yōu)勢在于結(jié)合了兩種模式,它的每個Observable上都能夠訂閱,而Observable之間的關(guān)系,則能夠體現(xiàn)流程(注意,RxJS里面的流程的控制和處理,其直觀性略強于Promise,但弱于Generator)。
我們可以把一切輸入都當做數(shù)據(jù)流來處理,比如說:
用戶操作
網(wǎng)絡響應
定時器
Worker
RxJS提供了各種API來創(chuàng)建數(shù)據(jù)流:
單值:of, empty, never
多值:from
定時:interval, timer
從事件創(chuàng)建:fromEvent
從Promise創(chuàng)建:fromPromise
自定義創(chuàng)建:create
創(chuàng)建出來的數(shù)據(jù)流是一種可觀察的序列,可以被訂閱,也可以被用來做一些轉(zhuǎn)換操作,比如:
改變數(shù)據(jù)形態(tài):map, mapTo, pluck
過濾一些值:filter, skip, first, last, take
時間軸上的操作:delay, timeout, throttle, debounce, audit, bufferTime
累加:reduce, scan
異常處理:throw, catch, retry, finally
條件執(zhí)行:takeUntil, delayWhen, retryWhen, subscribeOn, ObserveOn
轉(zhuǎn)接:switch
也可以對若干個數(shù)據(jù)流進行組合:
concat,保持原來的序列順序連接兩個數(shù)據(jù)流
merge,合并序列
race,預設條件為其中一個數(shù)據(jù)流完成
forkJoin,預設條件為所有數(shù)據(jù)流都完成
zip,取各來源數(shù)據(jù)流最后一個值合并為對象
combineLatest,取各來源數(shù)據(jù)流最后一個值合并為數(shù)組
這時候回頭看,其實RxJS在事件處理的路上已經(jīng)走得太遠了,從事件到流,它被稱為lodash for events,倒不如說是lodash for stream更貼切,它提供的這些操作符也確實可以跟lodash媲美。
數(shù)據(jù)流這個詞,很多時候,是從data-flow翻譯過來的,但flow跟stream是不一樣的,我的理解是:flow只關(guān)注一個大致方向,而stream是受到更嚴格約束的,它更像是在無形的管道里面流動。
那么,數(shù)據(jù)的管道是什么形狀的?
在RxJS中,存在這么幾種東西:
Observable 可觀察序列,只出不進
Observer 觀察者,只進不出
Subject 可出可進的可觀察序列,可作為觀察者
ReplaySubject 帶回放
Subscription 訂閱關(guān)系
前三種東西,根據(jù)它們數(shù)據(jù)進出的可能性,可以通俗地理解他們的連接方式,這也就是所謂管道的“形狀”,一端密閉一端開頭,還是兩端開口,都可以用來輔助記憶。
上面提到的Subscription,則是訂閱之后形成的一個訂閱關(guān)系,可以用于取消訂閱。
下面,我們通過一些示例來大致了解一下RxJS所提供的能力,以及用它進行開發(fā)所需要的思路轉(zhuǎn)換。
示例一:簡單的訂閱
很多時候,我們會有一些顯示時間的場景,比如在頁面下添加評論,評論列表中顯示了它們分別是什么時間創(chuàng)建的,為了含義更清晰,可能我們會引入moment這樣的庫,把這個時間轉(zhuǎn)換為與當前時間的距離:
const diff = moment(createAt).fromNow()
這樣,顯示的時間就是:一分鐘內(nèi),昨天,上個月這樣的字樣。
但我們注意到,引入這個轉(zhuǎn)換是為了增強體驗,而如果某個用戶停留在當前視圖時間太長,它的這些信息會變得不準確,比如說,用戶停留了一個小時,而它看到的信息還顯示:5分鐘之前發(fā)表了評論,實際時間是一個小時零5分鐘以前的事了。
從這個角度看,我們做這個體驗增強的事情只做了一半,不準確的信息是不能算作增強體驗的。
在沒有RxJS的情況下,我們可能會通過一個定時器來做這件事,比如在組件內(nèi)部:
tick() { this.diff = moment(createAt).fromNow() setTimeout(tick.bind(this), 1000) }
但組件并不一定只有一份實例,這樣,整個界面上可能就有很多定時器在同時跑,這是一種浪費。如果要做優(yōu)化,可以把定時器做成一種服務,把業(yè)務上需要周期執(zhí)行的東西放進去,當作定時任務來跑。
如果使用RxJS,可以很容易做到這件事:
Observable.interval(1000).subscribe(() => { this.diff = moment(createAt).fromNow() })
示例二:對時間軸的操縱
RxJS一個很強大的特點是,它以流的方式來對待數(shù)據(jù),因此,可以用一些操作符對整個流上所有的數(shù)據(jù)進行延時、取樣、調(diào)整密集度等等。
const timeA$ = Observable.interval(1000) const timeB$ = timeA$.filter(num => { return (num % 2 != 0) && (num % 3 != 0) && (num % 5 != 0) && (num % 7 != 0) }) const timeC$ = timeB$.debounceTime(3000) const timeD$ = timeC$.delay(2000)
示例代碼中,我們創(chuàng)建了四個流:
A是由定時器產(chǎn)生的,每秒一個值
B從A里面過濾掉了一些
C在B的基礎上,對每兩個間距在3秒之內(nèi)的值進行了處理,只留下后一個值
D把C的結(jié)果整體向后平移了2秒
所以結(jié)果大致如下:
A: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
B: 1 11 13 17 19
C: 1 13 19
D: 1 13
示例三:我們來晚了
RxJS還提供了BehaviourSubject和ReplaySubject這樣的東西,用于記錄數(shù)據(jù)流上一些比較重要的信息,讓那些“我們來晚了”的訂閱者們回放之前錯過的一切。
ReplaySubject可以指定保留的值的個數(shù),超過的部分會被丟棄。
最近新版《射雕英雄傳》比較火,我們來用代碼描述其中一個場景。
郭靖和黃蓉一起背書,黃蓉記憶力很好,看了什么,就全部記得;而郭靖屬魚的,記憶只有七秒,始終只記得背誦的最后三個字,兩人一起背誦《九陰真經(jīng)》。
代碼實現(xiàn)如下:
const 九陰真經(jīng) = '天之道,損有余而補不足' const 黃蓉$ = new ReplaySubject(Number.MAX_VALUE) const 郭靖$ = new ReplaySubject(3) const 讀書$ = Observable.from(九陰真經(jīng).split('')) 讀書$.subscribe(黃蓉$) 讀書$.subscribe(郭靖$)
執(zhí)行之后,我們就可以看到,黃蓉背出了所有字,郭靖只記得“補不足”三個字。
示例四:自動更新的狀態(tài)樹
熟悉Redux的人應該會對這樣一套理念不陌生:
當前視圖狀態(tài) := 之前的狀態(tài) + 本次修改的部分
從一個應用啟動之后,整個全局狀態(tài)的變化,就等于初始的狀態(tài)疊加了之后所有action導致的狀態(tài)修改結(jié)果。
所以這就是一個典型的reduce操作。在RxJS里面,有一個scan操作符可以用來表達這個含義,比如說,我們可以表達這樣一個東西:
const action$ = new Subject() const reducer = (state, payload) => { // 把payload疊加到state上返回 } const state$ = action$.scan(reducer) .startWith({})
只需往這個action$里面推action,就能夠在state$上獲取出當前狀態(tài)。
在Redux里面,會有一個東西叫combineReducer,在state比較大的時候,用不同的reducer修改state的不同的分支,然后合并。如果使用RxJS,也可以很容易表達出來:
const meAction$ = new Subject() const meReducer = (state, payload) => {} const articleAction$ = new Subject() const articleReducer = (state, payload) => {} const me$ = meAction$.scan(meReducer).startWith({}) const article$ = articleAction$.scan(articleReducer).startWith({}) const state$ = Observable .zip( me$, article$, (me, article) => {me, article} )
借助這樣的機制,我們實現(xiàn)了Redux類似的功能,社區(qū)里面也有基于RxJS實現(xiàn)的Redux-Observable這樣的Redux中間件。
注意,我們這里的代碼中,并未使用dispatch action這樣的方式去嚴格模擬Redux。
再深入考慮,在比較復雜的場景下,reducer其實很復雜。比如說,視圖上發(fā)起一個操作,會需要修改視圖的好多地方,因此也就是要修改全局狀態(tài)樹的不同位置。
在這樣的場景中,從視圖發(fā)起的某個action,要么調(diào)用一個很復雜的reducer去到處改數(shù)據(jù),要么再次發(fā)起多個action,讓很多個reducer各自改自己的數(shù)據(jù)。
前者的問題是,代碼耦合太嚴重;后者的問題是,整個流程太難追蹤,比如說,某一塊狀態(tài),想要追蹤到自己是被從哪里發(fā)起的修改所改變的,是非常困難的事情。
如果我們能夠把Observable上面的同步修改過程視為reducer,就可以從另外一些角度大幅簡化代碼,并且讓聯(lián)動邏輯清晰化。例如,如果我們想描述一篇文章的編輯權(quán)限:
const editable$ = Observable.combineLatest(article$, me$) .map(arr => { let [article, me] = arr return me.isAdmin || article.author === me.id })
這段代碼的實質(zhì)是什么?其實本質(zhì)上還是reducer,表達的是數(shù)據(jù)的合并與轉(zhuǎn)換過程,而且是同步的。我們可以把article和me的變更reduce到article$和me$里,由它們派發(fā)隱式的action去推動editable計算新值。
感謝各位的閱讀!關(guān)于“RxJS有什么用”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。