ฉันได้ใช้Redux-Saga รหัสที่เขียนด้วยเหตุผลนั้นง่ายมากยกเว้นฟังก์ชั่นตัวสร้าง JS ทำให้หัวของฉันสับสนเป็นครั้งคราว จากความเข้าใจของฉันRedux-Observableสามารถทำงานที่คล้ายกันซึ่งจัดการกับผลข้างเคียง แต่ไม่ต้องใช้ฟังก์ชันเครื่องกำเนิดไฟฟ้า

อย่างไรก็ตามเอกสารจาก Redux-Observable ไม่ได้ให้ความเห็นมากมายว่าเหตุใดจึงเหนือกว่า Redux-Saga ฉันต้องการทราบว่าการไม่ใช้ฟังก์ชันเครื่องกำเนิดไฟฟ้าเป็นประโยชน์เพียงอย่างเดียวของการใช้ Redux-Observable หรือไม่ และอะไรคือข้อเสีย gotcha หรือการประนีประนอมจากการใช้ Redux-Observable แทน Redux-Saga? ขอบคุณล่วงหน้า.

ข้อจำกัดความรับผิดชอบ: ฉันเป็นหนึ่งในผู้เขียนเรื่อง redux-observable ดังนั้นจึงยากสำหรับฉันที่จะเป็นกลาง 100%

ขณะนี้เราไม่ได้ให้เหตุผลใด ๆ ที่สามารถสังเกตได้ว่า redux ดีกว่า redux-saga เพราะ ... ไม่ใช่ 😆

tl; dr มีข้อดีข้อเสียทั้งสองอย่าง หลายคนจะพบว่าหนึ่งใช้งานง่ายกว่าอีกแบบหนึ่ง แต่ทั้งสองอย่างมีความซับซ้อนในการเรียนรู้ในรูปแบบที่แตกต่างกันหากคุณไม่รู้จัก RxJS (redux-observable) หรือเครื่องกำเนิด / "effects as data" (redux-saga)

พวกเขาแก้ปัญหาเดียวกันด้วยวิธีที่คล้ายกันมาก แต่มีความแตกต่างพื้นฐานบางอย่างที่เห็นได้ชัดเมื่อคุณใช้เพียงพอเท่านั้น

redux-observable เลื่อนเกือบทุกอย่างไปที่ RxJS ที่เป็นสำนวน ดังนั้นหากคุณมีความรู้ RxJS (หรือได้รับมัน) การเรียนรู้และใช้การสังเกตซ้ำได้นั้นเป็นเรื่องธรรมชาติสุด ๆ นั่นหมายความว่าความรู้นี้สามารถถ่ายโอนไปยังสิ่งอื่นที่ไม่ใช่เรกซ์ หากคุณตัดสินใจที่จะเปลี่ยนไปใช้ MobX หากคุณตัดสินใจที่จะเปลี่ยนไปใช้ Angular2 หากคุณตัดสินใจที่จะเปลี่ยนไปใช้ความร้อนแรง X ในอนาคตโอกาสที่ RxJS จะช่วยคุณได้นั้นดีมาก เนื่องจาก RxJS เป็นไลบรารี async ทั่วไปและในหลาย ๆ ด้านก็เหมือนกับภาษาโปรแกรมในตัวมันเองนั่นคือกระบวนทัศน์ "Reactive Programming" ทั้งหมด RxJS มีมาตั้งแต่ปี 2012 และเริ่มต้นเป็นพอร์ตของ Rx.NET (มี "พอร์ต" ในเกือบทุกภาษาหลักซึ่งมีประโยชน์มาก )

redux-saga ให้ตัวดำเนินการตามเวลาดังนั้นในขณะที่ความรู้ที่คุณได้รับเกี่ยวกับเครื่องกำเนิดไฟฟ้าและการจัดการผลข้างเคียงในรูปแบบตัวจัดการกระบวนการนี้สามารถถ่ายโอนได้ แต่ตัวดำเนินการและการใช้งานจริงจะไม่ถูกใช้ในไลบรารีหลักอื่น ๆ นั่นเป็นเรื่องโชคร้ายเล็กน้อย แต่ไม่ควรเป็นตัวทำลายข้อตกลงด้วยตัวเอง

