跳转到主要内容

标签(标签)

资源精选(342) Go开发(108) Go语言(103) Go(99) angular(82) LLM(75) 大语言模型(63) 人工智能(53) 前端开发(50) LangChain(43) golang(43) 机器学习(39) Go工程师(38) Go程序员(38) Go开发者(36) React(33) Go基础(29) Python(24) Vue(22) Web开发(20) Web技术(19) 精选资源(19) 深度学习(19) Java(18) ChatGTP(17) Cookie(16) android(16) 前端框架(13) JavaScript(13) Next.js(12) 安卓(11) 聊天机器人(10) typescript(10) 资料精选(10) NLP(10) 第三方Cookie(9) Redwoodjs(9) LLMOps(9) Go语言中级开发(9) 自然语言处理(9) PostgreSQL(9) 区块链(9) mlops(9) 安全(9) 全栈开发(8) ChatGPT(8) OpenAI(8) Linux(8) AI(8) GraphQL(8) iOS(8) 软件架构(7) Go语言高级开发(7) AWS(7) C++(7) 数据科学(7) whisper(6) Prisma(6) 隐私保护(6) RAG(6) JSON(6) DevOps(6) 数据可视化(6) wasm(6) 计算机视觉(6) 算法(6) Rust(6) 微服务(6) 隐私沙盒(5) FedCM(5) 语音识别(5) Angular开发(5) 快速应用开发(5) 提示工程(5) Agent(5) LLaMA(5) 低代码开发(5) Go测试(5) gorm(5) REST API(5) 推荐系统(5) WebAssembly(5) GameDev(5) CMS(5) CSS(5) machine-learning(5) 机器人(5) 游戏开发(5) Blockchain(5) Web安全(5) Kotlin(5) 低代码平台(5) 机器学习资源(5) Go资源(5) Nodejs(5) PHP(5) Swift(5) 智能体(4) devin(4) Blitz(4) javascript框架(4) Redwood(4) GDPR(4) 生成式人工智能(4) Angular16(4) Alpaca(4) 编程语言(4) SAML(4) JWT(4) JSON处理(4) Go并发(4) kafka(4) 移动开发(4) 移动应用(4) security(4) 隐私(4) spring-boot(4) 物联网(4) nextjs(4) 网络安全(4) API(4) Ruby(4) 信息安全(4) flutter(4) 专家智能体(3) Chrome(3) CHIPS(3) 3PC(3) SSE(3) 人工智能软件工程师(3) LLM Agent(3) Remix(3) Ubuntu(3) GPT4All(3) 软件开发(3) 问答系统(3) 开发工具(3) 最佳实践(3) RxJS(3) SSR(3) Node.js(3) Dolly(3) 移动应用开发(3) 低代码(3) IAM(3) Web框架(3) CORS(3) 基准测试(3) Go语言数据库开发(3) Oauth2(3) 并发(3) 主题(3) Theme(3) earth(3) nginx(3) 软件工程(3) azure(3) keycloak(3) 生产力工具(3) gpt3(3) 工作流(3) C(3) jupyter(3) 认证(3) prometheus(3) GAN(3) Spring(3) 逆向工程(3) 应用安全(3) Docker(3) Django(3) R(3) .NET(3) 大数据(3) Hacking(3) 渗透测试(3) C++资源(3) Mac(3) 微信小程序(3) Python资源(3) JHipster(3) 大型语言模型(2) 语言模型(2) 可穿戴设备(2) JDK(2) SQL(2) Apache(2) Hashicorp Vault(2) Spring Cloud Vault(2) Go语言Web开发(2) Go测试工程师(2) WebSocket(2) 容器化(2) AES(2) 加密(2) 输入验证(2) ORM(2) Fiber(2) Postgres(2) Gorilla Mux(2) Go数据库开发(2) 模块(2) 泛型(2) 指针(2) HTTP(2) PostgreSQL开发(2) Vault(2) K8s(2) Spring boot(2) R语言(2) 深度学习资源(2) 半监督学习(2) semi-supervised-learning(2) architecture(2) 普罗米修斯(2) 嵌入模型(2) productivity(2) 编码(2) Qt(2) 前端(2) Rust语言(2) NeRF(2) 神经辐射场(2) 元宇宙(2) CPP(2) 数据分析(2) spark(2) 流处理(2) Ionic(2) 人体姿势估计(2) human-pose-estimation(2) 视频处理(2) deep-learning(2) kotlin语言(2) kotlin开发(2) burp(2) Chatbot(2) npm(2) quantum(2) OCR(2) 游戏(2) game(2) 内容管理系统(2) MySQL(2) python-books(2) pentest(2) opengl(2) IDE(2) 漏洞赏金(2) Web(2) 知识图谱(2) PyTorch(2) 数据库(2) reverse-engineering(2) 数据工程(2) swift开发(2) rest(2) robotics(2) ios-animation(2) 知识蒸馏(2) 安卓开发(2) nestjs(2) solidity(2) 爬虫(2) 面试(2) 容器(2) C++精选(2) 人工智能资源(2) Machine Learning(2) 备忘单(2) 编程书籍(2) angular资源(2) 速查表(2) cheatsheets(2) SecOps(2) mlops资源(2) R资源(2) DDD(2) 架构设计模式(2) 量化(2) Hacking资源(2) 强化学习(2) flask(2) 设计(2) 性能(2) Sysadmin(2) 系统管理员(2) Java资源(2) 机器学习精选(2) android资源(2) android-UI(2) Mac资源(2) iOS资源(2) Vue资源(2) flutter资源(2) JavaScript精选(2) JavaScript资源(2) Rust开发(2) deeplearning(2) RAD(2)

