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.
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.