Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
There are others who do have these problems. Because one individual does not have a problem does not mean a problem does not exist. A quick search on stack overflow will show a lot of people have difficulties understanding this.
this is a complicated concept to grasp and I'm sure there is room for improvement in its design; however, it is not broken and especially not broken to the point where we need wrapper libraries to unbind contexts. Arrow functions were created to pass the parent context (this of the parent) into child scopes.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
I do not know a single developer that hasn't had to debug a this problem by writing console.log(this). It is not accepted that as a JavaScript developer, at some point you will have to debug `this.
Duh! Ofcourse you will. Just like with any other code that you're not sure about YET. Then as you debug it to get an insight, to see what this points to you'll ask yourself - wait a second how did that happened? Does that mean... OOOH! And then the spoon bends, the matrix code appears and you get it. And that my friend is one of the big pleasures of working with your head.
It aint broken. Case closed.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
What is the purpose of trying to access this.event on the 5th line? If this.event was a value declared in the parent scope, the fat arrow would actually save you. The implication of using EventEmitter2 would be so that you can access arguments from the callback of the events.on method (ie. args passed inside the callback).
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
So you can use the arrow function to get access to the parent context and still access the element you have attached the listener to... Please don't stop using this just because you don't know how a lib works.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
The funny thing is, I think you were trying to use this argument to show how silly it is to remove this. But a lot of people are seriously proposing total gun bans for this exact reason, accidental shootings. It's almost as if your statement can be interpreted as in agreement with the article...
And banning guns will prevent a significant number of accidental gun deaths.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
I see developers stumble on this. It's part of every developer interview process. Do they understand this?
In a functional reactive program, you won't find any instance of this. But there are times when code is outside of your control. For example when you have to use a 3rd party library. So you can never be truly free.
But your question should not be ** Why are you falling into the traps of this then?** it should be ** Why do JavaScript developers fall into the traps of this?** To which you will have to google and search stack overflow to understand the complexity of why people don't fully understand this.
you already have autobind(this) as a utility in react to prevent losing this context on event handlers which solves this issue in an easy and intuitive way without the need to bind everything manually.
i think your project is a nice idea considering how creative you got about solving that personal problem you got with this but on the other hand i think this is way to confusing to introduce in productive code bases.
handling this in js is not quite intuitive in some cases but there are only 2 - 3 tricky parts you gotta learn and this should be no problem at all.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
autobind is a good tool too. It was created to solve one the problems with this.
There are always easy ways to work with this. But you will always run into bugs with it. I am just trying to imagine a world where you never have bugs with this because this doesn't exist.
I have created a project to demonstrate how easy it can be to use React without this here: npmjs.com/package/nothis-react
I had face a bad time debugging working with React, when the error was just forgot to bind this, but nothing really bad. But with TypeScript works the same way? Working with TS never had any problem.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
TypeScript is awesome. It definitely helps with this issues. The big problem of this in plain JavaScript is that you can never be sure what it really is. And your code may work differently based on how other people use it.
These two pieces of code could yield different results because this becomes unintentionally rebound to a different context.
constcat={sound:'meow',speak:function(){returnthis.sound;}}constlogSound1=animal=>console.log(animal.speak())constlogSound2=({speak})=>console.log(speak())logSound1(cat)//=> "meow"logSound2(cat)//=> Cannot read property 'sound' of undefined.
So instead of worrying about what this is all the time, let's just get rid of this completely and we never have to guess again.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
So, is there any other options to avoid using this, that are native to JS? I know one of the quickest ways is var self = this, but not about anything that do not involves a variable. And one of your past comments, wake up my curiosity, if TypeScript is a superset of JS, what it does to work aroun with this issues?
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Although I can see what you are pointing, what is difficult, is to find the best way to avoid using this in a real application. Thanks a lot, this has been one of the most significant discussion this year.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
That is because you have been taught to use this. With OOP, you are pretty much stuck with this (unless of course you use nothis). When you learn functional reactive programming, you'll find this to no longer be necessary and magically this just vanishes from your codebase.
If you use typescript and modify the cat speak code to use an explicit if, you get a compile error.
constcat={sound:'meow',speak(this:{sound:string}){returnthis.sound}}constspeak=cat.speakspeak()// <= Compile error: void is not assignable to { sound: string }.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Not everyone does. I really think this is not an issue with this but an issue with people who insist on trying to write JS in an OOP style, perhaps because they came from an OOP background. The problem basically goes away when you use JS in a functional way, i.e. stop writing code which is called like animal.speak().
I don't think it's too hard to still use this in the contexts where it's required by libraries without shooting yourself in the foot, and at the same time eliminate it from your own code.
As mentioned by others, your invalid React code is really just an example of not understanding how the language works, and I don't think abstracting that away is a good solution.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Not everyone does. I really think this is not an issue with this but an issue with people who insist on trying to write JS in an OOP style, perhaps because they came from an OOP background. The problem basically goes away when you use JS in a functional way, i.e. stop writing code which is called like animal.speak().
^ THIS. This is the true solution. Write your software in a way that doesn't require the use of this ever.
But there are many people that come from OOP and want JavaScript to be OOP. I have been trying to convince people to write functional code for a while now. But I still receive the "HOW DARE YOU" responses. OOPers gonna OOP.
I just hope they think of me every time they write console.log(this) :)
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Which is A LOT of people! I'm not fabricating problems out of mid air. A very large number of people do have issues with this. You can tell by the number of articles written explaining the concept. The number of questions asked on stack overflow. Every JavaScript interview will include questions to see if you understand what this is.
It's a complicated subject for a lot of developers. I do not know a single developer that hasn't written console.log(this) at some point in their careers.
The problem with this cannot be simplified into "that's just how scope works".
This code is a good example of that. By simply using a destructured argument, the scope is unexpectedly changed.
So because it's something that people have to learn, that means it's a problem? No.
Arrow functions are designed to preserve scope. That's what they exist for. There is nothing "surprising" about them. Just people that haven't actually learned the language
YOU DONT DESIGN CODE AROUND "DEVELOPERS" THAT DONT UNDERSTAND THE LANGUAGE.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
If it's something that a majority of developers stumble on, then yes it's a problem.
Much in the same way NULL has been described as the Billion dollar mistake. NULL is a MUCH more simple concept to grasp than this. Yet now because we decide to use null, we have introduced an entire class of bugs into our application. All those lovely NullReferenceException bugs.
It doesn't matter how good of a programmer you are, YOU WILL run into NullReferenceException bugs.
Of course, there are ways to program without NULL. And this would eliminate that entire class of bug from your application. But we don't (myself included).
If we can program in a way that can completely eliminate entire classes of bugs, why would we choose not do to so?
I get how it could trip up someone new to js, but that's what makes this a method and not just any old function.
Do you suggest replacing all classes with object factory functions?
Sure, s.speak is already bound.
Sure, memory and even code cache difference can be negligible when you don't instantiate even a thousand of these objects.
But what meaning does const {speak} = s have as a freestanding function?
Should we have it a static function and not a closure and take a state POJO instead: speak(s)?
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
I'll disagree with this statement. null is a much easier concept to understand when compared to this. Yet null is now currently considered to be the Billion dollar mistake or "The worst mistake in computer science".
We all understand null and we understand it very well. Yet we are forever doomed to run into random NullReferenceException errors. Even though we fully understand and comprehend null, you can never guarantee you will not run into those bugs.
So to assume problems with this are limited to Junior developers, I would say is an Optimism Bias.
Do you suggest replacing all classes with object factory functions?
In my perfect world, Objects and behavior would be disconnected. So you would never have a function and data combined together. We would have Categories and Morphisms (transformations) and immutability.
And instead of encapsulating the state of a resource beyond our control in an object? IO monad?
How would you handle a WebSocket, a File handle, and such?
null is terrible. It shifts the job of knowing whether a function might return zero instead of one expected result to to the caller. And in JS we have two different nulls 👌
TypeScript with strictNullChecks begins to solve this, but there's the risk that something external claiming to return one concrete value might return a nullish value at runtime.
this is quite different. There's a couple of rules, and once you get them it works perfectly:
In arrow functions, this isn't special it's just the binding from the enclosing scope. (undefined if that's nothing)
In all other functions, including the object method shorthand on an object literal or a class, it's the enclosing object (undefined if that's nothing)
Function.protptype.{bind|call|apply} first get the function, so it can't possibly be a method any more, so you get to provide your own this
A binded function forever loses those arguments, just like you can't rebind a curried function's argument you can't rebind this. All it really does is
There are many ways properties are different from scope bindings.
For example, one would not expect
consta={b:1}a.b++console.log(a)
To have the same result as
consta={b:1}let{b}=ab++console.log(a)
Or consider getters and other capabilities of Object.defineProperty()
Treating properties and bindings with the same expectations is a very novice thing in the context of JS.
On the other hand in this beginner period I can definitely appreciate, for example when using ES6 classes, that the methods would be forever bound to the newed object.
But once you see what that desugars to, one stops thinking that.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
I'm am perplexed by your ability to understand the complexities of null and at the same time miss the complexities of a more simple concept being this.
What's the advantage of pointfree propEq usage? Isn't that less immediately readable than x=>x.type==='match'?
I feel like passing key names around in strings is strictly worse and should be avoided whenever it can. So much so, that if you have to use index notation on a non-Array object because your name is truly dynamic, you should actually be using an ES6 Map instead.
I can see the top Event, message, has an excuse to use Observable to filter, but why is
Most importantly, how do you clean up the observables when the websocket closes? It seems that the websocket object and the three observables will never be collected, and a new call to default would just make a new one in parallel.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
I just got into the habbit of using it. I can go either way on this one. The advantage is when you use something like path(['one', 'two', 'three']) instead of obj && obj.one && obj.one.two && obj.one.two.three so prop and propEq are similar which is why I used them.
I can see the top Event, message, has an excuse to use Observable to filter, but why is
Just for consistency again. So all "subscriptions" have the same interface. Again, I could have gone either way.
Most importantly, how do you clean up the observables when the websocket closes?
If I remember correctly, I am handling this by exiting the app completely. I have another process that restarts it. I had some issues with closing / reopening some websockets and this app wasn't critical to stay open, so I hard exit.
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.
In my short experiencie with JavaScript, had never faced an issue while working with
this
. What is so bad about it?Don't worry, you will. Everyone does ;)
Check out this example:
You will also frequently run into problems with
this
when working with React.I have a few other examples on the github page github.com/joelnet/nothis
Those aren't problems to me, that's just not knowing how the language works. I don't mean to sound terse, but it's just never been an issue for me.
Exactly.
There are others who do have these problems. Because one individual does not have a problem does not mean a problem does not exist. A quick search on stack overflow will show a lot of people have difficulties understanding
this
.I don't think understanding
this
is not that hard.Besides, properly understand a language is a basic requirement to program in that language.
this
is a complicated concept to grasp and I'm sure there is room for improvement in its design; however, it is not broken and especially not broken to the point where we need wrapper libraries to unbind contexts. Arrow functions were created to pass the parent context (this
of the parent) into child scopes."Having difficulties" is part of learning process. That's how you grow.
I do not know a single developer that hasn't had to debug a
this
problem by writingconsole.log(this)
. It is not accepted that as a JavaScript developer, at some point you will have to debug `this.it doesn't have to be
Duh! Ofcourse you will. Just like with any other code that you're not sure about YET. Then as you debug it to get an insight, to see what
this
points to you'll ask yourself - wait a second how did that happened? Does that mean... OOOH! And then the spoon bends, the matrix code appears and you get it. And that my friend is one of the big pleasures of working with your head.It aint broken. Case closed.
Just FYI, saying case closed doesn't close the case.
You don't have to use the library. But please remember to think of me the next time you write
console.log(this)
.Arrow functions solve ONE of the problems with
this
.Here's a reference to
this
that you can't arrow function your way out of.nothis
also does more than removethis
. It lets you use arrow functions and also argument destructuring. Both of which are not options otherwise.What is the purpose of trying to access
this.event
on the 5th line? Ifthis.event
was a value declared in the parent scope, the fat arrow would actually save you. The implication of usingEventEmitter2
would be so that you can access arguments from the callback of theevents.on
method (ie. args passed inside the callback).The code is correct. This is how their API is written. I need the
this
from thefunction
inside theevents.on
method, not the parent scope.It works the same way jQuery's
this
context works here:You can't write an arrow function for these.
Actually,
jQuery
calls the callback of theelement
'sthis
passed into it viaapply
andcall
. Check it out: code.jquery.com/jquery-3.3.1.jsIn jquerys events
this
is the same asevent.delegateTarget
: api.jquery.com/event.delegateTarget/So you can use the arrow function to get access to the parent context and still access the element you have attached the listener to... Please don't stop using
this
just because you don't know how a lib works.A total gun ban also may prevent you from shooting yourself in the foot.
The funny thing is, I think you were trying to use this argument to show how silly it is to remove
this
. But a lot of people are seriously proposing total gun bans for this exact reason, accidental shootings. It's almost as if your statement can be interpreted as in agreement with the article...And banning guns will prevent a significant number of accidental gun deaths.
It looks like you know what you are doing in the
github.com/joelnet/nothis
package. Why are you falling into the traps ofthis
then?I see developers stumble on
this
. It's part of every developer interview process. Do they understand this?In a functional reactive program, you won't find any instance of this. But there are times when code is outside of your control. For example when you have to use a 3rd party library. So you can never be truly free.
But your question should not be ** Why are you falling into the traps of this then?** it should be ** Why do JavaScript developers fall into the traps of this?** To which you will have to google and search stack overflow to understand the complexity of why people don't fully understand
this
.you already have autobind(this) as a utility in react to prevent losing this context on event handlers which solves this issue in an easy and intuitive way without the need to bind everything manually.
i think your project is a nice idea considering how creative you got about solving that personal problem you got with this but on the other hand i think this is way to confusing to introduce in productive code bases.
handling this in js is not quite intuitive in some cases but there are only 2 - 3 tricky parts you gotta learn and this should be no problem at all.
autobind is a good tool too. It was created to solve one the problems with
this
.There are always easy ways to work with
this
. But you will always run into bugs with it. I am just trying to imagine a world where you never have bugs withthis
becausethis
doesn't exist.I have created a project to demonstrate how easy it can be to use React without
this
here: npmjs.com/package/nothis-reactI had face a bad time debugging working with React, when the error was just forgot to bind
this
, but nothing really bad. But with TypeScript works the same way? Working with TS never had any problem.TypeScript is awesome. It definitely helps with
this
issues. The big problem of this in plain JavaScript is that you can never be sure what it really is. And your code may work differently based on how other people use it.These two pieces of code could yield different results because
this
becomes unintentionally rebound to a different context.So instead of worrying about what
this
is all the time, let's just get rid ofthis
completely and we never have to guess again.Oh, thanks for taking the time, to explain to me, to make it pretty clear. I used to think, problem was just about scope.
It is actually. it's just that your scope can change when you do not expect it to change.
So, is there any other options to avoid using this, that are native to JS? I know one of the quickest ways is
var self = this
, but not about anything that do not involves a variable. And one of your past comments, wake up my curiosity, if TypeScript is a superset of JS, what it does to work aroun withthis
issues?TypeScript doesn't fix all
this
issues.If you check out the REPL at typescriptlang.org/play/ and enter this code:
You'll find it still has problems with
this
.My solution to avoiding this is to write JavaScript functionally and not to mix data and functions together into classes.
I would instead write the above like this:
Although I can see what you are pointing, what is difficult, is to find the best way to avoid using
this
in a real application. Thanks a lot, this has been one of the most significant discussion this year.That is because you have been taught to use
this
. With OOP, you are pretty much stuck withthis
(unless of course you usenothis
). When you learn functional reactive programming, you'll findthis
to no longer be necessary and magicallythis
just vanishes from your codebase.Check out one of my projects here github.com/joelnet/bitcoin-all-tim.... This is a real world application. It follows what I preach from How I rediscovered my love for JavaScript after throwing 90% of it in the trash.
You won't find any references to
this
,var
,let
,if
,switch
,for
, thefunction
keyword or other staples of classic javascript programs.If you use typescript and modify the cat speak code to use an explicit if, you get a compile error.
It's pretty nice that this will happen at compile time and not runtime.
Not everyone does. I really think this is not an issue with
this
but an issue with people who insist on trying to write JS in an OOP style, perhaps because they came from an OOP background. The problem basically goes away when you use JS in a functional way, i.e. stop writing code which is called likeanimal.speak()
.I don't think it's too hard to still use
this
in the contexts where it's required by libraries without shooting yourself in the foot, and at the same time eliminate it from your own code.As mentioned by others, your invalid React code is really just an example of not understanding how the language works, and I don't think abstracting that away is a good solution.
^ THIS. This is the true solution. Write your software in a way that doesn't require the use of
this
ever.But there are many people that come from OOP and want JavaScript to be OOP. I have been trying to convince people to write functional code for a while now. But I still receive the "HOW DARE YOU" responses. OOPers gonna OOP.
I just hope they think of me every time they write
console.log(this)
:)Cheers!
No, not "everyone does". People who don't understand the language do. There is only an issue with
this
when you aren't aware of how scope worksPrecisely.
Which is A LOT of people! I'm not fabricating problems out of mid air. A very large number of people do have issues with
this
. You can tell by the number of articles written explaining the concept. The number of questions asked on stack overflow. Every JavaScript interview will include questions to see if you understand whatthis
is.It's a complicated subject for a lot of developers. I do not know a single developer that hasn't written
console.log(this)
at some point in their careers.The problem with
this
cannot be simplified into "that's just how scope works".This code is a good example of that. By simply using a destructured argument, the scope is unexpectedly changed.
The reason why this happens is explained when you fully understand
this
. But to many developers they will stumble onthis
. Just search stack overflow.So because it's something that people have to learn, that means it's a problem? No.
Arrow functions are designed to preserve scope. That's what they exist for. There is nothing "surprising" about them. Just people that haven't actually learned the language
YOU DONT DESIGN CODE AROUND "DEVELOPERS" THAT DONT UNDERSTAND THE LANGUAGE.
If it's something that a majority of developers stumble on, then yes it's a problem.
Much in the same way NULL has been described as the Billion dollar mistake. NULL is a MUCH more simple concept to grasp than
this
. Yet now because we decide to use null, we have introduced an entire class of bugs into our application. All those lovelyNullReferenceException
bugs.It doesn't matter how good of a programmer you are, YOU WILL run into
NullReferenceException
bugs.Of course, there are ways to program without NULL. And this would eliminate that entire class of bug from your application. But we don't (myself included).
If we can program in a way that can completely eliminate entire classes of bugs, why would we choose not do to so?
I get how it could trip up someone new to js, but that's what makes this a method and not just any old function.
Do you suggest replacing all classes with object factory functions?
Sure, s.speak is already bound.
Sure, memory and even code cache difference can be negligible when you don't instantiate even a thousand of these objects.
But what meaning does
const {speak} = s
have as a freestanding function?Should we have it a static function and not a closure and take a state POJO instead:
speak(s)
?I'll disagree with this statement.
null
is a much easier concept to understand when compared tothis
. Yetnull
is now currently considered to be the Billion dollar mistake or "The worst mistake in computer science".We all understand
null
and we understand it very well. Yet we are forever doomed to run into randomNullReferenceException
errors. Even though we fully understand and comprehendnull
, you can never guarantee you will not run into those bugs.So to assume problems with
this
are limited to Junior developers, I would say is an Optimism Bias.In my perfect world, Objects and behavior would be disconnected. So you would never have a function and data combined together. We would have Categories and Morphisms (transformations) and immutability.
Then the world becomes simplified:
And instead of encapsulating the state of a resource beyond our control in an object? IO monad?
How would you handle a
WebSocket
, aFile
handle, and such?null
is terrible. It shifts the job of knowing whether a function might return zero instead of one expected result to to the caller. And in JS we have two different nulls 👌TypeScript with
strictNullChecks
begins to solve this, but there's the risk that something external claiming to return one concrete value might return a nullish value at runtime.this
is quite different. There's a couple of rules, and once you get them it works perfectly:this
isn't special it's just the binding from the enclosing scope. (undefined
if that's nothing)undefined
if that's nothing)Function.protptype.{bind|call|apply}
firstget
the function, so it can't possibly be a method any more, so you get to provide your ownthis
bind
ed function forever loses those arguments, just like you can't rebind a curried function's argument you can't rebindthis
. All it really does isNo one could possibly be overwhelmed by this.
There are many ways properties are different from scope bindings.
For example, one would not expect
To have the same result as
Or consider getters and other capabilities of
Object.defineProperty()
Treating properties and bindings with the same expectations is a very novice thing in the context of JS.
On the other hand in this beginner period I can definitely appreciate, for example when using ES6 classes, that the methods would be forever bound to the
new
ed object.But once you see what that desugars to, one stops thinking that.
Probably a combination of event emitters and rxjs.
Check out a project of mine here where I use these techniques: github.com/joelnet/bitcoin-all-tim...
On this page you can see how I consume a WebSocket: github.com/joelnet/bitcoin-all-tim...
I'm am perplexed by your ability to understand the complexities of
null
and at the same time miss the complexities of a more simple concept beingthis
.What's the advantage of pointfree
propEq
usage? Isn't that less immediately readable thanx=>x.type==='match'
?I feel like passing key names around in strings is strictly worse and should be avoided whenever it can. So much so, that if you have to use index notation on a non-Array object because your name is truly dynamic, you should actually be using an ES6
Map
instead.I can see the top Event,
message
, has an excuse to useObservable
tofilter
, but why isnot just
And such?
Most importantly, how do you clean up the observables when the websocket closes? It seems that the
websocket
object and the three observables will never be collected, and a new call todefault
would just make a new one in parallel.I just got into the habbit of using it. I can go either way on this one. The advantage is when you use something like
path(['one', 'two', 'three'])
instead ofobj && obj.one && obj.one.two && obj.one.two.three
soprop
andpropEq
are similar which is why I used them.Just for consistency again. So all "subscriptions" have the same interface. Again, I could have gone either way.
If I remember correctly, I am handling this by exiting the app completely. I have another process that restarts it. I had some issues with closing / reopening some websockets and this app wasn't critical to stay open, so I hard exit.