DEV Community: JemalJA

React Extension components

JemalJA — Thu, 18 Feb 2021 13:24:12 +0000

Overview

Reusing React components can be tricky. You need to think twice before you try to extend a reusable component, otherwise, it might become a massive beast which can no longer be tamed. Talking from experience, you need to come up with a plan about how to extend your reusable components before you start playing with files long thousands of lines of code, which once used to be a simple Button component. This is when the idea for React extensions was born.

The idea of having extensions is to be able to build different components which can reuse each other. It was inspired by the inheritance mechanism, which you can apply on a class upon another class to retain similar implementation. This way you will have small components built with single responsibility in mind which will be easy to scale up and maintain later on.

Building React Extensions

For this example, I will build a reusable Button component which I will extend later on with additional features.

Let's start with a simple Button:

// Different button variants which will apply different styling
const btnVariants = {
  primary: "primary",
  danger: "danger",
  tertiary: "tertiary",
};

// Variant styles
const variantStyles = {
  [btnVariants.primary]: {
    background: "#1890ff",
  },
  [btnVariants.danger]: {
    background: "#f81d22",
  },
  [btnVariants.tertiary]: {
    background: "#fff",
    color: "#000",
  },
};

function BaseButton({ variant, ...props }) {
  const btnStyle = {
    color: "#fff",
    border: "none",
    padding: "5px 10px",
    ...variantStyles[variant],
  };

  return <button {...props} style={btnStyle} />;
}

Button component which has a variant prop to apply different styling. You can think of this component as the Base component from which each extension will inherit from. This component will have the functionality that every component is supposed to have and nothing else. It's very important to correctly decouple the different functionalities to build a maintainable component.

Let's build an extension which will easily allow adding an icon to the BaseButton. To do this, let's create a new React component which will reuse the BaseButton and build on top of it.

const container = {
  display: "flex",
  alignItems: "center",
};

function IconButton({ icon = "", iconPosition = "left", ...props }) {
  const iconStyle = {
    width: 20,
    height: 20,
    ...(iconPosition === "left" ? { marginRight: 10 } : { marginLeft: 10 }),
  };

  const Icon = <img src={icon} style={iconStyle} />;

  return (
    <Button {...props}>
      <div style={container}>
        {iconPosition === "left" && Icon}
        {props.children}
        {iconPosition === "right" && Icon}
      </div>
    </Button>
  );
}

The IconButton component applies two new props - icon and iconPosition which are relevant to this new component. The BaseButton doesn't need to know about them. This component is reusing the BaseButton without neglecting any of its props but building on top of.

You can assign the extensions to the base component like you are assigning a property to an object. This will allow to easily access any of the extensions while using the component.

const Button = BaseButton;
Button.WithIcon = IconButton;

<Button variant="primary">My Button</Button>
<Button.WithIcon variant="tertiary" icon="random-path/icon.jpg">My Button with Icon</Button.WithIcon>

This pattern allows building truly reusable components without the worry that they will grow to a point where we won't be able to maintain them. I hope this will find out well and will help you while working with React. Let me know what you think about this pattern.

How does an elevator works?

JemalJA — Wed, 03 Feb 2021 13:24:16 +0000

Recently I started wondering what does it take to build an elevator software? How do the current elevators work? How do they know how to prioritise their requests from all the different floors and in different directions. I started digging to find answers to those questions and I decided to write an article about it. This article will not only give answers but I will also apply my findings in practice.

Hoes does an elevator work?

Every elevator works differently based on its real-world allocation and it's fairly difficult to build such an algorithm. All algorithms might differ from each other but looking at the most basic example, an elevator is using the so-called C-SCAN algorithm. This algorithm is used for Disk Scheduling also known as I/O scheduling.

From an elevator perspective, the algorithm works as follows:

Request array represents an array storing which floors the elevator has been requested from
The elevator services always from floor 0 to the highest floor.
While moving down, the elevator does not service any of the requests.
When the elevator reaches the beginning (floor 0), reverse the direction.
While moving up, the elevator services all floors one by one.
Currently serviced floor now becomes the new position of the elevator.
Go to step 6 until the elevator reaches the highest floor.
If the elevator reaches the highest floor, reverse the direction and go to step 3 until all requests have been serviced.

Going through the steps you can see that there are some performance optimisations which can be done here. For example:

Point 3, the elevator will be quicker if it services any outstanding requests going down to floor 0.
Point 7 - there is no point of going to the highest floor if there isn't a request for that floor
Point 8 - it will make more sense to reverse the direction once the highest request has been serviced

