Testing is necessary to ensure that everything works as expected.

And, to be honest, we all kinda do it when we are developing. Or am I the only one who uses a bunch of console.log, print, fmt.Println or anything like that everywhere?

For example, when we are developing an algorithm we create variables containing the inputs of the use cases that we want to make sure they work. It’s very instinctive. What testing propose is to systematize that.

In the process, you will write a little more code, yes, once. But then, what you’ll get in return is the reliability of your code; it will force you to write more modular code and clean architecture; you can refactor knowing that you need to make sure to pass the tests that you already created; and really put your code to the limit trying all kinds of different edge cases, all while ensuring that their processes do not disrupt development.

Wait… if it is that good. Then, why everyone is not doing it?

True, it sounds too good to be true, right? Well, because it is. You see, although I said that we instinctively already do testing, it’s not like learning and using the tools are trivial things. As with any skill it requires time and practice to master it. Writing good tests is a skill all by itself.

And even when you manage to get the hang of testing, making tests takes time and effort and, most important of all, writing tests don’t assure that no bug will be introduced into the code base. I’m afraid that we don’t write tests for our tests so we can’t be 100% sure that every use case was tested.

Alright, I get it now… then, why even bother?

Sure, there’s the usual: “caching bugs early” and all things I already mentioned. But, from a developer's point of view, it leads to more reliable and modular code and clean architecture, which can make it more maintainable, scalable, and reusable. By systematically testing your code, you can ensure that it works as intended in a variety of use cases.

Also, I would say that while testing you get to know a little bit more about your components. You can experiment with different scenarios and see how far can they go; and refactor when you see that it’s not working as intended (whether the code or the tests themselves).

Finally, It’s not only to debug an application but also a culture, a way of approaching the development process. Testing sets the standard of the application.

Alright, you convinced me. Where do I start?

Well, it will depend on what languages and frameworks/libraries you use. But, here are some principles that I use to write tests:

Logic and UI separation

Sometimes it's easier to test your components in their different functionalities and then test them together than testing all at once and trying to figure out where a possible bug could be.

Start with the basics and move to the complex ones

Sometimes time we forget to check if the code we want to test sends a response to begin with, or even if it is even defined. So, test even the most fundamental things.

Keep it short and sweet

Try to test one thing at a time.

Don't forget to test edge cases and error handling

It's important to test not only the expected results but also the unexpected ones. By testing edge cases and error handling, you can ensure that your code is robust and can handle unexpected scenarios.

Use mocks and stubs

Mocks and stubs are tools that can help you isolate and test specific parts of your code. For example, if your code relies on an external API, you can use a mock API to simulate different responses and test how your code handles them.

Every failing test is an opportunity to improve

Yes, that’s right, the idea is to improve code quality, so, use every failed test to solve it and hence improve the code and reliability of it.

Don't test everything

Testing is important, but it's not realistic to test every single line of code. Instead, focus on testing the critical parts of your code and the parts that are most likely to break.

By following these principles and incorporating testing into your development process, you can build more reliable and maintainable software.

Find your own thing

Even when you learn from courses, coworkers and tutorials, it’s also important to listen to your own experience and find your way to do it.

Now

I’ll be releasing an article on testing in react native with this example that I made only for that article. Here’s the repository.

I don’t know if I’ll gonna release it after this article because I’ve been organizing my study notes and stuff. But I’ll let you know 😆 (And, yes, I did the thumbnail of this article. Pretty cool, right? 😎).

That’s it for me, but you can follow me on LinkedIn, Twitter, Instagram, Facebook, Github, Reddit and here in Hashnode. Also, you can subscribe to my newsletter down below 👇. Well, see ya!

They are the blueprint for its instances (objects that the class produce).

JavaScript has had classes since the ES5 language implementations. In there it was introduced to us the native implementations of “classes” was. Typescript extends the functionalities of that feature to make it look more like more common programming languages like Java for example.

Before we continue, if you're in a hurry, here's the GitHub repository with all the code of this guide, just in case.

Now, let’s see what functionalities are and how to use them.

Basic declaration

There is no mystery here. You use the keyword class, next to the name of the class (starting it with Uppercase by convention) and open brackets.

/* ------------- Basic declaration ------------ */
class A {
    a1: string;
    a2: number;
    a3: boolean;

    constructor(a1: string, a2: number, a3: boolean) {
        this.a1 = a1;
        this.a2 = a2;
        this.a3 = a3;
    }
}

In that snippet of code, you have a1 , a2 and a3 declared at the top of the class, that’s because Typescript will use that to tell this that those are part of its constructor and will not throw an error nor syntax warnings on the editor.

I know that’s a little too much boilerplate for just a simple class, but don’t worry, keep reading and I’ll show you a shorter way of doing that.

Then you can instantiate it like this:

const aa = new A("New Class", 1, true);
console.log("Basic declaration:", aa);

With methods

Went you wanna add methods, you don’t need to declare it at the top of the class nor do you have to use the keyword function.

/* --------------- With methods --------------- */
class B {
    b1: string;
    b2: number;
    b3: boolean;

    constructor(b1: string, b2: number, b3: boolean) {
        this.b1 = b1;
        this.b2 = b2;
        this.b3 = b3;
    }

    run(time: "all day" | "just the mornings" | "anytime"): void {
        console.log(`I'm running ${time}, so you have this: ${this.b1} times ${this.b2} and it's ${this.b3}`);
    }
}
const bb = new B("Power", 59, true);
console.log("B class:", bb);
bb.run("all day");

Encapsulation

Sometimes you’ll want to limit the kind of information that the instances share with the rest of the code, in those cases, you’ll use encapsulation.

The default way that classes instantiate their properties is public. Anyone can see them, anyone can change them, and anyone can manipulate that data.

Then, you have private properties which can only be manipulated by the class itself. By convention, you start the name of a private with an underscore _ and they are strongly related to getters and setters, which I’ll explain in a moment

Some properties can only be read and cannot be modified, not even by the class itself, those are readonly .

And finally, we have protected which is very similar to private but with the difference that protected properties can also be modified by inherited classes (I’ll talk a little bit about that later).

/* --------------- Encapsulation -------------- */
class C {
    c0: any // public by default
    public c1: null | number;
    private _c2: boolean | string;
    readonly c3: string;
    protected _c4: string;

