- Learning RxJava
- Thomas Nield
- 263字
- 2021-07-02 22:22:50
When to use RxJava
A common question ReactiveX newcomers ask is what circumstances warrant a reactive approach? Do we always want to use RxJava? As someone who has been living and breathing reactive programming for a while, I have learned that there are two answers to this question:
The first answer is when you first start out: yes! You always want to take a reactive approach. The only way to truly become a master of reactive programming is to build reactive applications from the ground up. Think of everything as Observable and always model your program in terms of data and event flows. When you do this, you will leverage everything reactive programming has to offer and see the quality of your applications go up significantly.
The second answer is that when you become experienced in RxJava, you will find cases where RxJava may not be appropriate. There will occasionally be times where a reactive approach may not be optimal, but usually, this exception applies to only part of your code. Your entire project itself should be reactive. There may be parts that are not reactive and for good reason. These exceptions only stand out to a trained Rx veteran who sees that returning List<String> is perhaps better than returning Observable<String>.
Rx greenhorns should not worry about when something should be reactive versus something not reactive. Over time, they will start to see cases where the benefits of Rx are marginalized, and this is something that only comes with experience.
So for now, no compromises. Go reactive all the way!
- FreeSWITCH 1.8
- Java技術手冊(原書第7版)
- RTC程序設計:實時音視頻權威指南
- Python Data Analysis Cookbook
- 區塊鏈技術與應用
- 基于ARM Cortex-M4F內核的MSP432 MCU開發實踐
- Visual C#.NET Web應用程序設計
- Clojure High Performance Programming(Second Edition)
- Java核心技術速學版(第3版)
- Serverless從入門到進階:架構、原理與實踐
- Python Natural Language Processing
- VB語言程序設計教程(第2版)
- iOS程序員面試筆試真題與解析
- Node.js入門指南
- Web測試囧事