นอกจากนี้ยังใช้ "เอฟเฟกต์เป็นข้อมูล" ( อธิบายไว้ที่นี่ ) ซึ่งอาจจะยากที่จะคาดเดาในตอนแรก แต่หมายความว่าโค้ด redux-saga ของคุณไม่ได้ทำผลข้างเคียงเอง ฟังก์ชันตัวช่วยที่คุณใช้จะสร้างอ็อบเจ็กต์ที่เหมือนกับงานที่แสดงถึงเจตนาในการทำผลข้างเคียงจากนั้นไลบรารีภายในจะดำเนินการให้คุณ ทำให้การทดสอบทำได้ง่ายมากโดยไม่ต้องมีการล้อเลียนและเป็นที่ดึงดูดใจสำหรับบางคน อย่างไรก็ตามโดยส่วนตัวแล้วฉันพบว่ามันหมายความว่าการทดสอบหน่วยของคุณนำตรรกะของเทพนิยายของคุณมาใช้อีกครั้งทำให้การทดสอบเหล่านั้นไม่ได้มีประโยชน์มาก IMO (ทุกคนไม่ได้แบ่งปันความคิดเห็นนี้)

คนมักถามว่าทำไมเราไม่ทำอะไรแบบนั้นกับ redux-observable: สำหรับฉันแล้วมันเข้ากันไม่ได้กับ Rx ที่เป็นสำนวนปกติ ใน Rx เราใช้ตัวดำเนินการเช่นนี้.debounceTime()ที่ห่อหุ้มลอจิกที่จำเป็นในการ debounce แต่นั่นหมายความว่าหากเราต้องการสร้างเวอร์ชันที่ไม่ได้ทำการ debouncing จริง ๆ และปล่อยวัตถุงานออกมาด้วยเจตนาแทนตอนนี้คุณได้สูญเสีย พลังของ Rx เนื่องจากคุณไม่สามารถเชื่อมโยงตัวดำเนินการได้อีกต่อไปเพราะพวกเขากำลังดำเนินการกับวัตถุงานนั้นไม่ใช่ผลลัพธ์ที่แท้จริงของการดำเนินการ นี่เป็นเรื่องยากที่จะอธิบายอย่างหรูหรา ต้องมีความเข้าใจอย่างหนักอีกครั้งเกี่ยวกับ Rx เพื่อทำความเข้าใจความไม่ลงรอยกันของแนวทาง หากคุณต้องการบางสิ่งเช่นนั้นจริงๆให้ตรวจสอบวงจรซ้ำซ้อนซึ่งใช้ cycle.js และส่วนใหญ่มีเป้าหมายเหล่านั้น ฉันคิดว่ามันต้องมีพิธีรีตองมากเกินไปสำหรับรสนิยมของฉัน แต่ฉันขอแนะนำให้คุณหมุนมันถ้าคุณสนใจ

ดังที่ ThorbenA กล่าวถึงฉันไม่อายที่จะยอมรับว่าปัจจุบัน redux-saga (10/13/16) เป็นผู้นำที่ชัดเจนในการจัดการผลข้างเคียงที่ซับซ้อนสำหรับ redux เริ่มต้นขึ้นก่อนหน้านี้และมีชุมชนที่แข็งแกร่งมากขึ้น ดังนั้นจึงมีแรงดึงดูดมากมายในการใช้มาตรฐานทางพฤตินัยกับเด็กใหม่ในบล็อก ฉันคิดว่ามันปลอดภัยที่จะบอกว่าหากคุณใช้โดยไม่ได้รับความรู้มาก่อนคุณกำลังสับสน เราทั้งสองใช้แนวคิดขั้นสูงพอสมควรซึ่งเมื่อคุณ "ได้รับ" ทำให้การจัดการผลข้างเคียงที่ซับซ้อนง่ายขึ้นมาก แต่ก็มีหลายอย่างสะดุด

คำแนะนำที่สำคัญที่สุดที่ฉันสามารถให้ได้คืออย่านำห้องสมุดเหล่านี้เข้ามาก่อนที่คุณจะต้องการ หากคุณเพียงโทรผ่าน ajax ธรรมดาคุณอาจไม่จำเป็นต้องใช้ redux-thunk นั้นโง่ง่ายในการเรียนรู้และให้เพียงพอสำหรับพื้นฐาน - แต่ยิ่ง async ซับซ้อนมากเท่าไหร่ก็ยิ่งยากขึ้น (หรือเป็นไปไม่ได้) ก็จะกลายเป็น redux-thunk แต่สำหรับ redux-observable / saga ในหลาย ๆ ด้านมันส่องแสงที่สุด async ที่ซับซ้อนกว่า นอกจากนี้ยังมีข้อดีอีกมากมายในการใช้ redux-thunk กับหนึ่งในคนอื่น ๆ (redux-observable / saga) ในโครงการเดียวกัน! redux-thunk สำหรับสิ่งง่ายๆทั่วไปของคุณจากนั้นใช้ redux-observable / saga สำหรับสิ่งที่ซับซ้อนเท่านั้น นั่นเป็นวิธีที่ยอดเยี่ยมในการทำงานอย่างมีประสิทธิผลดังนั้นคุณจึงไม่ต้องต่อสู้กับสิ่งที่ซ้ำซากที่สังเกตได้ / เทพนิยายสำหรับสิ่งที่ไม่สำคัญกับ redux-thunk

