Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Be careful when you go down the rabbit hole of creating custom observables (rxJS).
I wasted half a day just to find out that there are hot and cold observables and that the whole time I tried to use the wrong one.
It finally works. 01:00 in the morning.
My boss will be proud when he pulls the changes and the code looks completely fucked up (clean, well structured code, but he doesn't really know observables).
Now something different: Sleep. Cya. -
Angular is still a pile of steaming donkey shit in 2023 and whoever thinks the opposite is either a damn js hipster (you know, those types that put js in everything they do and that run like a fly on a lot of turds form one js framework to the next saying "hey you tried this cool framework, this will solve everything" everytime), or you don't understand anything about software developement.
I am a 14 year developer so don't even try to tell me you don't understand this so you complain.
I build every fucking thing imaginable. from firmware interfaces for high level languaces from C++, to RFID low level reading code, to full blown business level web apps (yes, unluckily even with js, and yes, even with Angular up to Angular15, Vue, React etc etc), barcode scanning and windows ce embedded systems, every flavour of sql and documental db, vectorial db code, tech assistance and help desk on every OS, every kind of .NET/C# flavour (Xamarin, CE, WPF, Net framework, net core, .NET 5-8 etc etc) and many more
Everytime, since I've put my hands on angularJs, up from angular 2, angular 8, and now angular 15 (the only 3 version I've touched) I'm always baffled on how bad and stupid that dumpster fire shit excuse of a framework is.
They added observables everywhere to look cool and it's not necessary.
They care about making it look "hey we use observables, we are coo, up to date and reactive!!11!!1!" and they can't even fix their shit with the change detection mechanism, a notorious shitty patchwork of bugs since earlier angular version.
They literally built a whole ecosystem of shitty hacks around it to make it work and it's 100x times complex than anything else comparable around. except maybe for vanilla js (fucking js).
I don't event want todig in in the shit pool that is their whole ecosystem of tooling (webpack, npm, ng-something, angular.json, package.json), they are just too ridiculous to even be mentioned.
Countless time I dwelled the humongous mazes of those unstable, unrealiable shitty files/tools that give more troubles than those that solve.
I am here again, building the nth business critical web portal in angular 16 (latest sack of purtrid shit they put out) and like Pink Floyd says "What we found, same old fears".
Nothing changed, it's the same unintelligible product of the mind of a total dumbass.
Fuck off js, I will not find peace until Brendan Eich dies of some agonizing illness or by my hands
I don't write many rants but this, I've been keeping it inside my chest for too long.
I fucking hate js and I want to open the head of js creator like the doom marine on berserk19 -
Every time I have to switch from backend development to frontend and deal with rxjs Observables, I feel like a spider crafting a web, so that no matter at which string the fly/event happens, the right other strings will be pulled and I will get a nice notification.
No wonder it's called WEB-development1 -
Angular dosent work as well in Firefox somehow...
The navigation is choppy, observables are slow.
I think anything to do with rxjs dosent work as well.
Chrome works great even on cell phones.8 -
I need some opinions on Rx and MVVM. Its being done in iOS, but I think its fairly general programming question.
The small team I joined is using Rx (I've never used it before) and I'm trying to learn and catch up to them. Looking at the code, I think there are thousands of lines of over-engineered code that could be done so much simpler. From a non Rx point of view, I think we are following some bad practises, from an Rx point of view the guys are saying this is what Rx needs to be. I'm trying to discuss this with them, but they are shooting me down saying I just don't know enough about Rx. Maybe thats true, maybe I just don't get it, but they aren't exactly explaining it, just telling me i'm wrong and they are right. I need another set of eyes on this to see if it is just me.
One of the main points is that there are many places where network errors shouldn't complete the observable (i.e. can't call onError), I understand this concept. I read a response from the RxSwift maintainers that said the way to handle this was to wrap your response type in a class with a generic type (e.g. Result<T>) that contained a property to denote a success or error and maybe an error message. This way errors (such as incorrect password) won't cause it to complete, everything goes through onNext and users can retry / go again, makes sense.
The guys are saying that this breaks Rx principals and MVVM. Instead we need separate observables for every type of response. So we have viewModels that contain:
- isSuccessObservable
- isErrorObservable
- isLoadingObservable
- isRefreshingObservable
- etc. (some have close to 10 different observables)
To me this is overkill to have so many streams all frequently only ever delivering 1 or none messages. I would have aimed for 1 observable, that returns an object holding properties for each of these things, and sending several messages. Is that not what streams are suppose to do? Then the local code can use filters as part of the subscriptions. The major benefit of having 1 is that it becomes easier to make it generic and abstract away, which brings us to point 2.
Currently, due to each viewModel having different numbers of observables and methods of different names (but effectively doing the same thing) the guys create a new custom protocol (equivalent of a java interface) for each viewModel with its N observables. The viewModel creates local variables of PublishSubject, BehavorSubject, Driver etc. Then it implements the procotol / interface and casts all the local's back as observables. e.g.
protocol CarViewModelType {
isSuccessObservable: Observable<Car>
isErrorObservable: Observable<String>
isLoadingObservable: Observable<Void>
}
class CarViewModel {
isSuccessSubject: PublishSubject<Car>
isErrorSubject: PublishSubject<String>
isLoadingSubject: PublishSubject<Void>
// other stuff
}
extension CarViewModel: CarViewModelType {
isSuccessObservable {
return isSuccessSubject.asObservable()
}
isErrorObservable {
return isSuccessSubject.asObservable()
}
isLoadingObservable {
return isSuccessSubject.asObservable()
}
}
This has to be created by hand, for every viewModel, of which there is one for every screen and there is 40+ screens. This same structure is copy / pasted into every viewModel. As mentioned above I would like to make this all generic. Have a generic protocol for all viewModels to define 1 Observable, 1 local variable of generic type and handle the cast back automatically. The method to trigger all the business logic could also have its name standardised ("load", "fetch", "processData" etc.). Maybe we could also figure out a few other bits too. This would remove a lot of code, as well as making the code more readable (less messy), and make unit testing much easier. While it could never do everything automatically we could test the basic responses of each viewModel and have at least some testing done by default and not have everything be very boilerplate-y and copy / paste nature.
The guys think that subscribing to isSuccess and / or isError is perfect Rx + MVVM. But for some reason subscribing to status.filter(success) or status.filter(!success) is a sin of unimaginable proportions. Also the idea of multiple buttons and events all "reacting" to the same method named e.g. "load", is bad Rx (why if they all need to do the same thing?)
My thoughts on this are:
- To me its indentical in meaning and architecture, one way is just significantly less code.
- Lets say I agree its not textbook, is it not worth bending the rules to reduce code.
- We are already breaking the rules of MVVM to introduce coordinators (which I hate, as they are adding even more unnecessary code), so why is breaking it to reduce code such a no no.
Any thoughts on the above? Am I way off the mark or is this classic Rx?16 -
So you're telling me that you have no documentation, and your app business logic is made on only observables?
Uh no thanks. -
Colleague's thought process:
Hmm I have observables but I don't understand shit.
Hey I like listeners let's add listeners to all observables.
Should I make the method return an observable and subscribe my listener to it?
Nah I'll erase everything and pass an anonymous class listener to the method so no one can chain a few calls together.
Fuck you and I hope you're reading this!!!
Time to rerewrite 2k lines of fucking code.... -
Can you give me some tips on how to debug a massive app? (Android app running on android studio which is basically intellij idea).
For example I need to fix a bug where a certain action results in unexpected behaviour.
But oh my god the codebase is so large (mainly architecture is MVVM and rxjava) that searching for the specific place is like searching for a needle in haystack.
For example I added a breakpoint in few places, but I can see only like 4 or 5 last frames in the stack that led to the current action, last frame is a lambda which doesnt help me so frankly Im unable to even track where current event started. I am loosing my mind. I cant even find where the buttonclick action started because everything is reactive and done with observables which can be anywhere.
Any tips on debugging will be appreciated7 -
A follow up to the last rant.
Trying to get that angular working with my rest api. But frickin observables and promises. I built my angular based on the official tutorial from the angular website. Sadly that tutorial uses promises, which aren't that suited for communicating with an api. So now I'm learning/implementing observables into the angular.
BUT I'M GETTING SO MUCH ERRORS. CONFUSION IS RISING.
I need more coffee to do this. :/3 -
Since I can't get my user stories today, I started on trying getting my angular frontend to communicate with my symfony backend. I now feel like I need a lot of climbing gear, because I get the feeling I went too deep into the rabbit hole.
getting quite confused with Observables and promises.1 -
So.. in the AngularJS we had Promises and Deferred objects and in Angular we have RxJS and Observables and Subjects... and I spent last few hours googling for something like "deferred equivalent in angular" with no useful result at all, because, well, "Subject" is not the first damn thing to come to mind when looking for "Deferred" synonyms.. who the hell is making up these names?
It's like "well, since this is a new framework, it should also have completely different(and unrelated) names, so that it does not resemble the old one at all".2 -
A RxJS wrapper for MySQL queries.
https://github.com/inf3cti0n95/...
If anyone has any suggestions/reviews for it.1 -
Why does it take so much effort to do a very simple thing in angular?
Here I am trying to create an observable that listens to two observables from parent and child. I have to subscribe to observable in parent and then convert @input value back to observable. Fuck angular
https://stackblitz.com/edit/...4 -
How can you build an oidc library almost completely on observables? Cannot complain about it, as it's open source, but what if you want to access some token data synchronously?4
Top Tags
Weekly Rant
View