Navigate back to the homepage

Source code snippets, quirks and features

Tomasz Waszczyk
July 25th, 2020 · 2 min read


function in object

1const obj = {
2 value: 'some value',
3 method() { return this.value; }
5obj.method(); // "some value"
7const x = obj.method;
8x(); // undefined


1tsc --watch //watch mode

Logical nullish assignment

1function myFn(variable1, variable2) {
2 variable2 ??= "default value"
3 return variable1 + variable2
6myFn("this has", " no default value") //returns "this has no default value"
7myFn("this has no") //returns "this has no default value"
8myFn("this has no", 0) //returns "this has no 0"

The assignment operator allows us to check for the value of variable2 and if it evaluates to either null or undefined then the assignment will go through, otherwise it will never happen.

Warning: this syntax can be confusing to others that aren’t familiar with this operator, so if you’re using it you might as well leave a one-line comment explaining what’s happening.


TL;DR: You want a HOT observable when you don’t want to create your producer over and over again.

1// COLD
2var cold = new Observable((observer) => {
3 var producer = new Producer();
4 // have observer listen to producer here

HOT is when your observable closes over the producer

1// HOT
2var producer = new Producer();
3var hot = new Observable((observer) => {
4 // have observer listen to producer here

Comparing promise’s then to observable’s subscribe, showing differences in eager vs lazy execution, showing cancellation and reuse of observables, etc. It’s a handy way to introduce beginners to observables.

There’s one problem: Observables are more different from promises than they are similar. Promises are always multicast. Promise resolution and rejection is always async. When people approach observables as though they’re similar to a promises, they expect these things, but they’re not always true. Observables are sometimes multicast. Observables are usually async. I blame myself a little, I’ve helped perpetuate this misunderstanding.

Observable is just a function that takes an observer and returns a function

If you really want to understand observable, you could simply write one. It’s not as hard as it sounds, honestly. An observable, boiled down to it’s smallest parts, is no more than a specific type of function with a specific purpose.


  • A function that accepts an observer: An object with next, error and complete methods on it.
  • And returns a cancellation function


To connect the observer to something that produces values (a producer), and return a means to tear down that connection to the producer. The observer is really a registry of handlers that can be pushed values over time.

1// simple implementation of observable
2function myObservable(observer) {
3 const datasource = new DataSource();
4 datasource.ondata = (e) =>;
5 datasource.onerror = (err) => observer.error(err);
6 datasource.oncomplete = () => observer.complete();
7 return () => {
8 datasource.destroy();
9 };



An Observable is a data stream that houses data that can be passed through different threads. In our demo app, we’ll be using an Observable to supply data to our different components.


An Observer consumes the data supplied by an Observable. In our demo app, we’ll be using our setState Hook to consume data from our Observable.


In order for our Observer to consume data from our Observable, we’ll have to subscribe it to the Observable. In our demo app, we’ll be using the subscribe() method to subscribe our setState Observer to our Observable.
















More articles from

Dive into Rust in Substrate way or dive into Substrate in Rusty way!

Rust has been Stack Overflow's most loved programming language for four years in a row, indicating that many of those who have had the…

July 24th, 2020 · 2 min read

The Past and Future of Digital Assets

Past and future of digital assets

July 24th, 2020 · 18 min read
© 2020
Link to $ to $ to $ to $