Forem: Jokerwolf

📄 Switch off

Jokerwolf — Sun, 11 Jul 2021 10:56:04 +0000

I have this personal preference to avoid if-else's and switch's whenever possible.
As you most likely already know, each case in a switch is evaluated consequently to determine if this is the case (pun intended).
Check an example bellow. We're using functions as case expressions just to have some logs.
Try passing different values to the whatsThis function and try guessing the console output before actually running the code.

If for example you pass 1, only the first case would be evaluated and the output would be:

Is this a 1?
It is 1!

If you pass 10 - all the cases would be evaluated.
Now imagine having tens of cases to evaluate. Your code would have an O(n) complexity at least (where n is the number of cases).

How can we change this code? The most straight forward approach could be using an object literal.
Here is an example. You can see that object literal variant is faster.

Conclusion

switch is a great feature of the language. I find it useful when working with small _enum_s in TypeScript at times when I would need same return for different keys, but as a personal rule I'd start with an object literal.

📗 Object Behavioural: Strategy

Jokerwolf — Sat, 10 Jul 2021 09:28:13 +0000

TL;DR;

Use this pattern if you have multiple similar classes, which differ in some logic implementation; your code contains if-else's to determine a proper algorithm to use.
Second pattern in a row targets to eliminate if-else's where possible - nice.

Definition

Strategy pattern allows separating algorithms from the clients using them.

Here is a formal diagram:

We have an object of type Context, which holds a reference to an IStrategy object. Context passes some work to this IStrategy object.

Sounds pretty much the same as State Pattern, but the strategy is set once at the Context instantiating time (while state is changing after Context is instantiated).

Implementation

Let's write some code.
We still have a Player, but this time we're more interested in its codecs.
So we would end up with something like this:

export default class Player {
  private paramA: number;
  private paramB: number;
  private paramC: number;

  constructor(private codecType: AlgorithmType, private stream: Stream) {
    // Setting up params
  }

  play() {
    const algorithm = this.getAlgorithm();

    switch (algorithm) {
      case 'A':
        this.decodeA();
        break;
      case 'B':
        this.decodeB();
        break;
      case 'C':
        this.decodeC();
        break;
    }

    console.log('>>>> Play');
  }

  private getAlgorithm(): AlgorithmType {
    // Some logic happens here to determine appropriate algorithm.
    return this.codecType;
  }

  private decodeA(): Stream {
    // Actual algorithm to decode the stream in some way
    console.log('>>>> Decoding with A', this.paramA);
    return this.stream;
  }

  private decodeB(): Stream {
    // Actual algorithm to decode the stream in some way
    console.log('>>>> Decoding with B', this.paramB);
    return this.stream;
  }

  private decodeC(): Stream {
    // Actual algorithm to decode the stream in some way
    console.log('>>>> Decoding with C', this.paramC);
    return this.stream;
  }
}

We have all different ways of decoding a stream inside the Player class. We have a switch statement to determine which particular algorithm we should use. Not that bad right now, but imagine a real life situation where decode functions could contain tens of lines of code.

What Strategy suggests is:

create an interface to describe the strategy class
move each decoding algorithm into a standalone strategy class
add a reference to the particular instance to you Player

Well, let's do all these with one small change: let's not create a class for each algorithm. Look at this:

interface Strategy {
  decode(stream: Stream, context: DecodeContext): Stream;
}

class StrategyA implements Strategy {
  decode(stream: Stream, context: DecodeContext) {
    // implementation
  }
}

We're in the TypeScript (JavaScript) world, functions are the first class citizens, we can pass them everywhere, we don't need to create a class just to have one function in it.

So this is what our pattern implementation might look like:

export default class Player {
  private paramA: number;
  private paramB: number;
  private paramC: number;

  constructor(private decode: Decode, private stream: Stream) {
    // Setting up params
  }

  play() {
    this.decode(this.stream, {
      a: this.paramA,
      b: this.paramB,
      c: this.paramC,
    });
    console.log('>>>> Play');
  }
}

And all decoding algorithms now live in their own functions:

export const decodeA: Decode = (stream: Stream, { a }: DecodeContext) => {
  // Actual algorithm to decode the stream in some way
  console.log('>>>> Decoding with A', a);
  return stream;
};

export const decodeB: Decode = (stream: Stream, { b }: DecodeContext) => {
  // Actual algorithm to decode the stream in some way
  console.log('>>>> Decoding with B', b);
  return stream;
};

export const decodeC: Decode = (stream: Stream, { c }: DecodeContext) => {
  // Actual algorithm to decode the stream in some way
  console.log('>>>> Decoding with C', c);
  return stream;
};

What will it cost?

Potential Cons:

We might increase the number of files, which some might consider a bad thing
As we define the Decode interface for every algorithm we're passing all the params each algorithm might need. Less then ideal