Building the algorithm

This implementation of the algorithm will be purely functional using Vanilla Javascript. You should be able to test the code directly in the browser. The implementation will apply the proposed performance optimisations for points 3,7 and 8.

To start with let's create an elevator class
Let's assign a start method which will start processing the requests. We will pass the floor requests to it and the current floor of the elevator.

class Elevator {
  /**
   * Start service elevator requests
   * @param {number[]} requests - Floor Requests
   * @param {number} currFloor - Current Floor
   */
  start(requests = [], currFloor = 0) {}
}

Looking at requirement #2, the elevator will always go up first. We should organise the requests so we get to serve the higher floors first and then serve the floors below the current elevator floor.

class Elevator {
  minimumFloor = 0;

  /**
   * Start service elevator requests
   * @param {number[]} requests - Floor Requests
   * @param {number} currFloor - Current Floor
   */
  start(requests = [], currFloor = 0) {
    const organisedRequests = this.organiseRequests(requests, currFloor);
  }

  /**
   * Organise requests - higher floors first and then lower floors
   * @param {number[]} arr - Service Requests
   * @param {number} currFloor - Current Elevator Floor
   */
  organiseRequests(arr, currFloor) {
    const { highFloors, lowFloors } = arr.reduce(
      (acc, curr) => {
        const isHighFloor = curr >= currFloor;
        return isHighFloor
          ? {
              ...acc,
              highFloors: [...acc.highFloors, curr],
            }
          : {
              ...acc,
              lowFloors: [...acc.lowFloors, curr],
            };
      },
      { lowFloors: [], highFloors: [] }
    );

    // Sorting high floors, asc order
    highFloors.sort((a, b) => a - b);
    // Sorting low floors, desc order
    lowFloors.sort((a, b) => b - a);

    // The last floor should always be the minimum floor - 0
    return [...highFloors, ...lowFloors, this.minimumFloor];
  }
}

Let's highlight what is going on in organiseRequests.

The requests are divided into two separate lists - one for higher floors and the other one for lower floors based on the elevator's current floor.
The higher floors are sorted by ascending order, e.g. 5,6,7,8
The lower floors are sorted by descending order so when the elevator goes down, it starts picking the lowest high first to the lowest floor, e.g. 4,3,2,1.
The method returns an array with all floor lists merged into one, starting with the high floors.
The minimum possible floor is also added to the requests list as the elevator should always finish all requests on the ground floor.

Now its time to service all organised requests. To do this, the algorithm will iterate through the organised list and serve the different requests.

The function looks like this

  /**
   * Serve all elevator requests
   * @param {number[]} arr - Floor Requests
   * @param {number} currFloor - Current Floor
   */
  serviceRequests(arr, currFloor) {
    arr.forEach((currItem) => {
      currFloor = currItem;
      console.log("Floor: ", currFloor);
    });
  }

As you can see this method is servicing requests by iterating over the organised list. Another thing to mention is that the current floor of the elevator is getting assigned to the currently serviced floor. (point 6) Lastly, log the current floor in the console.

Here is the full implementation:

class Elevator {
  minimumFloor = 0;

  /**
   * Start service elevator requests
   * @param {number[]} requests - Floor Requests
   * @param {number} currFloor - Current Floor
   */
  start(requests = [], currFloor = 0) {
    const organisedRequests = this.organiseRequests(requests, currFloor);

    this.serviceRequests(organisedRequests, currFloor);
  }

  /**
   * Organise requests - higher floors first and then lower floors
   * @param {number[]} arr - Service Requests
   * @param {number} currFloor - Current Elevator Floor
   */
  organiseRequests(arr, currFloor) {
    const { highFloors, lowFloors } = arr.reduce(
      (acc, curr) => {
        const isHighFloor = curr >= currFloor;
        return isHighFloor
          ? {
              ...acc,
              highFloors: [...acc.highFloors, curr],
            }
          : {
              ...acc,
              lowFloors: [...acc.lowFloors, curr],
            };
      },
      { lowFloors: [], highFloors: [] }
    );

    // Sorting high floors, asc order
    highFloors.sort((a, b) => a - b);
    // Sorting low floors, desc order
    lowFloors.sort((a, b) => b - a);

    // The last floor should always be the minimum floor - 0
    return [...highFloors, ...lowFloors, this.minimumFloor];
  }

