DEV Community: Bulent Gorkem

Lambda function use in React Class Components

Bulent Gorkem — Sat, 06 May 2023 13:58:45 +0000

React functional components have become more popular than React class components in recent times. Hence we don’t need to rely on use of often misunderstood "this" keyword to access member variables, methods. We used to add a lot of mysterious bind(this) methods to our handlers in constructors before.

   this.checkedHandler = this.checkedHandler.bind(this);

Together with lambda syntax used in class methods we don't need this ceremony anymore.

If you want to understand why, the code sample below explains briefly.

import React from "react";

export default class App extends React.Component {
  constructor(props: React.PropsWithChildren) {
    super(props);
  }

  handleThis() {
    console.log("handle ", this);
  }

  handleThisWithLambda = ()=> {
    console.log('handle that', this)
  }

  render() {
    return (
      <div className="App">

        <button onClick={this.handleThis}>Handle This </button>
        <button onClick={this.handleThisWithLambda}>Handle That </button> </div>
    );
  }
}

There are 2 methods: handleThis and handleThisWithLambda

First one prints undefined as this, because in strict-mode this value is undefined when run outside of any object, ie. the event handler, unless it was bound by the function called, hence the use of ...bind.this( )

The second one with the lambda syntax though prints the correct App instance we are running in.

What is the difference?

If you copy-paste this code to a code transpiler, like typescript playground which converts it old ECMAScript 2017 code, you will spot the difference in how lambda syntax is translated inside the class code

export default class App extends React.Component {
    constructor(props) {
        super(props);
        this.handleThisWithLambda = () => {
            console.log('handle that', this);
        };
    }
    handleThis() {
        console.log("handle ", this);
    }
    ...
}

As you can see handleThisWithLambda code moved into the constructor function, hence created with a closure to the this instance. So it is already doing the same job bind.this was doing previously for the legacy method case.

In React Functional components, you don't need this or bind.this anymore, as every thing is inside the same function closure anyway.

Hope this helps!

Why Typescript?

Bulent Gorkem — Sat, 09 Jan 2021 13:53:11 +0000

Why Typescript

Typescript extends JavaScript by adding types at build time.

Benefits

✅ Encode constraints and assumptions, as part of developer intent. Defensive programming: Don't trust any of your inputs. Causes cognitive and performance overhead
✅ Speeds up your development experience by catching errors and providing fixes even
before you run your code. Some 15% of JavaScript detectable bugs could be prevented according to a research
✅ Easier to refactor code without breaking it significantly. Gives you the confidence to refactor without fear of breaking assumed, implicit contracts.
✅ Improved Developer experience: Navigating, understanding complex large size code is easier. Don't need to drill into source files and read all code implementation. You can go one level higher abstraction: rather than how you look at what the code does
✅ Helps with documentation. Automated API docs generation. More formalized and stable contracts

Cons

❌ Not true static typing, only checks the shape of the object, not its true type.
❌ Paradigm shift for developers coming from non statically typed languages, the learning curve
❌ Adding extra step — transpiling from .ts files to .js / so many options to consider.

App vs Library concerns

App perspective

More richness when you work with data. You can discover enumerations you can use, overloads of methods you can call.
Better encapsulation tools. Private, protected, public, read-only. Unintended code is hidden away from end-user
Improved "major version upgrade" experience, ie. upgrade from Lodash 3 to 4, you get immediate todo list with all those broken code showing typescript checks.

Library perspective

Create and maintain public API surface, helps with semantic version guarantees
Use enums to allow the only type encoded list of values and support for future compatibility, reserve values for future
SemVer (deprecations, breakage)
API Docs

Show me some code examples

casing/typing errors

plain old .js

let toothBrush = { name:'OracleB', price: 2.99 }

function getProductName(product) {
    console.log(product.Name); //simple case error
}

getProductName(toothBrush)  //undefined

type checking .ts

type Product= { name:string, price: number}; //type is defined here..

let toothBrush = { name:'OracleB', price: 2.99 }

function getProductName(product: Product) {
    console.log(product.Name); // !! will fail at development time
}

getProductName(toothBrush)

undefined is not a function


let myFunction;

myFunction('hello'); //Uncaught type error, not defined..

myFunction = (message)=> console.log(message);

Accidental type coercion

function addFive(num) {
    return num + 5;
}

let result = addFive('hello') // result = hello5

function addFive(num:number) { ... } // would have fixed this problem in advance.

Myths

It is not going to fix everything, won't fix bad code smells.

❌ No more runtime errors
❌ Code will run faster

Typescript Newish Features

Bulent Gorkem — Tue, 29 Dec 2020 18:04:29 +0000

Introducing useful Typescript features arrived with 3.7 and later

I learned these from the Frontend Masters course, definitely recommended 👍

Production Grade Typescript

Recursive Type References (3.7)