Potential Pros:

We got rid of the switch statement
We separated concerns by moving algorithms implementations outside the Player class

Conclusion

I do like separating concerns and avoiding conditionals when possible, so this pattern seems really useful to me so far.

Hope this was a bit helpful 🙃
Source code if needed

📗 Object Behavioural: State

Jokerwolf — Mon, 21 Jun 2021 14:56:50 +0000

Pre-face:

I was reading about design patters here and there, but it's finally the time to systemise them a bit.

So I started reading this great book: Design Patterns: Elements of Reusable Object-Oriented Software.

And as usual I'm remembering better if I'm writing it down.

TL;DR;

Use this pattern if you have lots of if-else's, your object needs to change its behaviour cause it's state changed, your object's state consists of multiple pieces which need to be checked often.

Definition

State design pattern allows an object to alter its behaviour when its state changes.

Here is a formal diagram:

We have an object of type Context. It holds a reference to a state object of type IState. There are multiple implementations of IState - StateA, StateB, etc.

Context talks to the outside world and passes calls to the IState implementation it currently holds.

Concrete type of IState changes when Context's state changes.

Implementation

Let's try to write some code now.

Imagine having a Player object, which does what players do:

play
stop
forward
rewind

class Player {
  // Omitting constructor code

  play(): void {}
  stop(): void {}
  forward(): void {}
  rewind(): void {}
}

Let's start with implementing play and stop methods. When we 'push the button' we want to track time when this happened and of course let's log this into a console.

class Player {
  // Omitting constructor code

  play(): void {
    this.time = Date.now();
    console.log(`>>>> Time: ${this.time}`);
  }
  stop(): void {
    this.time = Date.now();
    console.log(`>>>> Time: ${this.time}`);
  }

  forward(): void {}
  rewind(): void {}
}

Ok, we're seeing some code duplication, but let's continue for now. In real life you can't 'push the same button' twice, right? Let's add some checks.

class Player {
  // Omitting constructor code

  play(): void {
    if (!this.isPlaying) {
      this.time = Date.now();
      this.isPlaying = true;
      this.isStopped = false;
      console.log(`>>>> Time: ${this.time}`);
    }
  }
  stop(): void {
    if (!this.isStopped) {
      this.time = Date.now();
      this.isStopped = true;
      this.isPlaying = false;
      console.log(`>>>> Time: ${this.time}`);
    }
  }

  forward(): void {}
  rewind(): void {}
}

Let's add forward and rewind into the mix. And let's log when 'wrong buttons are clicked'.

class Player {
  // Omitting constructor code

  play(): void {
    if (!this.isPlaying) {
      this.time = Date.now();
    }

    if (this.isStopped) {
      console.log('>>>> [Stop]: play');
    } else if (this.isForwarding) {
      console.log('>>>> [Forward]: play');
    } else if (this.isRewinding) {
      console.log('>>>> [Rewind]: play');
    } else {
      console.log('>>>> [Play]: play');
    }

    if (!this.isPlaying) {
      this.isPlaying = true;
      this.isStopped = false;
      this.isForwarding = false;
      this.isRewinding = false;

      console.log(`>>>> Time: ${this.time}`);
    }
  }

  stop(): void {
    if (!this.isStopped) {
      this.time = Date.now();
    }

    if (this.isPlaying) {
      console.log('>>>> [Play]: stop');
    } else if (this.isForwarding) {
      console.log('>>>> [Forward]: stop');
    } else if (this.isRewinding) {
      console.log('>>>> [Rewind]: stop');
    } else {
      console.log('>>>> [Stop]: stop');
    }

    if (!this.isStopped) {
      this.isStopped = true;
      this.isPlaying = false;
      this.isForwarding = false;
      this.isRewinding = false;

      console.log(`>>>> Time: ${this.time}`);
    }
  }

  forward(): void {
    if (!this.isForwarding) {
      this.time = Date.now();
    }

    if (this.isPlaying) {
      console.log('>>>> [Play]: forward');
    } else if (this.isStopped) {
      console.log('>>>> [Stop]: forward');
    } else if (this.isRewinding) {
      console.log('>>>> [Rewind]: forward');
    } else {
      console.log('>>>> [Forward]: forward');
    }

    if (!this.isForwarding) {
      this.isForwarding = true;
      this.isStopped = false;
      this.isPlaying = false;
      this.isRewinding = false;

      console.log(`>>>> Time: ${this.time}`);
    }
  }

  rewind(): void {
    if (!this.isRewinding) {
      this.time = Date.now();
    }

    if (this.isPlaying) {
      console.log('>>>> [Play]: rewind');
    } else if (this.isStopped) {
      console.log('>>>> [Stop]: rewind');
    } else if (this.isForwarding) {
      console.log('>>>> [Forward]: rewind');
    } else {
      console.log('>>>> [Rewind]: rewind');
    }

    if (!this.isRewinding) {
      this.isRewinding = true;
      this.isStopped = false;
      this.isPlaying = false;
      this.isForwarding = false;

      console.log(`>>>> Time: ${this.time}`);
    }
  }
}