  /**
   * Serve all elevator requests
   * @param {number[]} arr - Floor Requests
   * @param {number} currFloor - Current Floor
   */
  serviceRequests(arr, currFloor) {
    arr.forEach((currItem) => {
      currFloor = currItem;
      console.log("Floor: ", currFloor);
    });
  }
}

Once the elevator is executed the output will be logged in the console:

function init() {
  const requests = [100, 79, 34, 67, 60, 92, 11, 55, 41, 77];
  const currFloor = 50;

  const elevator = new Elevator();
  elevator.start(requests, currFloor);
}
init();

Output:

Floor:  55
Floor:  60
Floor:  67
Floor:  77
Floor:  79
Floor:  92
Floor:  100
Floor:  41
Floor:  34
Floor:  11
Floor:  0

Conclusion

It was interesting to find out the order of which the elevator prioritises its requests. It is safe to say that an elevator's last destination will always be the ground floor.

Keep in mind this is the most basic way of how an elevator can work. There are lots of optimisations and real-world scenarios where the elevator's algorithm will be completely different than this one, probably most of the cases.

Flat is better than nested

JemalJA — Wed, 27 Jan 2021 09:20:44 +0000

Nesting code is a common feature in a programming language. While it has some advantages, it is mainly considered an anti-pattern. There are a number of problems when nesting code:

The code is hard to read
The context is hard to understand
Hard to maintain, whilst developers will try to avoid it

Let's explore different ways to invert nested conditions and make code easier to work with.

Executing functions

Inverting conditions

Consider the following example code:

function payBill(user = { isLoggedIn: false }, amount = 0) {
  if (user) {
    if (user.isLoggedIn) {
      if (amount > 0) {
        // pay the bill
      } else {
        throw new Error("Invalid amount");
      }
    } else {
      throw new Error("User needs to login");
    }
  } else {
    throw new Error("User doesnt exist");
  }
}

This code has a nesting depth of 3 and this will probably continue if we need to cover different validation scenarios. Simply by inverting the conditions we can reduce the nesting depth to 1 as follows:

function payBill(user = { isLoggedIn: false }, amount = 0) {
  if (!user) {
    throw new Error("User doesnt exist");
  }

  if (!user.isLoggedIn) {
    throw new Error("User needs to login");
  }

  if (amount <= 0) {
    throw new Error("Invalid amount");
  }

  // Pay bill
}

This code will work exactly the same way as the first example. The only difference is that it is easier to read, understand and maintain.

Early return

This is another solution that can be used in function as a guard clause before executing the function.

For example, instead of wrapping everything in a condition like this:

function doSomething(myParam) {
  if(myParam){
    // Do something here
  }
}

You can simply revert the condition and stop the execution of the function when the condition is not met.

function doSomething(myParam) {
  if(!myParam){
    return;
  }

  // Do something here
}

Loops

Building custom logic within loops is something common that we all do. We can definitely improve the way we execute loops by reducing the nested conditioning.

Here is an example with nested conditions:

const myList = ["one", "two", null, "four", "", "six"];
for (let i = 0; i < myList.length; i++) {
  const item = myList[i];
  if (item !== null) {
    if (item !== "") {
      // Do something with current item
      console.log(item);
    }
  }
}

Here is an improved version:

const myList = ["one", "two", null, "four", "", "six"];
for (let i = 0; i < myList.length; i++) {
  const item = myList[i];
  if (item === null) {
    continue;
  }

  if (item === "") {
    continue;
  }

  // Do something with current item
  console.log(item);
}

By using the continue statement, the loop stops the current iteration of the loop and continues with the next iteration. This stops the nested conditions and makes the flow more linear, either stopping the iteration to go further down the block or continue with the next item.

The same can be done with .forEach loop.

const myList = ["one", "two", null, "four", "", "six"];
myList.forEach((item) => {
  if (item === null) {
    return;
  }

  if (item === "") {
    return;
  }

  // Do something with current item
  console.log(item);
});

The return statement plays the same role as continue statement in for loop.

Conclusion

Minimizing nesting and applying these simple tricks can make your life much easier. It's not only going to make the code more readable and understandable, but it will also improve your coding style. Your teammates will thank you for that later.

Error handling without try/catch blocks

JemalJA — Wed, 20 Jan 2021 16:20:12 +0000

The try/catch statement wraps a code block within a wrapper and catches any exception thrown from that same block. When building large applications it might get a bit tedious when you have to wrap lots of parts of the code within try/catch.

Instead of getting sick of try/catch, there is another way of checking if the executable throws an error, using custom error instances.