ฉันคิดว่ามีหลายสิ่งที่คุณต้องคำนึงถึง

1. ความซับซ้อน
2. รูปแบบการเข้ารหัส
3. เส้นโค้งการเรียนรู้
4. การตรวจสอบได้

สมมติว่าเราต้องการดึงข้อมูลผู้ใช้จาก API

// Redux-Saga

import axios from 'axios' 

function* watchSaga(){
  yield takeEvery('fetch_user', fetchUser) // waiting for action (fetch_user)
}

function* fetchUser(action){
    try {
        yield put({type:'fetch_user_ing'})
        const response = yield call(axios.get,'/api/users/1')
        yield put({type:'fetch_user_done',user:response.data})
  } catch (error) {
        yield put({type:'fetch_user_error',error})
  }
}

// Redux-Observable
import axios from 'axios'

const fetchUserEpic = action$ => 
    action$
        .ofType('fetch_user')
        .flatMap(()=>
          Observable.from(axios.get('/api/users/1')) // or use Observable.ajax
            .map(response=>({type:'fetch_user_done', user:response.data}))
            .catch(error => Observable.of({type:'fetch_user_error',error}))
            .startWith({type:'fetch_user_ing'})
        )

นอกจากนี้ฉันได้เขียนบทความนี้เพื่อเปรียบเทียบความแตกต่างระหว่าง Redux-saga และ Redux-Observable ในเชิงลึก ตรวจสอบการเชื่อมโยงที่นี่หรือนำเสนอ

ฉันใช้ Redux-Observable มากกว่า Redux-Saga เพราะชอบทำงานกับสิ่งที่สังเกตได้มากกว่าเครื่องกำเนิดไฟฟ้า ฉันใช้กับ RXJS ซึ่งเป็นไลบรารีที่มีประสิทธิภาพสำหรับการทำงานกับสตรีมข้อมูล คิดว่ามันเหมือน lodash สำหรับ async ในแง่ของข้อเสีย gotcha และการประนีประนอมในการเลือกอย่างใดอย่างหนึ่งลองดูคำตอบนี้จาก Jay Phelps:

redux-saga เนื่องจากโปรเจ็กต์มีอยู่นานกว่าที่สามารถสังเกตได้ซ้ำซ้อนดังนั้นจึงเป็นจุดขายสำคัญอย่างหนึ่ง คุณจะพบเอกสารตัวอย่างและมีแนวโน้มที่จะมีชุมชนที่ดีกว่าที่จะได้รับการสนับสนุนจาก

การโต้แย้งว่าโอเปอเรเตอร์และ API ที่คุณเรียนรู้ใน redux-saga นั้นแทบจะไม่สามารถถ่ายโอนได้เหมือนกับการเรียนรู้ RxJS ซึ่งใช้กันทั่วทุกที่ redux-observable นั้นง่ายสุด ๆ ภายในเป็นเพียงวิธีที่เป็นธรรมชาติสำหรับคุณในการใช้ RxJS ดังนั้นหากคุณรู้จัก RxJS (หรือต้องการ) มันเป็นสิ่งที่เป็นธรรมชาติอย่างยิ่ง

คำแนะนำของฉันสำหรับคนส่วนใหญ่ในขณะนี้คือถ้าคุณต้องถามว่าคุณควรใช้อันไหนคุณควรเลือก redux-saga

Redux-Observable เป็นไลบรารีที่น่าทึ่งเราใช้ในการผลิตเป็นเวลา 1.5 ปีโดยไม่มีปัญหาใด ๆ จนถึงขณะนี้สามารถทดสอบได้อย่างสมบูรณ์แบบและสามารถรวมเข้ากับเฟรมเวิร์กได้อย่างง่ายดาย เรากำลังมีช่องซ็อกเก็ตแบบขนานที่มากเกินไปและสิ่งเดียวที่ช่วยเราจากการค้างคือ Redux-Observable

ฉันมี 3 จุดที่อยากจะพูดถึงที่นี่

1. ความซับซ้อนและเส้นโค้งการเรียนรู้