For example, this was not feasible in 3.6:

type ValueOrArray<T> = T | Array<ValueOrArray<T>>;

Now type declarations can recursively reference themselves.

Optional Chaining (3.7)

type ContactDetails =  {
    name: string,
    phone: string,
    address?: {
        city: string,
        street?: string,
    }
}
const myOtherFriend : ContactDetails = { name:'Some Guy', phone:'0123456766'}
console.log(myOtherFriend.address?.street);

Nullish Coalescing (3.7)

raw name is either undefined or null, not empty string, false values

this.name = rawName ?? '(no name)';

Private class fields (3.8)

3.8 adds private fields, which are a way of declaring a class field to
be unavailable outside of the containing class, including to subclasses.

class Foo {
  #name:string;
  constructor() {
    this.#name = 'whatever'; //ok here
  }  
}
const myVal = new Foo();
myVal.#name // Error! can't access name outside class Foo;

ReExport from (3.8)

With 3.8, TypeScript supports more of the export
statement forms in the JavaScript specs, letting
you write a single line to re-export a module

export * as jestConsole from "@jest/console";
export * as jestReporters from "@jest/reporters";

Variadic Tuple Types (4.0)

A variadic tuple type is a tuple type that has the same properties - defined length and the type of each element is known - but where the exact shape is yet to be defined.

The first change is that spreads in tuple type syntax can now be generic.


// spreads in tuples can be generic now
type GenericTuple<S extends unknown[]> = [first:number,  ...spread:S,  last: string];

const foo:GenericTuple<[boolean, string]> = [12,false,'aaa','aaa'];
const bar:GenericTuple<[number, string, boolean]> = [13,1,'bbb', false,'ccc'];

The second change is that rest elements can occur anywhere in a tuple – not just at the end!

type Strings = [string, string];
type Numbers = [number, number];

// [string, string, number, number, boolean]
type StrStrNumNumBool = [...Strings, ...Numbers, boolean];

Labeled tuple types (4.0)

old style tuple declaration

type Address = [ number, string, string, number];

vs this

type Address = [streetNumber: number, streetName: string, houseName: string, houseNumber: number];

now you can see tuple variables labels in intellisense

instead of this

printAddress(/*address_0*/54,/*address_1*/'regents street',/*address_2*/'whitehouse', /*address_3*/12)

you get this..

printAddress(/*streetNumber*/54,/*streeName*/'regents street',/*houseName*/'whitehouse', /*houseNumber*/12)

Template type literals (4.1)

type Features = "Redesign" | "newArtistPage";

4.1 supports a set of new generic-like keywords which
you can use inside a template literal to manipulate strings.
These are: Uppercase, Lowercase, Capitalize and Uncapitalize

type FeatureID = `${Lowercase<Features>}-id`;
type FeatureEnvVar = `${Uppercase<Features>}-ID`;

const z: FeatureID = 'redesign-id'; //works
const t: FeatureID = 'Redesign-id'; //not valid

A Micro FrontEnd Journey

Bulent Gorkem — Thu, 23 Jul 2020 16:07:41 +0000

What we need

A scalable, modular, dev-ops friendly, enterprise grade web app hosting platform (ie. Shell) which will compose multiple SPAs side-by-side and allow them to communicate with each other under a single website brand.

MFE features

Single Page Apps (SPAs) should follow Micro Services development principles, hence each SPA can be also called Micro FrontEnd following the same terminology.
MFEs should be lightweight and should focus on one business workflow (e.g one for Accounts, one for Recipients, one for Making Payment, one for Statements ...)
They can be developed using different UI Frameworks ( React, Angular, Vue, Svelte ) depending on application requirements or team's skillsets.
They should share a common look and feel via modular CSS, they can also share common functionality via WebComponents
They live independently, developed, versioned, deployed separately. Should not clash with each other when composed, no global pollution, double loading React or conflicting versions.
They are lazy loaded at runtime (they have to implement a common interface), by the hosting shell app.
They manage their own App state but also raise / subscribe to events so they can communicate with each other.

Shell features

The security context (login / logout / session monitor, permissions),
Lazy loading and layout of MFEs at runtime when routed
Lifecycle management of each MFE as they get mounted or unmounted.

What have we used to build this

Lerna to organise our sample code as a monorepo to manage independent MFEs in a single repository for convenience. In a multi team environment, this may not be desirable.
Lerna behind the scenes uses Yarn workspaces to link multiple package dependencies and install all MFEs and Shell in one go using yarn install
SystemJS Dynamic ES Module loader polyfill (which will eventually be replaced with es-modules when all browsers support import-maps). SystemJS is like AMD allows multiple assets to be dynamically loaded on demand.
SingleSPA to register and manage individual MicroFEs implemented with different FWs ( React and Svelte example here)

Where is the code

Micro FrontEnds Base

ReadMe documentation should give you all the know-how you need