Building custom error class

interface ICustomErrorProps extends Error {
  status?: number;
  data?: any;
}

class CustomError {
  constructor(props: ICustomErrorProps) {
    this.status = props.status;
    this.message = props.message;
    this.data = props.data;
  }

  message: ICustomErrorProps["message"];
  status?: ICustomErrorProps["status"];
  data?: ICustomErrorProps["data"];
}

The code above is building a custom error class which expects, the usual properties that can be found in an error, e.g. status, message, data.

Building an Error Validator

By using custom class, it can be easily determined what type of response has been returned by checking the instance of the response. To illustrate how to do this, here is an ErrorValidator, which will determine the type of response.

type IResponse<T> = T | CustomError;

class ErrorValidator {
  constructor() {
    this.isError = this.isError.bind(this);
    this.isSuccess = this.isSuccess.bind(this);
  }

  public isError<T>(result: IResponse<T>): result is CustomError {
    return result instanceof CustomError;
  }

  public isSuccess<T>(result: IResponse<T>): result is T {
    return !this.isError(result);
  }
}

The IResponse type defines what type the response can be - in this case either success T or error CustomError.

The ErrorValidator has two functions, isError and isSuccess. The isError function is checking if the instanceof the object is the CustomError that was defined above.

The TypeScript type predicate result is CustomError will automatically cast the result to CustomError if the returned condition is true.

ErrorValidator in action

One way to see this in action is to build an abstraction for an HTTP client. The HTTP client can extend the ErrorValidator class so the validation functions can be easily accessible by the client instance.

Here is an example of an HTTP client:

class HttpClient extends ErrorValidator {
  public async request<T>(
    url: string,
    options?: RequestInit
  ): Promise<IResponse<T>> {
    return fetch(url, options)
      .then((response) => response.json())
      .then((result: T) => result)
      .catch((error) => new CustomError(error));
  }
}

The request function of the HttpClient is returning a promise of the IResponse type defined above. The catch of the fetch creates a new instance of the CustomError which later on can be validated.

Here is an example of how to consume the HttpClient:

interface IUserDetails {
  firstName: string;
  lastName: string;
  dob: Date;
}

async function init() {
  const httpClient = new HttpClient();

  const userDetails = await httpClient.request<IUserDetails>(
    "https://my-domain.com/user-details"
  );

  if (httpClient.isError(userDetails)) {
    console.log("An error occurred: ", userDetails.message);
    // Do something with the error
    return;
  }
  console.log("API Response data: ", userDetails);
  // Do something with the success
}
init();

The main trick to bear in mind when using the custom error classes is the instanceof operator. As this is a pure JavaScript operator the same approach can be taken without TypeScript. The only difference will be that it won't apply static type checking.

Lose coupling abstractions in React using TypeScript

JemalJA — Wed, 13 Jan 2021 12:14:16 +0000

Overview

Building React components with OOP design principles in mind can really take a turn in how the component will behave in the future and how easy it will be to be used. This article is an introduction of the concept for Liskov Substitution Principle and how React components and the benefits of applying it in React.

General Idea

The idea behind the principle is that objects of a superclass should be replaceable with objects of its subclasses without breaking the application. This requires the superclass object to behave the same way as the subclass and to have the same input.

In React terms, if we remove an abstraction of a component, then the component should behave the same way as it was while using the abstraction.

Enforcing the Liskov Substitution Principle in React

Let's see this in action.
We need to build a custom React component library. One of the components we will need to use is a custom Button. The Button component will need to have the same functionality as the usual button except for the style of the button, which will be closed for modification.

The props interface for the button will look like this:

interface IButtonProps extends Omit<React.HTMLAttributes<HTMLButtonElement>, "style"> {}

Let's examine the interface.

IButtonProps extends the HTML attributes of the native HTML <button/>, e.g. React.HTMLAttributes<HTMLButtonElement>. This way we can just reuse the attributes from the native <button/> instead of writing them manually.

The beauty of this approach is that if we decide to ditch the custom Button component and just use the default <button/>, it will just work.

Another BIG plus for using this approach is that the rest of the team will already be familiar with the custom Button's interface as the props are inherited by the native HTML element.

The next thing to look at is the word Omit, used when declaring the interface. Omit is a Typescript helper which helps to unselect properties from a provided interface. Omitting multiple props can be done by using the | operator like this:

interface IButtonProps extends Omit<React.HTMLAttributes<HTMLButtonElement>, "style" | "className"> {}