Redux-saga สามารถเอาชนะ Redux ได้อย่างง่ายดายที่นี่ หากคุณต้องการเพียงแค่คำของ่ายๆเพื่อให้การอนุญาตเสร็จสิ้นและคุณไม่ต้องการใช้ redux-thunk ด้วยเหตุผลบางประการคุณควรพิจารณาใช้ redux-saga มันจะง่ายกว่าที่จะเข้าใจ

หากคุณไม่มีความรู้มาก่อนเกี่ยวกับ Observable มันจะเป็นความเจ็บปวดสำหรับคุณและทีมของคุณจะต้องเจอคุณแน่นอน :)

2. Observable และ RxJS เสนออะไรให้ฉันได้บ้าง?

เมื่อพูดถึง async logic Observable คือมีดสวิสของคุณ Observable สามารถทำเกือบทุกอย่างให้คุณได้ คุณไม่ควรเปรียบเทียบสิ่งเหล่านี้กับสัญญาหรือเครื่องกำเนิดไฟฟ้ามันทรงพลังกว่ามากเหมือนกับการเปรียบเทียบ Optimus Prime กับ Chevrolet

แล้ว RxJS ล่ะ? มันเหมือนกับ lodash.js แต่สำหรับ async logic เมื่อคุณอยู่ในนั้นคุณจะไม่เปลี่ยนไปใช้สิ่งอื่น

3. ส่วนขยายปฏิกิริยา

เพียงตรวจสอบลิงค์นี้

http://reactivex.io/languages.html

ส่วนขยายปฏิกิริยาถูกนำไปใช้กับภาษาการเขียนโปรแกรมสมัยใหม่ทั้งหมดมันเป็นเพียงกุญแจสำคัญของคุณในการเขียนโปรแกรมเชิงฟังก์ชัน

ดังนั้นใช้เวลาของคุณอย่างชาญฉลาดเรียนรู้ RxJS และใช้ redux-observable :)

ฉันให้ความสำคัญกับความสามารถในการถ่ายโอนข้ามภาษาและเวลาทำงานที่ Rx มี แม้ว่าแอปของคุณจะไม่เปลี่ยนภาษา แต่อาชีพของคุณก็อาจ ใช้ประโยชน์สูงสุดจากการเรียนรู้ของคุณไม่ว่าคุณจะเพิ่มขนาดให้กับตัวเอง เป็นประตูที่ยอดเยี่ยมสำหรับ. Net LINQ โดยเฉพาะ

เนื่องจากมีการพูดคุยซ้ำซ้อนมากมายที่นี่ฉันคิดว่าฉันจะให้แง่มุมของการโต้เถียง ฉันไม่ได้ใช้ redux-observable หรือ RxJS ดังนั้นฉันจึงไม่สามารถเปรียบเทียบแบบเคียงข้างกันได้ แต่ฉันใช้ sagas เพื่อเอฟเฟกต์ที่ยอดเยี่ยม

สำหรับสิ่งที่คุ้มค่าฉันใช้ sagas ในการผลิตในเว็บแอปพลิเคชัน

Sagas กับ Thunk

ซากะชนะมือลง ฉันไม่ชอบวิธีที่ thunk ใส่ตรรกะในผู้สร้างการกระทำของฉัน นอกจากนี้ยังทำให้การทำคำขอสองสามรายการในแถวลำบาก ฉันมองสั้น ๆ เกี่ยวกับ redux ที่สังเกตได้สำหรับงานนี้ แต่ตกลงที่ Sagas

การเรียนรู้ Curve สำหรับ Sagas

การทำความเข้าใจว่าเครื่องกำเนิดไฟฟ้าคืออะไรและเหตุใดจึงสำคัญคือกุญแจสำคัญในการทำความเข้าใจเกี่ยวกับ Sagas แต่ฉันจะเน้นว่าคุณไม่จำเป็นต้องรู้จักเครื่องกำเนิดไฟฟ้าทั้งภายในและภายนอก คุณเพียงแค่ต้องรู้ว่าคุณกำลังยกเลิกการควบคุมด้วยคำสั่งผลตอบแทนและเทพนิยายจะส่งผ่านการควบคุมกลับหลังจากที่รหัส async ของคุณถูกแก้ไข หลังจากนั้นก็ไม่ยากที่จะเข้าใจว่าเกิดอะไรขึ้นในเทพนิยาย

วิธีการเทพนิยายหลักคือ (จากประสบการณ์ของฉัน):