Well, all these if-else's are not looking good. They become longer as we add new functionality to our player and we need to keep track of all the booleans.

This is where State pattern comes into picture:

class Player extends Context<PlayerState, PlayerStateKey> {
  // Omitting some setup code

  constructor(state?: PlayerState) {
    super();
    this.state = state || new Stop(this);
  }

  play = () => this.state.play();
  stop = () => this.state.stop();
  forward = () => this.state.forward();
  backward = () => this.state.backward();
}

Quite concise, right?
We're hiding actual implementations into stand-alone objects (StateA, StateB, etc.) and let our Context only take care of holding the reference to the IState.

Let's implement Play state.

class Play implements PlayerState {
  key: PlayerStateKey = 'play';

  constructor(private context: Player) {}

  play() {
    console.log('>>>> [Play]: play');
    return;
  }

  stop() {
    console.log('>>>> [Play]: stop');
    this.context.time = Date.now();
    this.context.changeState(new Stop(this.context));
    console.log(`>>>> Time: ${this.context.time}`);
  }

  forward() {
    console.log('>>>> [Play]: forward');
    this.context.time = Date.now();
    this.context.changeState(new Stop(this.context));
    console.log(`>>>> Time: ${this.context.time}`);
  }

  rewind() {
    console.log('>>>> [Play]: rewind');
    this.context.time = Date.now();
    this.context.changeState(new Stop(this.context));
    console.log(`>>>> Time: ${this.context.time}`);
  }
}

Every concrete IState implementation needs to describe all the methods. For Play we want to be logging and updating time for any 'button press', but play one.

We'll need to implement all other states, but they will pretty much follow the same logic in our example, so let's omit them here.

What will it cost?

Potential Cons:

As you can see from the full implementation here using this pattern increases the number of files in the project. Some might consider it a bad thing.
Adding a new function to our player (let's say pause) would require to add some implementation in every concrete IState implementation, which might be tedious. IDEs could help with it though, but again might be considered a con for some developers.
In current implementation concrete states (Play, Stop, etc.) are getting the context reference to work with. This might be considered an issue as we might be exposing too much.
State transitions in our example are explicit. Concrete state knows which state to move to. This might not be ideal as we have tighter coupling and transitions might get hard to track.

Potential Pros:

Context (Player class in our example) class becomes drastically shorter and therefore easier to read and maintain.
Adding a new state (Pause for example) is as easy as adding a new class.
Same goes for removing a state (let's we don't need that Pause anymore).
Changing a particular behaviour for the state means just changing one function (several functions in one class/file).
No more if-else's spread across every function (for me personally this is always a huge selling point).

Conclusion

Splitting code into multiple files is usually a good thing. I can't say that i would personally use this pattern on daily basis, but Pros are definitely overweighting Cons for me.

Hope this was a bit helpful 🙃
Source code if needed

⚛️ React conditional rendering

Jokerwolf — Sat, 12 Jun 2021 13:46:39 +0000

A question popped up in my head during a PR review: is it OK to put a rendering condition into the render function (return statement for a functional component) instead of a component reference assignment?

Imagine having this 'heavy' calculation React-component.

It generates a list of elements based on the count prop and logs into a console for illustrative purposes.

Let's say we instantiate it like this.

We have the heavy reference and log it into a console for illustrative purposes.

Won't this way of instantiating actually run some of those 'heavy' calculations inside the Heavy component at the moment we create the heavy reference? What would be the console log if we run this code when shouldRenderHeavyComponent returns false?

I was a bit surprised to only see the heavy reference being logged. Was expecting to see at least the constructor logging something.

So no 'heavy' calculations happening and this approach looks nice. We can assign a component once and if we'll have a longer code for App component, we'll be able to see in the return statement why exactly heavy should/shouldn't be rendered.
The drawback I see is having an actual reference hanging around.
Imagine somebody doing a check somewhere later in code:

Now heavy reference is an actual object, so some code will run.

And of course we have some memory allocated for the object, which doesn't seem like a big thing, but still bothers me a bit as in the end it was all for not actually rendering heavy.

That's why although the idea of a rendering condition being close to the actual rendering is compelling, I would stick to moving it into the assignment.

Console would still have only heavy logged, but now it'll be null as expected.

To answer my initial question: it looks OK-ish to put a rendering condition into the render function (return statement for a functional component) instead of a component reference assignment, but not having a potentially obsolete reference hanging around feels nicer to me personally.

Wonder what else I might be missing? 🤔