This solved a problem I've had in Angular for years
Вставка
- Опубліковано 4 сер 2024
- Ideally, we want our data to be reactive right from the source, but sometimes we are just dealing with imperative APIs. RxDB makes it possible to have reactive local storage of data, and provides us with the power of a document based NoSQL database.
This video was sponsored by the RxDB team, but I had complete editorial and creative control over this video (including publishing with negative opinions if I desired).
More information on RxDB: rxdb.info/?...
Leave them a start on GitHub: github.com/pubkey/rxdb
Previous video on the Signals/RxJS state management approach: • Will this new signals ...
Source code: github.com/joshuamorony/quick...
0:00 Introduction
0:14 The Problem with Storage
0:56 Reactive Storage with RxDB
2:31 Syncing to a Backend
3:22 Conclusion
#angular #rxdb #rxjs
You can find a quick start guide and more here: rxdb.info/?
OMG, how cool is that! This is soooo helpful! Very cool approach with RxDB and CouchDB, maybe you could do a few more videos about this. Thanks a lot 👍
This is great, thanks alot for sharing 🎉
that thing for auto update the frontend when the database is changed is great. some time is hard to do something like that
Can you make a video on how it will be to implement with an existing firestore db please
I was traumatized by NoSQL in 2016. But it looks like you can back this up with a Postgres database. That might be really interesting.
I loved the idea of PouchDB + CouchDB around the same time, got super into it, but there were enough rough edges/difficulty to make me stop using it. This is making me want to give the whole CouchDB thing a go again.
It sure does sound interesting, but it sounds like it has a huge performance impact. Not to mention the db costs for all those calls that might be not needed.
Also, does it mean we have an open connection always? If so, it doesn't sound scalable.
What are your thoughts?
What performance impact are you referring to? I don't know nearly enough about the internals to make insightful comments around performance - but if you mean in terms of syncing it to some remote backend there are actually potentially some benefits here (over say using just Firestore): rxdb.info/replication-firestore.html
Anyone know what diagraming tool Joshua is using?
I do, it's Excalidraw!
@@JoshuaMorony Thank you my friend.
What is this „takeUntilDestroyed“ operator? Did you implement it yourself or is it a new rxjs operator?
It's a new one provided by angular/core/rxjs-interop - if used within an injection it will unsub when the component/service is destroyed, if used outside of an injection context you need to manually supply a DestroyRef
What is the différence with RxDb and FireStore + AngularFire ? You can do that sins years with AngularFire and observable.
the difference is the sponsorship lol
@@cloudsss83 no way
One of the big differences is that you can sync RxDB with many different backends (couchdb, p2p, firebase, websocket etc.) while Firestore is a vendor lock-in which is not an option if you already have a backend and need a frontend app. Also firestore is not really offline-first because it requires you to run the auth cycle on application startup at least once which will not work if the user is offline.
I was expecting the "after" code to look a little more minimal than that. 1:40 may be reactive, but it is not what I would call *readable*. Is there a way to improve that? What is `addIdToChecklist`?
In what way would you want to improve it? You could certainly use a more imperative style if you like - as for addIdToChecklist this is just a function that generates a human readable slug to use as the id for the checklist (e.g. for a title of "my checklist" it would generate the slug/id "my-checklist")
@@JoshuaMorony I may place too high a value on making code concise. The intent of the `add` service method (which isn't even a method, but a subscription to a Subject, weirdly) gets lost in all the reactive boilerplate. Adding a checklist to something feels like an inherently imperative concern, so yes I'd like to see a single simple method on the service which you call to add a checklist. Pseudocode:
`public add = ( checklist: AddChecklist ) => this.storageService.checklists.add( this.convertToChecklist( checklist ) )`
To each his own, thanks for the reply!
@@shmert to elaborate a little on the "why" of this subject approach, the general idea is that all state is derived declaratively from data sources - but sometimes you do need to react to some imperative action, so this basically takes that imperative action and converts it into a new source of data, minimising the imperative aspect (rather than handling the operation imperatively)
🤑
Firestore
RxDB does touch upon the realm of Firestore and comparisons are relevant at some point (especially if you are planning to use Firestore as the backend) - but in cases like the one I demonstrated (i.e. I would basically just want more powerful/reactive local storage) then just installing RxDB seems the better option to me
I never learn something from this channel, adios!
You have to understand it first.