Now, let's declare the custom Button component

const style = {
  // My custom Button style
};

function Button(props: IButtonProps) {
  return <button {...props} style={style} />;
}

Another thing that needs mentioning here is how the props are passed to the <button/>. To make sure that the style prop cannot be overridden by the props, by any chance, we should define the style prop after destructuring the rest of the props. This way even if style prop has been passed via the properties, it will be overridden by our custom styling. Even if someone decides to ignore the TypeScript error, this will still prevent them from passing that style.

This all looks great so far, but let's see another example.
As part of the component library, we need to build a custom Paragraph component. We need to make sure that we can apply some of the styling, e.g. text-align, font-weight... Keep in mind the idea again is to enforce the Liskov Substitution Principle.

For this example we can build our interface as shown below:

interface IParagraphProps extends React.HTMLAttributes<HTMLParagraphElement> {
  style?: Pick<
    React.CSSProperties,
    "textAlign" | "fontWeight"
  >;
}

Let's dig in and see what is happening.

The IParagraphProps extends the native HTML <p/> element's attributes. Like the custom Button, the idea is to share the same properties as the native element. The next thing defined is the style property. The word Pick is another TypeScript helper which allows to pick some of the properties from a predefined interface. In this case, the component will only allow for textAlign and fontWeight.

Let's implement the Paragraph component.

const style = {
  // My custom Paragraph style
};

function Paragraph(props: IParagraphProps) {
  return <p {...props} style={{ ...style, ...props.style }} />;
}

Conclusion

We just saw how the Liskov Substitution Principle can be enforced when building React components using TypeScript. This allows us to reuse the attributes of the native elements on the abstraction and to pick only the functionality the custom components are allowed to implement without breaking the interface between the abstraction and the native element.

Classy way of using Typescript Generics

JemalJA — Wed, 06 Jan 2021 13:51:04 +0000

Overview

Within the realms of Object-Oriented Programming, generic types are a very common and useful way to build components which can work with a variety of types instead of only one. Fortunately for us, we can do the same generic types in functional programming using TypeScript Generics.

Using generic parameters

Simple example

A simple generic parameter in a function looks like this:

function myFunc<T>(arg: T) {
  return value;
}

A generic type can be defined by using <GenericAnnotation> after the name of our function. Then simply specify the type of the argument to be the generic type. The return value of a function can also be defined as a generic type, e.g. myFunc<T>(arg: any): T

More Interesting Example

Let's have the following interface IUserDetails which specifies different user properties:

interface IUserDetails {
  firstName: string;
  lastName: string;
  age: number;
  dob: Date;
}

For the sake of this example, let's imagine that each user property needs to be updated separately. One way to do this is by writing a function for each property which can be strongly typed independently for each property.

Instead of doing that, let's build a generic function which will allow to pass any of the user properties and their correct types. Here is how that might look like:

function updateUserDetails<
  TKey extends keyof IUserDetails,
  TValue extends IUserDetails[TKey]
>(key: TKey, value: TValue) {
  // Update user details
}

Pretty cool isn't it? Let's see what the generic type constraints are doing.

There are two generics in the function, one for the key of the user property, TKey, and the other for the value of it, TValue.

TKey has a defined type constaint, specifying that it can only be one of the keys of IUserDetails interface.
TValue has a defined type constraint, specifying that the type can only be the type of the defined user property.

Calling the function like this: updateUserDetails("dob", "Jack") will throw a type error as the dob property of the interface expects a type of Date, but executing the function like updateUserDetails("firstName", "Jack") will work as it's passing the correct type forfirstName property.

Using Generic types when building React components

Typescript Generics can also be applied when building React components.

Here is an example. Let's build a List which can receive any types of list items with predefined generic constraints.

This is the bare minimum a List item object needs to have:

interface IBaseListItem {
  id: string;
  name: string;
}

The props of the list will look like this:

interface IListProps<T extends IBaseListItem> {
  title: string;
  items: T[];
}

The items[] property is defined as a generic type with a constaint which provides the bare minimum the type needs to have in order to be accepted, in this case is IBaseListItem.

The component definition can look like this:

function List<T extends IBaseListItem>(props: IListProps<T>) {
  return (
    <ul>
      {props.items.map((it) => (
        <li key={it.id}>{it.name}</li>
      ))}
    </ul>
  );
}

The react component has defined generic type which is provided to the generic props IListProps. As the generic type of the function has the same generic constraint as the IListProps, the generic type will be accepted.