category

Introduction of signals has stirred quite a storm in angular developer community (and outside as well). And quite rightly so. Lets see why is there so much hype around it

Advantages of Signals

Performance

With signals, angular applications can have fine-grained reactivity. Which means only the DOM nodes which needs to be updated will be updated. This can potentially make angular application very efficient about its DOM updates and change detection. In contrast, currently in angular whole tree goes through dirty checking because the framework doesn’t know which part of the DOM depends on which part of the view model.

Also, with signals we can finally have zone-less application, as framework will get notification for any changes happening in the view model which uses signals.

Even in current version of angular without signals we can still get highly performant application, but signals will make it hard to shot ourself in the foot and accidentally create performance related issues.

Developer doesn’t need to worry about which changeDetectionStrategy to use, or calling functions is template, or memoize functions or using pipes. All these best practices to build performant app might become irrelevant. Less thing to learn is always good thing

Developer Ergonomics

Any moderate to complex angular applications has a lot of rxjs usages. Though rxjs is a very useful library, it might not be easy to grasp for lot of developers. To create a reactive applications, and handle race conditions rxjs becomes essential. Cant live with it, cant leave without it.

But with signals we can potentially get rid of most of rxjs code. This will make angular much more welcoming to new developers and increase overall readability of the code base.

Distinction between rxjs and signals

While going through example usages of signals, lot of developers might feels is just rxjs with different apis. The similarity is uncanny, especially with BehaviourSubject

//Example behaviourSubject usage
const subject = new BehaviourSubject(0);
subject.getValue();
subject.next(1);
subject.subscribe((data) => {
  console.log(data)
})

//Example signal usage
const sig = signal(0);
sig()
sig.set(1)
effect(() => {
  console.log(sig())
})

But once we dig in a little bit the distinction starts getting more clear.

Signals are always sync. Hence you can always get current value of a signal. But Observable is not always sync. It may be sync or async, we cant say for certain. It’s very straightforward to get current value of signal but not so much for Observable . With BehaviourSubject sure we can always get current value in sync, but once we do any kind of operation, we loose that capability.

const number = new BehaviourSubject(0);
number.getValue();
const isOdd = number.pipe(map((data) => data % 2 ? true : false));
isOdd.getValue() //<--- we can not do this

const numberSignal = new BehaviourSubject(0);
numberSignal();
const isOddSignal = computed(() => numberSignal() % 2 ? true : false);
isOddSignal() //<--- we can do this

Also signal do not require distinctUntilChange or shareReplay for multicasting, unlike Observable in most cases.

Then we don’t need rxjs?

Well, not exactly. Because signal is always sync. They are very good candidate for storing states or view model. But signals are not very good candidate for async stuff, like events, or XHR calls. For those we would still need rxjs, mostly.

Classic example is search-as-you-type usecase, where we leverage, debounceTime distinctUntilChanges and switchMap

const searchValue$: Observable<string> //lets assume this is comes from input
const result$ = searchValue$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((input) => {
    return this.http.get('/seach?' + input)
  })
)

For converting this to use signals, we might jump from signal to observable then back to signals

const searchValue: Signal<string>
const searchValue$ = fromSignal(searchValue); //convert signal to observable
const result$ = searchValue$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((input) => {
    return this.http.get('/seach?' + input)
  })
)
const result = fromObservable(result$) //convert observable back to signal

In a world where signals are adopted completely we might see rxjs used sparingly only for such use case. It’s little awkward to keep jumping between signal and rxjs way of writing code. But maybe we can remove rxjs completely even for such cases?

const searchValue: Signal<string>
const debouncedSearchValue = signal(searchValue());
const results: WritableSignal<Result[]> = signal([])
/**
* This effect add debounced search term in a new signal
*/
effect(() => {
  const search = searchValue();
  const timeout = setTimeout(() => {
    debouncedSearchValue.set(search)
  });
  return () => {
    clearTimeout(timeout)
  }
})
/**
* This effect uses debounceSearchValue instead of searchValue
* to trigger api call
*/
effect(() => {
  const subscription = this.http.get('/seach?' + debouncedSearchValue())
  .subscribe((res) => {
    results.set(res)
  })
  return () => {
    subscription.unsubscribe()
  }
})

If you are comparing the code with and without rxjs, ofcourse, the one using rxjs looks much more concise. Let’s refactor it a little bit to make it more concise.

const searchValue: Signal<string>
const debounceSearchValue = debouncedSignal(searchValue);
const results: WritableSignal<Result[]> = signal([]);
effect(() => {
  const subscription = this.http.get('/seach?' + debouncedSearchValue())
  .subscribe((res) => {
    results.set(res)
  })
  return () => {
    subscription.unsubscribe()
  }
})

This looks better. Still less concise than rxjs one, but we don’t need to learn rxjs to understand this. This is much more beginner friendly IMHO.

BTW if you are wondering debouncedSignal function used above looks like this

function debouncedSignal<T>(input: Signal<T>): Signal<T> {
  const debounceSignal = signal(input());
  effect(() => {
    const value = input();
    const timeout = setTimeout(() => {
      debounceSignal.set(value)
    });
    return () => {
      clearTimeout(timeout)
    }
  });
  return debounceSignal
}

Conclusion

Yes, signals can replace rxjs. But, maybe not completely. Even if it does, there will be some tradeoffs. rxjs brings conciseness and signals make if easier to read.

How these use-cases and patterns will evolve is something we all will see in due time and developers start exploring more. But signals are here to change how we code in angular and the hype is real

文章链接