4 ms·

Are projects still chosing to pick RxJS (or equivalent) which make the code heavily layered and a pain to debug? Or has sanity reached the Angular ecosystem by

• thevillagechief 4mo ago
  Everything is signals now.
• jonkoops 4mo ago
  I believe Signals are the go-to now, but surely RxJS is still present for complex use cases. Are Zones fully gone?
  • vyrotek 4mo ago
    As of v21, zoneless is the default https://angular.love/angular-21-whats-new https://angular.love/angular-21-whats-new
    • jonkoops 4mo ago
      Nice
  • andriy_koval 4mo ago
    Now we have promises, observables and signals. I would be more happy if it would be just one of those..
    • halflife 4mo ago
      Each one of these solves a different problem. Promised - async Observables - streams Signals - reactivity
      • azangru 4mo ago
        > Observables - streams > Signals - reactivity The r in rx stands for reactive.
        • halflife 4mo ago
          The react in react stands for reactivity, however it is not.
          • azangru 4mo ago
            React reacts to changes in state or properties by automatically updating the UI. What's not reactive about that?
            • halflife 4mo ago
              Its entire state management is not reactive, it’s always on push, not pull. You always need to call setState to get render changes.
              • azangru 4mo ago
                But why is push vs pull the definition of reactivity? I suppose we can say that there are different kinds of reactivity. Signals is one kind. Observables à la rxjs is a different kind (the whole model of programming with rxjs was referred to as "functional reactive programming"). Observables are push-based. Signals, as I heard, are a more complex primitive, which, under the hood, is push-pull. React's reactivity model may be crap; but this doesn't make it non-existent.
                • halflife 4mo ago
                  Maybe push pull wasn’t the best metaphor, but the point is that everything can be reactive, it only depends on how much boilerplate you need to write to achieve the desired result. Since react doesn’t have a true reactive model, you need to subscribe to changes manually (use effect) to create computations, while in signals it’s a primitive (computed). I actually created a lib that operates signals over reacts state management (https://roypeled.github.io/react-logic/ https://roypeled.github.io/react-logic/), so I removed the boilerplate to create a true reactive system. If you want, you can create reactive system just from JS primitives, using callbacks. But that doesn’t make JS reactive by nature.
      • wartijn_ 4mo ago
        In theory that’s true (although observables are for reactivity too), but Angular uses observables for its http library and http requests are very much not streams. It’s one of the main downsides of working with Angular, the http library is mediocre and does come with the added overhead and complexity that rxjs brings. Until this release (if you only use stable features) using forms meant dealing with observables too, even if you just want to read data when submitting a form and validating some data on change/blur. And often you’ll find that your data from promises, observables and signals need to interact with each other, which can be annoying. Fortunately the situation with signals and their async usage is improving, and iirc the Angular team wants to make rxjs optional, but until it is Angular can be a confusing mess on some points.
        • halflife 4mo ago
          I partially agree, there is an overlap between signals and rxjs, however the core business is different- observables are about data manipulation, while signals are about efficient state management. Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and using DI it’s a drop in replacement.
      • deleted 4mo ago
        [deleted]
• throw310822 4mo ago
  The problem with Angular is that the http client service used to return observables by default and that made people think that you had to use them as such. It was a mostly useless, massive pain. Working with Angular became a pleasure the moment we decided to just cast our service calls to promises. For the rest, RxJS is cool where you actually need it and want it.
  • jessyco 4mo ago
    I never understood the problem with the rxjs, its a challenge to learn for those not used to the pattern but its very nice. Regardless signals is also fine, we have ways now to interop between rxjs to signal for those looking for it: https://angular.dev/api/core/rxjs-interop/toSignal https://angular.dev/api/core/rxjs-interop/toSignal Personally the http client workflow is fine. Usually lives in a service and exposes the needed values in any form we want.
  • mablopoule 4mo ago
    Agree. RxJS is a beast to approach at first but it's a genuinely cool library, as long as you don't spread observable around when you don't actually need them. I used the same approach for a few years (pushing my http calls behind domain-specific api services that only return promise), and it's way simpler to handle. I still use RxJS, but mostly in the top-level component and/or service who orchestrate between data, url state and api responses. Those top-level page usually keep the default change detection instead of the 'on-push' strategy).