    constructor({ c1, c2, c3, c4 }: { c1: null | number, c2: boolean, c3: string, c4: string, }) {
        this.c0 = "Whatever";
        this.c1 = c1;
        this._c2 = c2;
        this.c3 = c3;
        this._c4 = c4;
    }

    get c2() {
        return `Mr. C2 says that  it's value is: ${this._c2}. Now you can go, please`;
    }
    set c2(newValue: boolean | string) {
        // this.c3 = "Nope, still not changing"; // it will change the value, but the idea is to listen to typescript
        this._c2 = newValue;
    }

    set c4(newValue: string) {
        this._c4 = newValue;
    }

}
const cc = new C({ c1: null, c2: false, c3: "You can only see me, not modify me", c4: "Only the class can make me change and it's children" });
console.log("Encapsulation with class:", cc);

cc.c0 = "I'm public, whatever";
cc.c1 = 975;
// cc._c2 = true; // it will change the value, but the idea is to listen to typescript
cc.c2 = "VIP";
// cc.c3 = "Time to change... hahaha, not really"; // it will change the value, but the idea is to listen to typescript
// cc._c4 = "I told you, only the class can change me, not you"; // it will change the value, but the idea is to listen to typescript
cc.c4 = "Oh, well, if you say it please.... okey, let's go";

console.log("After changes:", cc)
console.log(cc.c2)
console.log(cc.c3)
// console.log(cc._c4) // it will display the value, but the idea is to listen to typescript

In the code above you’ll see a lot of comments, that’s because since this is an implementation of Typescript, many of these keywords don’t exist natively on Javascript, so the changes that you make in those scenarios are, even if they are invalid to Typescript, it will still run went it transpile to Javascript.

Getters and Setters

Although this is not specific to Typescript but also Javascript. Getters and Setters are used to set or get a value of a property.

They are useful when you are using private or protected properties but you still want a way for the class to expose those values without directly referencing them.

Using the example above, they would like something like this:

class C {
    private _c2: boolean | string;

    constructor({ c2, }: { c2: boolean }) {
        this._c2 = c2;
    }

    get c2() {
        return `Mr. C2 says that  it's value is: ${this._c2}. Now you can go, please`;
    }
    set c2(newValue: boolean | string) {
        // this.c3 = "Nope, still not changing"; // it will change the value, but the idea is to listen to typescript
        this._c2 = newValue;
    }

}

Get

get will return the value of the property.

console.log(cc.c2)

Set

set can overwrite the value of the private property.

cc.c2 = "VIP";

Short constructor

To avoid all the boilerplate to declare the variables with their types at the beginning of the class, you can use attributes of the constructor to short that off. The only condition is to add the access type of each variable.

/* ------------- Short constructor ------------ */
class D {
    constructor(
        // d0: any // you need to add the type of access: public, private, etc
        public d1: number,
        private d2: boolean,
        readonly d3: string,
        protected d4: number = 888,
    ) { }

    d5(): void {
        console.log("Just logging");
    }
}
const dd = new D(13, true, "Reading...", /* 99 */);
console.log("Short constructor", dd);

Inheritance

A class can have all the methods and properties that another class has. To do so, one class extends the functionalities of another, this process is called inheritance because, in some sense, the class extended will become a “parent” and the other a “child” that will inherit everything that its “parents” has.

As a side note, a class can only inherit one class at a time.

/* ---------------- Inheritance --------------- */
class E {
    constructor(
        public e1: number,
        private e2: string = "Hi, I'm VIP",
        protected e3: string = "Hello, I'm can be used be the inheritance",
    ) { }

    e4() {
        console.log("%c Here, just doing some Class E stuff", "color: pink; background-color: black",);
    }
}
class F extends E {
    constructor(
        e1: number, // for the super class don't put the access type (public, private, etc)
        public f1: number,
    ) {
        super(e1);
    }

    f2() {
        console.log(`Super thing 1 ${this.e1}`);
        // console.log(`Super thing 2 ${this.e2}`); // privates can be extended to the children
        console.log(`Super thing 3 ${this.e3}`);

        super.e4();
    }
}

const ee = new E(2000);
const ff = new F(2501, 3000);
console.log(ee);
console.log(ff);
ff.f2();
// class G extends A, B, C, D, {} // it can only extend 1 class at the time

Static methods

With the static keyword you can use properties and methods (mostly methods) without instantiating the class but with the class itself. Just keep in mind that the object instance this will not work as expected since there will be nothing instantiated yet.

/* ------------------ Statics ----------------- */
class G {
    constructor(
        public gg = "Good game, gg",
    ) { }

    static g = "gg, GG, gg";
    static ggGGgg() {
        console.log(`By the way, gg. ${this.gg}. Woops, I forgot that you need to initialize my first, unless... ${this.g}...`);
    }
}
G.ggGGgg();
console.log(G.g)

Abstract Classes

An abstract class is the class you don’t want to instantiate because they are too open in its definition and too vague to make an object out of it. Instead, what you wanna do is to define it and let other classes inherit from it. That’s the whole point of an abstract class.

/* ----------------- Abstract ----------------- */
// when a class is too general
// and you don't want to allow instances of that class
// but you still want to inherit
// then you can use an abstract class
interface ILiving {
    name: string;
    exists(): void;
}
abstract class LivingThing implements ILiving { // ignore the "interface" and "implements" for now
    constructor(
        public name: string = "perrito",
    ) { }

    exists(): void {
        console.log("Existing");
    }
}

// const livingThing = new LivingThing("Creature"); // Just don't, ok?
class Dog extends LivingThing {
    constructor(
        name: string,
        public power: string,
    ) {
        super(name);
    }

    move(): void {
        console.log("Moving using 4 legs");
    }
}
const dog = new Dog("Perrito", "Perfection");
console.log("Extending from abstract class", dog);
dog.exists();
dog.move();

Interfaces in classes

Interfaces are related to objects and only exist on Typescript, not in Javascript. They declare what properties and methods the object will have and what type of data it’ll manage.

interface H {
    h1: number;
    h2(): number;
}

Like classes, they can extend from each other. But, there is no such thing as polymorphism, which I’ll explain in another moment, but means that you can’t overwrite a property, for example h1 with another interface.