• call- เรียกรหัสบิตใดก็ได้และรับค่าส่งคืน รองรับคำสัญญา การทำงานร่วมกันที่ยอดเยี่ยมระหว่างการประมวลผลแบบ async และ sagas
• select- เรียกตัวเลือก บิตนี้ค่อนข้างยอดเยี่ยม ตัวเลือกเป็นแกนหลักในการลดขนาดและรองรับ 100%!
• put- aka dispatchการกระทำ ในความเป็นจริงจัดส่งให้มากที่สุดเท่าที่คุณต้องการ!

มีฟังก์ชั่นอื่น ๆ แต่ถ้าคุณสามารถควบคุมทั้งสามอย่างนี้ได้คุณจะอยู่ในจุดที่ดีจริงๆ

ข้อสรุป

เหตุผลที่ฉันเลือก sagas คือความสะดวกในการใช้งาน การสังเกตซ้ำได้ดูเหมือนเป็นความท้าทาย ฉันพอใจ 100% กับ sagas มีความสุขมากกว่าที่ฉันเคยคาดไว้

จากประสบการณ์ของฉัน Sagas (ทาง) ดีกว่า thunks และค่อนข้างเข้าใจง่าย Rx ไม่ใช่ถ้วยชาของทุกคน ฉันขอพิจารณาอย่างยิ่งว่า sagas แทนการสังเกตซ้ำได้หากคุณไม่ได้มาจากระบบนิเวศนั้นและ / หรือไม่ได้วางแผนที่จะใช้ Rx ในอนาคต

ถ้าคุณเขียนโปรแกรมประยุกต์ของคุณใน typescript ผมขอแนะนำให้ตรวจสอบtypeless ได้รับแรงบันดาลใจจาก Redux-Observable และขึ้นอยู่กับ RxJS ด้วย แต่มีระบบนิเวศทั้งหมดสำหรับการสร้างแอป

ข้อเสียที่ใหญ่ที่สุดของ redux-observable / redux-saga คือการขาดแนวทาง ไม่มีแนวทางอย่างเป็นทางการเกี่ยวกับวิธีการลดน้ำหนักแบบขี้เกียจ, sagas หรือมหากาพย์ การแยกโค้ดเป็นสิ่งสำคัญเมื่อปรับขนาดแอปที่ใหญ่ขึ้น โซลูชันที่กำหนดเองสำหรับการโหลดแบบขี้เกียจมักจะไม่ทำงานกับ HMR ซึ่งทำให้เกิดประสบการณ์ของนักพัฒนาที่ไม่ดี

ผู้เชี่ยวชาญประเภทไม่มีประเภท:

1. ออกแบบมาสำหรับ TypeScript
   API ทั้งหมดได้รับการออกแบบสำหรับ typescript และ type-safety:
   • typescript จะเพิ่มผลผลิตของคุณไม่ทำให้คุณช้าลง
   • จำเป็นต้องมีคำอธิบายประกอบที่จำเป็นเท่านั้น: สถานะอาร์กิวเมนต์การดำเนินการ
   • ไม่มีพิมพ์ดีด ทุกอย่างจะถูกอนุมานโดยอัตโนมัติ 95% ของโค้ดดูเหมือนจาวาสคริปต์แท้
   • ไม่มี RootAction, RootEpic, RootState หรือตัวช่วยอื่น ๆ
2. จัดเตรียมแบบสำเร็จรูปทั้งหมด
   • Typeless รวมทุกอย่างเพื่อสร้างแอพขนาดกลางหรือระดับองค์กร
   • คุณไม่จำเป็นต้องพึ่งพาไลบรารีขนาดเล็กหลาย ๆ
3. modularity
   • การแยกโมดูลที่เหมาะสมเป็นสิ่งสำคัญสำหรับการสร้างแอปที่ปรับขนาดได้
   • ไม่จำเป็นต้องสร้างไฟล์รูทสำหรับมหากาพย์ตัวลดประเภทและอื่น ๆ เมื่อคุณสร้างโมดูลใหม่คุณสามารถแนบไฟล์จากที่ใดก็ได้ คล้ายกับส่วนประกอบของปฏิกิริยามาตรฐาน
4. ดื้อดึง
   • กรณีการใช้งานทั่วไปและปัญหาทั้งหมดจะได้รับการแก้ไขโดยค่าเริ่มต้น ไม่ต้องคิดมากว่าจะแก้ไขปัญหาเล็กน้อยได้อย่างไร
   • มีคำแนะนำและแนวทางปฏิบัติที่ดีที่สุดให้!

ตรวจสอบhttps://typeless.js.org/