3 ms·

> I want to get better with RxJS I've been really happy using RxJS outside of Angular. I know the author isn't claiming this is the case, but Angular adopting

> I want to get better with RxJS I've been really happy using RxJS outside of Angular. I know the author isn't claiming this is the case, but Angular adopting RxJS is a double-edged sword in that it seems many people equate RxJS with Angular. RxJS + React Hooks is a really powerful pairing to mitigate the hooks madness of more complex components. I use RxJS for the data flows and hooks just to bind the observable to a DOM rerender.

spaceribs 6y ago
Agreed, definitely didn't mean to pigeonhole RxJS. There are so many times I've been saved in the last year from async bugs because of RxJS. That said, it took me almost 6 months of practice to be able to make my code readable and use it scalably. I've actually come up with a solid rule of thumb for when it makes sense to use: If you have 2 async streams of events or data, that's at least 4 success scenarios you have to code for: 1. A has emitted, B hasn't 2. B has emitted, A hasn't 3. A and B haven't emitted 4. A and B have both emitted Now at 2 sources (and ignoring the error cases) that's right on the edge of being able to mentally model it and not forget a case, but at 3 you have 9 cases, at 4 you have 16, etc. etc. The branches and code you'd be creating to deal with this situation procedurally would be far more unreadable compared to the RxJS syntax. It was always a complex problem.
renke1 6y ago
I am also using RxJS in React. I created a few hooks to make it life a bit easier. While I think it's useful for my use cases, I have the feeling a deeper integration would be even more useful (although I don't know how exactly that would look like, maybe better hooks than mine?). Regarding Angular and RxJS, I don't think Angular really embraces RxJS (other than maybe the Async-Pipe). Actually I think it often feels awkward to work with RxJS in Angular, especially when you use observables that are not used via the Async-Pipe, unsubscribing for instance is annoying at best.
- spaceribs 6y ago
  > Actually I think it often feels awkward to work with RxJS in Angular, especially when you use observables that are not used via the Async-Pipe, unsubscribing for instance is annoying at best. I agree with this sentiment, we've been waiting patiently for observable inputs for a ridiculously long time: https://github.com/angular/angular/issues/5689 https://github.com/angular/angular/issues/5689, but I do have a pretty solid pattern for dealing with subscriptions these days: 1. Create one subscription as a private member of your class: https://github.com/spaceribs/plopdown/blob/4823f5017733ee7855a9214cf7959723aa2a7bcd/apps/website/src/app/home/home.component.ts#L32 https://github.com/spaceribs/plopdown/blob/4823f5017733ee785... 2. In your OnInit, subscribe and add that to your main component subscription: https://github.com/spaceribs/plopdown/blob/4823f5017733ee7855a9214cf7959723aa2a7bcd/apps/website/src/app/home/home.component.ts#L103 https://github.com/spaceribs/plopdown/blob/4823f5017733ee785... 3. Unsubscribe from everything in your destroy method: https://github.com/spaceribs/plopdown/blob/4823f5017733ee7855a9214cf7959723aa2a7bcd/apps/website/src/app/home/home.component.ts#L122 https://github.com/spaceribs/plopdown/blob/4823f5017733ee785...

spaceribs 6y ago

Agreed, definitely didn't mean to pigeonhole RxJS. There are so many times I've been saved in the last year from async bugs because of RxJS. That said, it took me almost 6 months of practice to be able to make my code readable and use it scalably. I've actually come up with a solid rule of thumb for when it makes sense to use: If you have 2 async streams of events or data, that's at least 4 success scenarios you have to code for: 1. A has emitted, B hasn't 2. B has emitted, A hasn't 3. A and B haven't emitted 4. A and B have both emitted Now at 2 sources (and ignoring the error cases) that's right on the edge of being able to mentally model it and not forget a case, but at 3 you have 9 cases, at 4 you have 16, etc. etc. The branches and code you'd be creating to deal with this situation procedurally would be far more unreadable compared to the RxJS syntax. It was always a complex problem.

renke1 6y ago

I am also using RxJS in React. I created a few hooks to make it life a bit easier. While I think it's useful for my use cases, I have the feeling a deeper integration would be even more useful (although I don't know how exactly that would look like, maybe better hooks than mine?). Regarding Angular and RxJS, I don't think Angular really embraces RxJS (other than maybe the Async-Pipe). Actually I think it often feels awkward to work with RxJS in Angular, especially when you use observables that are not used via the Async-Pipe, unsubscribing for instance is annoying at best.

spaceribs 6y ago
> Actually I think it often feels awkward to work with RxJS in Angular, especially when you use observables that are not used via the Async-Pipe, unsubscribing for instance is annoying at best. I agree with this sentiment, we've been waiting patiently for observable inputs for a ridiculously long time: https://github.com/angular/angular/issues/5689 https://github.com/angular/angular/issues/5689, but I do have a pretty solid pattern for dealing with subscriptions these days: 1. Create one subscription as a private member of your class: https://github.com/spaceribs/plopdown/blob/4823f5017733ee7855a9214cf7959723aa2a7bcd/apps/website/src/app/home/home.component.ts#L32 https://github.com/spaceribs/plopdown/blob/4823f5017733ee785... 2. In your OnInit, subscribe and add that to your main component subscription: https://github.com/spaceribs/plopdown/blob/4823f5017733ee7855a9214cf7959723aa2a7bcd/apps/website/src/app/home/home.component.ts#L103 https://github.com/spaceribs/plopdown/blob/4823f5017733ee785... 3. Unsubscribe from everything in your destroy method: https://github.com/spaceribs/plopdown/blob/4823f5017733ee7855a9214cf7959723aa2a7bcd/apps/website/src/app/home/home.component.ts#L122 https://github.com/spaceribs/plopdown/blob/4823f5017733ee785...