/* ---------------- Interfaces ---------------- */
interface H {
    h1: number;
    h2(): number;
}
interface I {
    i1: string;
    i2: ILiving;
}
interface J extends H, I {
    j1: boolean;
}

And you use the keyword implements to use them in your classes.

class K implements H, I, J { // in this example implementing "H" and "I" are optionals since "J" already does that
    constructor(
        public h1: number,

        public i1: string,
        public i2: ILiving,

        public j1: boolean,
    ) {}

    h2() {
        return 66;
    }
}
const kk = new K(44, "Welcome", dog, true);
console.log("Interfaces and classes =>", kk)

Well, there you have it. A complete guide to Object Oriented Programming using Typescript. If you have anything to add to it please comment on it or reach out to me through my social media:

Twitter, LinkedIn, Instagram, Github, Medium (For more opinion-based posts), and here on Hashnode and my Hashnode blog. Also, follow me if you want XD

Remember that here's the repository with all the code.

Have a nice day and until next time. Bye.

I must give credit to this post and its Youtube video because I was of great help in this regard.

If you’re in a hurry, here’s the repo containing the whole file of this tutorial.

How GitHub Actions works

As I said it’s a tool integrated into GitHub to automate processes related to the repository. It works by declaring a .yml (you can find a complete view of YAML files in this article) in the relative of your repo: /.github/workflows/

In those files will live the configurations of the tasks that will be executed when a given event occurs on the repo: push, pull requests, issues, tags, etc.

Where to begin?

Well, if you’re completely new to this I suggest starting to create a folder in the root of your project called .github. Inside there, create another folder called workflows (yes, this is the path that I mentioned before).

Then create a file with the .yml extension. You can call it whatever you want but I’ll call it: build-android.yml.

And finally, enable Github Actions in the Actions tab:

With that, we are ready to begin.

Considerations for this tutorial

You don’t need to be the owner of the repository to make this tutorial. If you have access to it like a contributor it’s enough.

I’ll gonna compile multiple .apk files for different architectures of CPUs, and if you only gonna compile one .apk then you can do it just fine.

Steps

Name the Action

At the top of the file put whatever name you want the action to have. You can do it like this:

name: Build Android .apk

Name of the runtime (optional)

By default, the action in the Actions tab will run with the name of the commit that triggers it, but you can change that by putting run-name in the file. Like this:

name: Build Android .apk

run-name: "Building the .apk with the tag triggered by @${{ github.actor }}"

The workflow running will look like this:

The ${{ [github.actor](http://github.actor) }} is a variable that Github provides with the user that triggered the action: GitHub Object.

Event Trigger

In this part, you can put any event that you see fit, but since this is a tutorial to create a release with the output, then it’s necessary to use git tags to trigger the action.

name: Build Android .apk

run-name: "Building the .apk with the tag triggered by @${{ github.actor }}"

permissions:
  contents: write

on:
  push:
    tags:
      - "v*"

The "v*" means that the tag name must start with v, but you can put it like this to trigger it at any tag: "*".

Jobs

Jobs are different processes that can run in parallel (or in sequence) in GitHub Actions. For this tutorial, we’ll not gonna worry too much about it, but I’ll leave you some resources for you to deep dive into it:

Github Actions Job Objects

Youtube: 5 Ways to DevOps-ify your App - Github Actions Tutorial

For now, I’ll gonna call this job as build (but you can call it otherwise if you want) and say it to run on the latest version of Ubuntu:

jobs:
  build:
    runs-on: ubuntu-latest

Steps Object

Before we start giving instructions on how to compile the app, first let’s declare the step object that will wrap the processes:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:

Setting the repository

Now, this is the part that we all have been waiting for: The Actions of GitHub Actions.

To use them you need to declare a name and a uses parameter. You’ll see the pattern with the rest of the tutorial.

Use the checkout action to move to the root of your project:

steps:
    - name: Checkout repository
      uses: actions/checkout@v2

Installing Java

Use the Java action with the Gradle version:

- name: Install Java
    uses: actions/setup-java@v3
    with:
      java-version: "11"
      distribution: "adopt"
      cache: "gradle"

Validate Gradle (optional)

I’ll not gonna lie to you, this is something that I saw in the tutorial that I mention but I suppose that you can do it without it anyway.

- name: Validate Gradle wrapper
  uses: gradle/wrapper-validation-action@v1

Installing Node.js

Setup node with the GitHub Action:

- name: Setup Node  
  uses: actions/setup-node@v3
  with:
    node-version: '16'

With this, you will set up yarn and npm if you need them. In my case, I’ll use yarn for the rest of the tutorial, but it will depend on your use case.

Installing dependencies and building the project

As I said, I’ll use yarn for this but it will depend on you.

- name: Run Yarn Install
  run: yarn install

- name: Build application
  run: yarn release

The release script in the package.json file looks like this:

"release": "cd android && ./gradlew assembleRelease",

List the compiled files (optional)

This is just to see the name of the .apk files in case you need to see them to do something else.

- name: List the .apks compiled
  run: ls ./android/app/build/outputs/apk/release/ -hal

Changing the name of the main .apk file (optional)

This is not necessary, but I’ll add it anyways because it’s better to download the .apk, when needed, with the version that has a semantic name.

In this case, I’ll rename the app-universal-release.apk, but in your case, it might look different. So be aware of that.

- name: Rename the .apk to the tag version
  run: mv ./android/app/build/outputs/apk/release/app-universal-release.apk ./android/app/build/outputs/apk/release/app-name_${{ github.ref_name }}.apk

The {{GitHub.ref_name }} has the version name of the git tag.

Creating Release and Uploading Files

Finally, the GH Release Action to create the release and push the .apk compiled.

As I said, I’ll upload many files because I’m compiling a .apk for each CPU architecture, in your case it could be only one, but don’t worry I’ll show you how to do it as well.

- name: Create Release and Uploading Files
  uses: softprops/action-gh-release@v1
  if: startsWith(github.ref, 'refs/tags/')
  with:
    files: |
      android/app/build/outputs/apk/release/app-arm64-v8a-release.apk
      android/app/build/outputs/apk/release/app-armeabi-v7a-release.apk
      android/app/build/outputs/apk/release/app-x86_64-release.apk
      android/app/build/outputs/apk/release/app-x86-release.apk
      android/app/build/outputs/apk/release/app-name_${{ github.ref_name }}.apk

In the files part, in case you want to upload only one file, do it like this:

files: android/app/build/outputs/apk/release/app-name_${{ github.ref_name }}.apk

Or

files: android/app/build/outputs/apk/release/app-universal-release.apk

Results

Well, the result would look something like this:

name: Build Android .apk

run-name: "Building the .apk with the tag triggered by @${{ github.actor }}"

permissions:
  contents: write

on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ubuntu-latest
    # runs-on: ubuntu-22.04 # this is the Ubuntu version that this was created on

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Install Java
        uses: actions/setup-java@v3
        with:
          java-version: "11"
          distribution: "adopt"
          cache: "gradle"

      - name: Validate Gradle wrapper
        uses: gradle/wrapper-validation-action@v1

      # Node, Yarn and NPM
      - name: Setup Node  
        uses: actions/setup-node@v3
        with:
          node-version: '16'

      - name: Run Yarn Install
        run: yarn install

      - name: Build application
        run: yarn release

      - name: List the .apks compiled
        run: ls ./android/app/build/outputs/apk/release/ -hal

      - name: Rename the .apk to the tag version
        run: mv ./android/app/build/outputs/apk/release/app-universal-release.apk ./android/app/build/outputs/apk/release/app_name_${{ github.ref_name }}.apk


      # Creating and Uploading the releases
      - name: Create Release and Uploading Files
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        with:
          files: |
            android/app/build/outputs/apk/release/app-arm64-v8a-release.apk
            android/app/build/outputs/apk/release/app-armeabi-v7a-release.apk
            android/app/build/outputs/apk/release/app-x86_64-release.apk
            android/app/build/outputs/apk/release/app-x86-release.apk
            android/app/build/outputs/apk/release/app_name_${{ github.ref_name }}.apk

Remember that everything we did is in the repository of this tutorial.

After you commit the file and push a tag into your repository you’ll see something like this in the Actions tab:

And you’ll also see the release:

Well, that’s it for me now. Please let me know if it was useful to you or if you had any issues.

Follow me on Twitter, LinkedIn, Instagram, Github, Medium (For more opinion-based posts), and here on Hashnode and my Hashnode blog.

Have a nice day and until next time. Bye.

(And all the code that you are about to see here it's in this repo)

Now, here are some of the key concepts of functional programming in JavaScript:

Pure functions

A pure function is a function that always returns the same output for the same input, and does not have any side effects. In other words, it does not modify any external state or data. Pure functions are predictable, easy to test, and can be composed together to create more complex functions.

/* -------------------------------------------- */
/*                Pure functions                */
/* -------------------------------------------- */
const double = x => x * 2;
let value = 2;
console.group('No matter the time executes the output will always be the same \ngiven the same value')
console.log(double(value))
console.log(double(value))
console.log(double(value))
console.log(double(value))

value = 3
console.log(double(value))
console.log(double(value))
console.log(double(value))

value = 12
console.log(double(value))
console.log(double(value))
console.log(double(value))

value = 234
console.log(double(value))
console.log(double(value))
console.log(double(value))
console.groupEnd()

In contrast, you can see what a not pure function would look like:

/* ----------- Not so pure functions ---------- */
const ran = x => x * Math.random();

console.group('It will always change no matter if is the same input')
console.log(ran(value))
console.log(ran(value))
console.log(ran(value))
console.groupEnd()

Immutability

In functional programming, immutability is the idea that data should not be modified once it is created. Instead, new data is created based on the old data. This allows for more predictable and maintainable code.

Higher-order functions

A higher-order function is a function that takes one or more functions as arguments or returns a function as its result. Higher-order functions are used extensively in functional programming.

/* -------------------------------------------- */
/*            Higher Order Functions            */
/* -------------------------------------------- */
function triple(x) {
    return x * 3;
}
const numbers = [1, 2, 3, 4, 5, 16, 27,];

const result1 = numbers.map(y => y * 3);
const result2 = numbers.map(triple);
// const result3 = numbers.map(triple()) // map will execute the function, not you. You only declare it not call it
// result1 === result2
// result2 !== result3

// higher order function can also be
// a function which returns another function

console.log("Higher order results", result1, result2, /* result3 */);

Recursion

Recursion is a technique in which a function calls itself until a stopping condition is met. In functional programming, recursion is used instead of loops to iterate over data structures.

You can see that in this code of a deep copy of an object of JavaScript:

/* --------------- Deep copy --------------- */
function isObject(element) {
    return typeof element === "object";
}
function isArray(element) {
    return Array.isArray(element);
}

function deepCopy(element) { // you can do this but with Freeze if you like (deepFreeze)
    const isObj= isObject(element);
    const isArr = isArray(element);
    let copy;

    if (isArr) {
        copy = [];
    } else if (isObj) {
        copy = {};
    } else {
        return element;
    }

    for (let key in element) {
        const inKey = element[key];
        const isKeyObject = isObject(inKey);

        if (isKeyObject) {
            copy[key] = deepCopy(inKey)
        } else {
            if (isArr) {
                copy.push(inKey);
            } else {
                copy[key] = inKey;
            }
        }
    }
    return copy;
}

const objD1 = deepCopy(objA2);
console.group("Deep Copy")
console.log(objD1, objA2)
objD1.a2 = 75950;
objD1.e2.f2 = 6905589
objA2.k2();
objD1.k2();
console.log("After modifications")
console.log(objD1, objA2)
console.groupEnd("Deep Copy")

Function composition

Function composition is the process of combining two or more functions to create a new function. This allows for more complex functionality to be built from simpler building blocks.

Closures

A closure is a function that has access to variables in its outer (enclosing) scope, even after the outer function has returned. This is possible because the variables are still being referenced by the inner function, and are not eligible for garbage collection. Closures are used extensively in functional programming and can be used to create private variables and functions, as well as to create higher-order functions. Here is an example of a closure in JavaScript:

/* -------------------------------------------- */
/*                   Closures                   */
/* -------------------------------------------- */
const rememberToSum = a => b => a + b;
function rememberToSum(a) {
    return function (b) {
        return a + b;
    }
}
const returnedSum = rememberToSum(5);
console.log(returnedSum(5))

Currying

Currying is a technique in which a function that takes multiple arguments is converted into a sequence of functions that each take a single argument. This allows for more flexible function composition and partial function application. In JavaScript, you can use the curry function from the popular lodash library to curry functions. Here is an example of using curry to create a curried function:

/* -------------------------------------------- */
/*                   Currying                   */
/* -------------------------------------------- */
function notCurredSumOfThree(a, b, c) {
    return a + b + c;
}
function sumOfThree(a1) {
    return function (b2) {
        return function (c3) {
            return a1 + b2 + c3;
        }
    }
}
const arrowSumOfThree = a => b => c => a + b + c; 

console.log(notCurredSumOfThree(1, 2, 3), sumOfThree(1)(2)(3), arrowSumOfThree(1)(2)(3));

Overall, functional programming in JavaScript can lead to more maintainable, predictable, and reusable code. It may take some time to get used to the functional programming paradigm, but it is worth exploring for any serious JavaScript developer.

Well, that's it for now. I hope it was useful for you. Comment if you have any other suggestions or something to add, I'll be reading you.

Follow me on Twitter, LinkedIn, Instagram, Github, Medium (For more opinion-based posts), and here on Hashnode and my Hashnode blog.

Have a nice day and until next time. Bye.

YAML is an information transfer language like JSON or XML. And it is used for its simplicity and consistency.

File Extention

These YAML files end with .yml or .yaml, either of them is correct.

Indentation

The indentation in YAML is essential, to make an indentation valid you need to use 2 spaces per indentation. Indentation is used instead of curly brackets {}.

Syntax

You don't end the line with a ; or any other special character.

Comments

Use the # symbol to ignore whatever it is in front of this symbol until the end of the line.

# variable: string commented
valid: "not commented"

Objects

You use indentation to denote that the variables below are methods of the object. YAML is sensitive to indentation so they all need to be at the same level of indentation.

nameoftheobject:
  app: some-name
  port: 9000
  version: 1.7

Lists

Use the - symbol to make a list, remember to indent the variables that belong to that list. But you can also avoid indentation while using lists, so don't get confused when you see them in different forms of indentation. But all elements need to have the same indentation.

microservices:
  - app: some-name
    port: 9000
    version: 1.7
  - app: other-name
    port: 9002
    version: 1.9

microservices:
  - some-name
  - other-name
  - app: dog
    port: 19
    versions:
    - 1.2
    - 1.5
    - 1.8

You can also use brackets as a primitive.

microservices:
  - some-name
  - other-name
  - app: dog
    port: 19
    versions: [1.2, 1.5, 1.8]

Boolean

true false yes no on and off, all of them are used as boolean values.

Multiline strings

Use the | symbol to make separate lines, and use the > symbol to make a single line of the string.

multilineString: |
  This string is separated
  so there is no need to make a buzz
  this is how it will be shown

multilineString: >
  This line will be shown as
  one line, no matter how long
  or how many breaks do I make

Environment Variables

Use the $ before the name of the environment variable to use it.

command: mysql -h 123.000.000 -u root $THIS_IS_A_PASSWORD -e 'SELECT 1'

Placeholders

Use the double curly brackets {{}}to use placeholders for templates.

app: {{ .Values.service.name }}

Multiple YAML Files

Use three dashes --- to separate YAML files inside the same file.

thisIsAVariable: blah-blah-blah

---
thisIsAnotherFileInside: this-is-another-file

Well, that's it for now. I hope it was useful for you. Comment if you have any other suggestions or something to add, I'll be reading you.

Follow me on Twitter, LinkedIn, Instagram, Github, Medium (For more opinion-based posts), and here on Hashnode and my Hashnode blog.

Have a nice day and until next time. Bye.

Initialize the project

To quickly initialize the project just do:

npm init -y

Or if you want a more personalized project just do:

npm init

There it will ask you the following questions:

• Name of the package
• Version
• Description
• Entry point
• Test command
• A git repository
• Keywords
• The name of the author
• And the type of license

Installing the dependencies

All the dependencies we’ll use are typescript, nodemon, ts-node, tsconfig-paths and tsc-alias as the main ones for development with typescript.

• typescript: is the language compiler.
• nodemon: it listens to any change on the project and restarts it to run that change.
• ts-node: It helps to listen to the changes on a typescript project.
• tsconfig-paths: typescript has a feature that allows custom path names to the folders to avoid nested relative paths such as ”../../../../../../someFile.ts”.
• tsc-alias: it will interpret those custom paths to relative routes on the compilation for production.

One of the core features of Typescript is the type check. These are defined on the language, whether they are strings, number or boolean just to name a few, that makes sure that the code doesn’t use types of values that it wasn’t assigned to.

Considering the abode, we'll install an additional dependency for the code editor to understand the intellisense (code completion) part of the development in node to understand typescript as well: @types/node.

npm install typescript nodemon ts-node tsconfig-paths @types/node --save-dev

Remember that --save-dev (-D for short) it’s used for dependencies that are only require in development. As a side note, I recommend add --save-exact (-E for short) to npm install command, this will install the exact dependencies each time that the package.json file is used.

npm install typescript nodemon ts-node tsconfig-paths tsc-alias @types/node -ED

This is because, by default, npm install dependencies as “from this version upwards” and you can distinguish them with the ^ symbol at the beginning of each version.

"devDependencies": {
    "@types/node": "^16.11.7",
    "nodemon": "^2.0.15",
    "ts-node": "^10.4.0",
    "tsc-alias": "^1.4.0",
    "tsconfig-paths": "^3.11.0",
    "typescript": "^4.4.4"
  }

As opposed to:

"devDependencies": {
    "@types/node": "16.11.7",
    "nodemon": "2.0.15",
    "ts-node": "10.4.0",
    "tsc-alias": "1.4.0",
    "tsconfig-paths": "3.11.0",
    "typescript": "4.4.4"
  }

Setting typescript

Typescript has a way to configure it to the project at hand. Use the following command to start from scratch:

npx tsc --init

This will generate a tsconfig.json file. This json has all the parameters that typescript accepts for configuration, in this case, most of them are commented. We’ll get there, for now, create a folder (or directory) at the root of the project called src/. For that you can simply use the following command:

mkdir src

Inside that folder create the main file, in this case, it will be called index with the .ts extension. You can use Vim or any other text editor to create it. In this case, I will use touch:

touch index.ts

In it, write a simple code like:

console.log("hi, this is working");

And in the src folder create another directory named example and file.ts in that same folder. You can simply use this to do those things in one line:

mkdir src/example && touch src/example/file.ts

Configuring Typescript

Remember when I told you to use the npx tsc --init command to generate the tsconfig file? Well, add at the beginning of the tsconfig.json the following code or uncomment the parts where this are located and put:

    "lib": ["ESNext"],
    "allowJs": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "baseUrl": "./",
    "paths": {
      "@example/*": ["src/example/*"]
    },

Putting all the installed dependencies together

The simple version is this: Add the following code to the package.json replacing the current scripts section in the file:

"scripts": {
    "start": "NODE_ENV=production node dist/index.js",
    "dev": "NODE_ENV=development nodemon src/index.ts --exec 'ts-node -r tsconfig-paths/register'",
    "build": "tsc --project tsconfig.json && tsc-alias -p tsconfig.json",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Now run:

npm run build

You’ll see a dist folder right on the root of the project, that’s the compilation of the typescript code to javascript. Run:

npm start

And it should output something like this:

> ts_setup@1.0.0 start
> NODE_ENV=production node dist/index.js

hi, this is working

Finally, in the index.ts of the src folder, replace it with the following code:

import variable from "@example/file";

console.log("hi, this is working", variable);

The output should be something like this:

hi, this is working { x: 'there', y: 'hello', z: 'hello, there' }

You can even run npm run build and npm start for production.

You can find the source code on in here.

If you have any idea or want to point out some mistake that I made, write a comment below, I will read it and I'm sure that we will find a solution for it. I hope that you make fantastic sites with this information that I wrote.

Follow me on Twitter, LinkedIn, Instagram, Github, Medium (For more opinion based posts), and here on Hashnode and my Hashnode blog.

Have a nice day and until next time. Bye.

Throughout history, people expressed their ideas through language. They give them form and shape words. However, memory can only last that much. With time, those who communicated and shared knowledge fated away and so much of their knowledge.

To perpetuate our ideas we started to represent language visually. This changed everything. Not only you could keep the thoughts and ideas longer, but also manipulate them. To play it over and over in your head until you understood what the author was talking about.

Now we can know what someone from different ages and countries was writing about. Communication rise, especially when started to product it quicker like with print or, nowadays, the internet.

Yeah yeah, but why does it matter?

Ideas are influenced by the way they are written. Different styles convey different messages. When the language is spoken we can understand the content and also the way it was delivered. The intention behind that message.

We can't know for sure how the reader will interpret our words.

Words help to communicate a message, good typography helps to connect words. That means that the visual implementation makes it easier to read the content of words, can set a brand apart, or just make the information more accessible overall.

You can make something aesthetically appealing and deliver a good narrative. Set your identity with what you want to tell.

Bad typography can confuse and diverge your content from your message.

So, be sure to pursue aesthetics and meaning in your writings. Because everything is taken into account.

Typefaces and Fonts

Typefaces

When I talk about typefaces I'm referring to the whole set of letters and symbols that share the same intended design.

Font

Fonts refer to the weight and italic style variations of a typeface. In short, it's an instance of a typeface.

Types of typefaces

Serif

They are typefaces with decoration at the extremes of each letter.

Sans-serif

Typefaces without any decorations at the extremes of each letter.

Monospace

In monospace each letter and symbol update the same space no matter the width of each one.

Scripts

Are hand-written typestyles.

How to choose a typeface or font family

Well, this is the part where I say that it depends. You see, I learn that as much study and analysis typography has, in the end, it's not an exact science. Sometimes you need to try different types and pick the one that gives the message that you want, in the context that you want and the medium that you're in.

Having said that, there are still some things to consider when choosing a typeface like the mood of the message or the medium that it will be seen.

Choosing the right type will make it more accessible for everyone who reads it.

The mood

Formal texts are associated often with serif, but script types can also be formal. And the more casual ones are the sans-serif which are good for context without formalities.

Print vs Digital

It's believed that the serif type will be easier to read on small printed elements like books or newspapers. The sans-serifs are used more often on digital devices and magazines.

White Space

It’s the area between elements.

Although is called whitespace, that doesn’t always need to be white. The main purpose is to allow text to breathe.

Title vs Text

Texts need to be easy to read even on small fonts, things like the height difference between caps and small caps are taken into account, in this case, a lower gap between those two is important for readability.

Titles can have more freedom in that regard, but they need to be trimmed to occupate as much space as possible without breaking into the next line. For that reason, the space between letters can be less than the normal text.

Size, Contrast, and Hierarchy

On the designing of typography, always use relative size units like em (relative to a specific part) or rem (relative to the root font size of the given document).

Contrast

The color of the font and the color of the background are really important to decide the contrast.

A proportion would be between 4.5 for texts and background and 3.1 for titles.

Size

Text

Somewhere between 16px and 24px.

The length of the paragraph is measured on letter count than on absolute sizes. A maximum length would be between 50 to 70 letters per line. But, of course, that depends on the size of the screen. In either case, the idea is to leave whitespace for the content to rest and make it easy to read.

You can use a max length of 30em and work from there.

Tittle

Between 26px and around 40px.

Hierarchy

Hierarchy is the distinction between one element with another, and it is used to guide the reader through the text with different types of emphasis.

You can use size, contrast, whitespace, and fonts to create an organized implementation of the elements.

A good rules of thumb with size is to start with 16px and add an 8x increase (24px, 32px, 40px, etc). But, don't forget the relative units of em and rem.

In contrast, make sure that the colors aren't "too vibrant" with each other.

Alignment

• Centered text can be used in titles, but it’s a good idea on regular text. Remember that text needs to be easy to read. But you can center the block of text on which the content rests.
• Justified alignment is more common in printed media, especially newspapers which need them to divide the content into columns and justify alignment takes advantage of that.
• Left alignment is especially useful for regular text, but it can be used on titles as well.
• Right alignment. Since we read from left to right, I wouldn’t recommend using it. But, like many things, there are exceptions. This isn’t an exact science, so you can experiment if you want.

Finally, choosing the right typography forces you to be conscious about the style, intention, and mood you want to deliver. So don't be afraid to experiment and use what fit into your message.

Follow me on Twitter, LinkedIn, Instagram, Github, Medium (For more opinion based posts), and here on Hashnode and my Hashnode blog.

Have a nice day and until next time. Bye.

The key thing here is the word “just”. It includes a lot more that doesn’t exist in a conventional shop. It takes into consideration a lot more like the number of clicks, pages visited and time inside the page.

It’s important to take seriously the design of every e-commerce store since it is the bridge between your customers and your business.

This article is not a must-do guide for the experience of a user of your e-commerce site. It’s just a list of considerations to take into account when developing one. There is no such thing as a definitive answer in a field that is constantly evolving. And it is up to you to use this and any information that you encounter with the most care. Use your experience, your intuition, and the metrics of the site to determine what works for you.

Customers

We can all agree that everyone is not the same. Your customers will explore your page with different goals in mind. Here is a brief consideration of the type of customer:

• Based on the Product: They know what they are looking for. They have a goal in mind and they are going to find it. Give them the tools to achieve that goal.

• Based on the Navigation: They have time. They want to search and see things around them. They might stop the search one day only to continue the next one.

• Based on the Investigation: They would like to have all the information possible to make an informed decision. Things like prices, quality pictures, addresses, and reviews. Every relevant information that you could give them.

• Bounty hunters: They want to buy the best products for the best price. Things like the discounts right next to the “original” price it’s very compelling to them.

• Occasional purchase: They could be one of the above but they could have found your e-commerce by chance, or by a gift card or something. Make sure that your site allows you to buy without registering or at least explain the benefits of doing it.

With that notion in mind, let’s dive into the specifics.

Search

The search must be at the heart of your business. Google made a whole empire based on a search engine. Youtube, at its core, is a place to search and watch videos, without the search component the platform would be a flop. Let customers go forward and back whenever they want.

Pay attention to the categories and subcategories of navigation. Remember to allow the exploration of a category as a whole instead of just automatically using a subcategory.

The search bar is very important. Take it very seriously. If you can add relevant suggestions and autocompletion then do it. And don’t forget to make it as simple and intuitive as possible, but with additional options for advanced users who want to make a specific type of search.

And don’t hesitate to add filters.

Make accessible the information about the product

Well, this is not only to make your business more transparent to your customers but also because it allows people to analyze and compare the products that you're offering. Whether with another store or other products that you have in stock, people will make comparisons, so make that information accessible.

Again, make a detailed description. Don’t saturate. You can make a summary, add a button to "read more" or do anything that alludes to the information that you have without clouding the page with information.

Make the price comparison easy, like adding the original price, the discounted price and how much the customer is saving. Also, remember that offers help to cause that sense of urgency.

Some people will give you their email for a newsletter, but only if you make it clear that they will find out more discounted prices, rare products, or relevant information for them.

Add information about the company. This will make it seem trustworthy and will send a message of professionalism to everyone who visits your e-commerce, investors included. That's related to the social proof that you need.

Make a "similar products" or "suggested" products section on the product detail

This is only an idea since it could backfire by leading to decision fatigue of the abundance of choices. So bear in mind that you need to make the information digestible. That's related to information theory.

Social Component

• Allow people to share this product.

• Add links to similar products.

• Highlight products on offer or new products or more bought or whatever.

• Comments and reviews, both good and bad because both sides of the opinions are valuable and it will make your site more transparent.

Buying process

• Simplify the shopping and checkout process.

• Make easy the usage of coupons, you can apply them automatically if necessary.

• Make e-commerce able to buy without registration.

• Clear distribution of the information.

Pages

Home

It needs to answer the doubts of the customers. You can use it to show the catalog or to show links to where to find those catalogs or something.

The home page is meant to be the first thing that your customers will see, just like a shelf in a store. You can ask yourself, what products do you want to show first to the customers? What things can you show them so that they keep buying?

• Make it clear that this is e-commerce.

• Allow them to buy on the home page.

• Give them access to the catalog.

• Information architecture.

• Buying and selling process: types of payments, devolution policy, delivery options, etc.

• Build thrust:

  • Customer services.

  • Privacy policies?

  • Information about the company.

• Make the URL as simple as possible.

• Make it simple, with this I mean don't saturate with information and link the customers.

• Make it clear what and how you sell so that customers can understand it as soon as possible.

• Add links to relevant information like policies, solutions or navigation, etc.

Be concise

The navigation must be clear and repeat like a pattern. Be consistent on the whole website.

Things like menus must be always accessible, and make it easy to access core functions like shopping cart, catalog, etc.

Category pages

They show and present the categories to the users. They are the bridge between choosing a category and a product or a list of products.

They represent order, so they can't be messy. And don't automatically move users to the subcategories. Don't saturate them with information. And show the levels of navigation so the user can move in the app and categories.

Product List pages

• Present.

• Show.

• Categorize.

Show the name of the product, price (always), add other options if they are available, availability now and in the near future, pagination (it tells that there are more products), and don't overwhelm with the suggestions, and quality images (this is important because many people buy after seeing a good set of images and show detailed views and everything).

Show which links they have seen (like Google does), and add personalized products and attention. Add filters and orders for choosing the sort order and filters and such.

Product page

This is where the user starts to make the choices in the buying process. This is the best sales agent for your site. They will compare your products with those of your competition.

• Reviews

• Images: don't forget not only to show the product itself but also in context.

• Description: They want clear descriptions, you can add different stages of the descriptions, like the technical ones on one side, and the general description on the other.

• Price.

• Discount: you can add them automatically if they have a coupon or something that it's related to some promotion, and show the discount price and all its benefits.

• Name.

• Availability.

• A clear way to buy or add to a cart or something.

• Categories.

• Navigation.

• Zoom into the images.

• Delivery and buying options.

• Variations.

Talk in the language of the users. What you show is what you sell, don't make shady businesses with fake images or descriptions.

Reviews

Show the good and the bad ones, present summaries and show more options for the reviews.

Checkout

• Order the steps just like the users expects them.

• Show the progress and the steps in the process.

• Minimize distractions.

• Add clear buttons for the process, like a go-back option, the step before, the step forward, and the cancel, (save the state of the whole thing on redux or something).

• Only ask for relevant information about that shopping process.

• Justify why are you asking for each piece of information, and add a description of the name of that field, use a title attribute, or use HTML and CSS to make a floating info panel on hover.

Forms

• Don't ask for the same information or information that you already have

• Update the information each time that it changes for the next checkout

• Autocomplete the fields with the info that you have, but allow them to be changed.

• Use clear tags and add hover descriptions to those fields

• Generate long enough input fields for each field. And make sure to use the right tags for input, like numbers for numbers, and text for text.

• Some users will use the "Enter" or "Return" keys to go to the next step.

• Allow users to correct or change their info at any point.

• Don't preselect like you were the user.

Error messages

They need to explain what went wrong. Be clear and concise.

They must appear next to the input field and don't overwrite the other fields.

They need to explain how to correct and solve the problem and be clear and concise.

Use red for the errors, because if you use it in other messages or things on the app then it will lose effectiveness. Take into consideration the users with visual impairments

Solve or show a possible error before it becomes a barrier when pressing the button or "enter".

Explain what you want with each field so that the error is less recurrent

Shopping cart

You need to show that the cart works and that it makes sounds or animations or something each time that they add something. The user must be able to config that.

Make clear the "buy" button and the "add to cart" button. The button "remove from the cart". And the quantity and total and discounts next to the total, be creative, remember that there aren't clear rules on this, only suggestions.

Explain what to do when the buyer and the receiver are different, like using a QR code or something.

Show what is on the cart.

The cart must be present at all times on the pages.

Add a "keep buying" button.

show links to the policies like devolution and such, and don't overwhelm with information.

Allow to change and modify the content of the cart. Always save the state of the cart.

Navigation

Avoid empty categories and/or catalogs. Remember that with each click the user must get closer to reaching their goal.

Categories trees, bread crumbs, and stand-alone categories and subcategories are important.

Show relevant information and navigation for the user, you can highlight some products in the navigation.

Some products are part of multiple categories or needs.

App Navigation

Remember to pay attention to trends or make your own, the tabs were really important, nowadays are the bottom tabs and drawers.

The hamburger menu and such are easy to recognize. It needs more than 4 categories, and if there is a lot of information it will become a disaster, and for those users that don't use too much internet then it might not be that intuitive.

The bottom navigation allows exploring the app with the dumb.

Registration

It must be optional, and they need to offer clear benefits to justify the process to the users.

You can use the email as usernames, don't have to allow them to create a username. But it's up to you.

If it is obligatory the registration, explain why and the advantages.

Give space for:

• registered users.

• about to register.

• guess users.

Add the logout button.

Delivery and shipping options

• Show the price of the shipping.

• Allow them to choose.

• Don't show choices that do not apply to the user or product.

• Show info about the delivery company, and possibly about the delivery person.

• Show the estimated date or time of the delivery.

• All in one price, even if they are more than one product.

• Allow the user to add instructions for the delivery.

• Add the precedence of the product (this is completely optional, it depends on the type of product and business).

• Show complete information like phone number, localization, and times. And, if applicable, the delivery options or where to pick up the product.

Totals and cost

• Show all the individual costs.

• Show the discount costs.

• Show the total cost.

• Show the total cost with the discounts.

• Add instructions when where to find the info that we are asking

• Show familiar images like a credit card for payments.

• Allow adding coupons in the right place to avoid friction.

• Show the money available like in a gift card or the wallet or general balance or whatever.

• Make simple code names.

Resume (page)

Show all the details in a resumed way (and view more if you need to) of the buy.

Add in the whole process the option to cancel the process.

Show all that information and allow the user to confirm.

You can think of it as a ticket:

• A "thank you" + name or something.

• A number of the buy or whatever.

• Info for the follow-up of the process.

• A PDF or a printable option for the user.

• A "keep shopping" button.

• A logout button (this one is optional, for the users that want to exit the process securely).

And, that's it. Remember, these aren't absolute rules to follow, they are only suggestions. It's up to you to find the best user experience for your e-commerce, and that's the most exciting part.

If you have any idea or want to point out some mistake that I made, write a comment below, I will read it and I'm sure that we will find a solution for it. I hope that you make fantastic sites with this information that I wrote.

Follow me on Twitter, LinkedIn, Github, Instagram, Medium (For more opinion based posts), and here on Hashnode and my Hashnode blog.

Have a nice day and until next time. Bye.

Note: throughout this tutorial, I’ll be using < and > symbols to show the commands, however, these symbols are not required to implement them. I just wanted to comment on it 😎. Now, let’s go with the article.

Creating Branches

The names can’t have spaces. If you need to make a separation use symbols like: - or _.

git branch <new-branch>

git checkout vs git switch

You can have as many branches as you want in the repository; to switch between a branch and another there are two commands: git checkout and git switch.

Git checkout is used on many other aspects of Git besides branches; while git switch is used only for branches which decreases the margin for error and it’s the best way to switch branches.

I recommend git switch.

Renaming

To change the name of the branch you’re in:

git branch -m <head-branch-new-name>

To rename a specific branch:

git branch -m <old-name-branch> <new-name-branch>

Delete Branches

To delete branches locally:

git branch -d <branch>

git push origin --delete <branch>

And to delete a branch from the remote repository use this command:

git push origin :<branch>

Just make sure that nobody in your team depends on the changes in that branch.

Merge

git merge works to integrate the changes between branches. This integration is commonly referred to as “merge”; it keeps the branch history of “commits” intact and creates a new “commit” for the branch receiving the changes.

First, switch to the branch in which you want to receive the changes, then use the following command:

git merge <incoming-branch>

Rebase

It's another way of integrating the changes of a commit history between two branches. It changes the commit history by making the integration a straight line and not a combination of branches.

Like in git merge, you have to switch to the branch in which you want to receive the changes, then use the command:

git rebase <incoming-branch>

Comparing Branches

Check which commits are in branch-b, but not on branch-a.

To check which commits are in one branch (branch-b) and not in another (branch-a) use this command:

git log <branch-a>..<branch-b>

You can also use it to compare them with the remote branches.

It was a short post but I just wanted to challenge myself to write so I told myself that I was gonna do this no matter what, so here it is. I hope I was useful to you.

That’s it for me, but you can follow me on LinkedIn, Twitter, Instagram, Facebook, Github, Reddit and here in Hashnode. Also, you can subscribe to my newsletter down below 👇. Well, see ya!