We're a place where coders share, stay up-to-date and grow their careers.
Hey Ivan , Thanks for your kind comment. Let me calmly clarify you certain things.
First of all, thanks a lot for taking time to drop a detailed comment, I really appreciate it. Let me talk about everything one by one.
I missed the meaning of private property part, I thought what he meant was to keep these properties private to your zone, I apologise for that.
The part about copying stuff from somewhere, I am pretty sure you copy stuff from articles / blogs too, as I don't think you are on the development team of Angular or something significant for that matter. (I gave the blog link for everyone to clarify their doubts). Also I said I solved the problem like this, and did not ADVICE anyone to use it, as far as I know there are no single solutions in engineering. You can chose to ignore the solutions you don't like.
Okay I might know what's going on here as I am still learning and also writing my first blog here, but I think you you're so intimidated because you definitely don't know anything what's going on here. I have read 10+ articles on ZoneJS, watched videos and read documentation, and I can certainly explain what is "forking the _inner zone" , we can discuss this off the comment section.
Private and undocumented things are not supposed to be used ??? Then I am sure you're well versed with ZoneJS documentation, please direct me to the place where this is mentioned that "DON'T use ZoneJS , it's a hidden feature made for internal use". ZONEJS is not a hack, just to clarify. It's available at 'angular/core'. I don't think I need to explain core to you.
Your solution with interceptors , let me give you a scenario. There are two arrays (A & B)of parallel API calls merged into an observable using lets say "forkJoin" in the same service. Both the arrays have one url which is same, I want to track the url from A and not from B, can interceptor handle that. Instead of suggesting solutions for how to make the message service work, try to fix this problem, which I am sure you did not get properly.
May be the ids solution is an overhead, I am sure I can do better there. You're right there.
About the component accepting messages array, loaderEmitter etc and whose purpose I did not mention. Again if you understood the point of the post you would not asked this question. I have written "/* Actual code removed for the sake of brevity. */" . That means something, that means the code is not important for this blog's perspective.
Okay lastly, broadcasting this.loaderMessages on the messageSubject is just plain wrong . I am so puzzled at this, obviously I know JS objects are passed by reference, and in fact I am using change detection strategy- onPush. Quick Angular tip for you, whenever you do that you use ngDoCheck not ngOnChanges. Also, the purpose of broadcasting the whole array was to do some calculation on all the subscribers as soon as it happens, as I haven't implemented ngDoCheck.
Again these are the things, which were just there to give you a glimpse of the working of the loader, which could have been implemented in 100 different ways. Commenting on that is just digressing from the topic.
I am so baffled that how people with no background information about the application, can judge and pass comments about the code. Also it's not an advice to follow this approach to achieve it, it's just me playing around with the code.
Hope this helps you understand things a little better and being little less hateful with your comments.
I clearly failed in not making my comment sound judgemental.
As much as you say you thank me and appreciate it, the sound of your answer ("I don't know if you can read English properly", "I only do educated debates", "before furiously tapping your keyboard") clearly shows you found it offensive.
I didn't mean that and I'm sincerely sorry if you found it "hateful".
You say you are not advising people to use your solution, but your post is literally titled "A short guide to understand ZoneJs and to solve a problem".
If your solution involves accessing private properties of Angular internals, it's a wrong solution.
You are free to think otherwise, but you are never supposed to access private properties. Of course you won't find any documentation saying you're not supposed to, since it's already taken for granted.
Even if you don't believe it's just wrong, you can find two valid pratical reasons not to do it in my previous comment.
And I really wonder if your code would compile in production.
You are right in saying I don't know the specifics of your project, but I don't agree that should hold me from commenting on that.
If you want to write a guide that says using undocumented features is better then using documented and standard ones, you should point out in which exact scenario this is true. If you hide it, it will sound like overcomplicating.
To answer your question about the Interceptor, I can't be more precise since as you say I don't know the details, but an idea could be adding params to the http query instructing the Interceptor on how to handle it. Or maybe using the Service to handle communication between what is running the query, the Interceptor and/or the Component.
Lastly, re-emitting the same object is always a bad practice. You are showing this in your code, then you're showing a bad practice. You might be doing something that you hide to force change detection, and I don't know what exactly, but that's because you are using a bad practice.
I don't want to force this on you, so you can take it as just a matter of personal preference.
Again, sorry if you found my comments offensive, I really didn't mean it.
For what it's worth, I sincerely like your writing and find it engaging, and that's why I read the whole article even if I was puzzled at the code.
If I criticized your code is because I like your style, and thought it would be better if you sticked on writing about documented code and good practices.
If I didn't like anything about your post, I sure would have ignored it, I didn't mean to write a destructive comment.
Hi Ivan ,
Sorry for lashing out , I edited my above comment with better phrases which do not sound offensive. I am certainly here to learn from everyone in the comment section . It's very hard not to take offense on the phrases you used like (You don't really know what's going on here, hocus pocus , etc). Could have easily been rephrased in a better way. In sounds to be destructive that way.
The title of the blog ("A short guide to understand ZoneJs and to solve a problem.") is subject to interpretations, I myself never just read one blog and implement anything. So it depends how you interpret it.
My code is compiled and deployed at at least 10 clients locations, including some big IT giants like Biocon, and even at organizations like ISRO etc. I don't want you to take it the wrong way, but please read a bit about ZoneJS, it's not much mysterious and cryptic. I can even refer you some good blogs. Because most of the things you say are wrong are just your opinions. Again, I mean no offense.
Also everything we discussing is kinda debatable except broadcasting an array, that can be done in a better way. The only thing I beg to differ is your interceptor approach in the current context. We can connect outside this comment section and discuss that if you like.
Sorry again for using those phrases, i should have handled it better.
Thanks , Cheers ! :)
thank you for accepting my goodwill and softening the tones.
As you edited your comment, I also edited my first one to clarify parts that indeed, now that you highlight them, could sound offensive.
I know that there are guides about ZoneJS, and you sure read a lot more than me about it, so you sure have a better picture than me. But those guides are not official, the official documentation is pretty scanty about it.
When I wrote "you don't really know what's going on" I didn't mean you don't know because of your lack of knowledge, I mean you (or me) don't know because there's no way to know (I now edited that part).
Even if people "reverse engineered" it and wrote guides, do they really know exactly when and how the _inner zone gets updated? Why should we fork the _inner one and not the _outer one? Has it always been consistent in all Angular versions? Why aren't we using the forkInnerZoneWithAngularBehavior() method instead? What does AngularBehavior even mean?
Of course I do copy code on an almost daily basis, but if I copy something from an unofficial source, something which is undocumented but only explained by the author to the best of his knowledge, I admit it indeed is hocus pocus. With which I mean something that just works that way because it does, and it's not guaranteed to work perfectly and forever to my needs. And if I wanted to change something about it I wouldn't know where exactly to look other than unofficial guides by people who write to the best of their knowledge.
I'm not saying it doesn't happen to me, but it's not a good practice, so if there's a documented and more conventional alternative I prefer it.
Also, given the rate that Angular introduces breaking changes in documented features, I wouldn't be surprised at all if they introduced them in an undocumented one (which as far as they know is only used in Angular itself). And of course the breaking changes would be undocumented themselves.
I believe you when you say you do use that code in production, but it honestly sounds weird that it doesn't throw compiling exceptions when accessing private properties, at least with Ivy.
Maybe I will try it out of curiosity when I get back to work (now I am on holiday, though it doesn't look like so;)).
Thank you again for helping me not escalating the argument, and keep on with your blogging. As I already wrote I like your style, it sure doesn't look like someone's first post in any negative way!
If you ask me why I don't write my own blog instead than criticizing your code, the answer is that I would do a terrible job, so it's better to leave it to you.
Maybe with more constructive and well worded comments from people:)
Hey Ivan ,
Thanks for taking high grounds man ! Let's do our bits to develop the community. Me with my poorly chosen codes XD and you with your constructive comments. :D
I will surely come up with a better / well researched blog on ZoneJS in future and definitely tag you there.
Again, thanks for all the compliments about my writing, I really appreciate it.
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.