Forem: Belghith Omar

Typescript Made Easy - Part 1

Belghith Omar — Mon, 20 Feb 2023 11:10:24 +0000

Build Your own Types From Scratch

Are you ready to take your Typescript skills to the next level? In this Series of Blog Posts, we will see how to build our own custom Typescript types from scratch. Typescript types are the building blocks of your code, and they allow you to create more robust and flexible applications. Whether you're a beginner or an experienced developer, learning how to create custom types will help you write better code and improve your productivity. So, what are you waiting for? Let's dive in and explore 10 different typescript types that will supercharge your development process!

The `Pick` Type

Have you ever needed to create a new type that only includes a subset of the properties from an existing type? If so, the Pick type in Typescript has got you covered. With just a few lines of code, you can create a new type that selects the properties you need and leaves the rest behind.

type Pick<T, K extends keyof T> = { [P in K]: T[P] }

Under the hood, Pick is implemented using a generic type alias that takes two type parameters: T (the original type) and K (a union of keys from T). The resulting type has the same keys as K, but their values come from the corresponding properties in T. This can be incredibly useful when working with large data structures or defining props for React components.

The `Readonly` Type

The Readonly type in Typescript creates a new type where all properties of an object are readonly. This can be useful when you need to ensure that an object's properties can't be modified after they're initialized. Here's the code for Readonly under the hood:

type Readonly<T> = {readonly [K in keyof T]: T[K]}

The Readonly type uses a mapped type to iterate over the keys in T and create a new type that has the same keys, but all of their values are readonly. This can make your code more robust and less error-prone, especially when working with large or complex data structures. This can be useful in many contexts, such as when defining configuration objects, constants, or state variables.

The `First` Type

The First type in Typescript is a generic type that takes an array type T and returns the type of its first element. This type is useful when you need to work with arrays and want to ensure that the first element has a certain type. There are two ways to implement First in Typescript.

The first way is to simply use T[0] to get the type of the first element.

type First<T extends any[]> = T[0]

However, this approach has a flaw, when the array is empty, T[0] will return undefined, which is not ideal.
To avoid this, we can use the second approach: T extends [] ? never : T[0]. This will check if the type of T is an empty array. If it is, it returns never, which is a type that cannot be instantiated. If it is not empty, it returns the type of the first element, which is T[0]. Here's the code for updated First:

type First<T extends any[]> = T extends [] ? never : T[0];

The `Length` Type

The Length type in Typescript is a generic type that takes an array type T and returns the length of that array as a number. This can be useful when you want to ensure that a given array has a certain number of elements or when you want to perform operations based on the length of an array. Here's the code for Length under the hood:

type Length<T extends readonly any[]> = T['length']

The Length type uses a type alias that takes a single type parameter T, which extends an array of any readonly types. Then, it simply returns the 'length' property of T. This is a concise way to get the length of an array in Typescript, which can save you time and improve your code's readability.

The `Exclude` Type

Have you ever needed to create a new type that excludes some types from another type? If so, the Exclude type in TypeScript can be a powerful tool. With a concise implementation, you can create a new type that removes the undesired types.

type Exclude<T, U> = T extends U ? never : T;

The Exclude type uses conditional types to check whether each element of T is assignable to U. If it is, the type never is returned, which represents a type that can never be instantiated. If it is not assignable to U, the original type T is returned.

The `Omit` Type

The Omit type in Typescript is similar to Pick, but it creates a new type that excludes a subset of properties from an existing type. This can be useful when you need to create a new type that has most of the properties of an existing type, but with some of them omitted.
Here is the implementation of Omit under the hood:

type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

As you can see, Omit uses Pick and Exclude to select a subset of properties from T and exclude them from the resulting type. The resulting type has all the properties of T, except for the properties listed in K.

The `Required` Type

The Required type in Typescript creates a new type where all properties of an object are required. This can be useful when you need to ensure that an object has all the required properties before it can be used. Here's the implementation of Required under the hood:

type Required<T> = { [P in keyof T]-?: T[P] };

Required uses a mapped type to iterate over the keys in T and create a new type that has the same keys, but all of their values are required. The -? syntax in the mapped type makes each property required. This can make your code more robust and less error-prone, especially when working with objects that require certain properties to be present.

The `Partial` Type

The Partial type in Typescript creates a new type where all properties of an object are optional. This can be useful when you need to create an object that doesn't require all the properties to be set initially. Here's the implementation of Partial under the hood:

type Partial<T> = { [P in keyof T]?: T[P] };

Partial uses a mapped type to iterate over the keys in T and create a new type that has the same keys, but all of their values are optional. The ? syntax in the mapped type makes each property optional. This can be useful when working with configuration objects, where not all properties are required, or when dealing with optional props in React components.

The `Record` Type

The Record type in Typescript creates a new type where the keys and values have a specific type. This can be useful when you need to define an object with a fixed set of keys and corresponding types.
Here's the implementation of Record under the hood:

type Record<K extends keyof any, T> = { [P in K]: T };

Record takes two type parameters: K (the keys) and T (the values). It uses a mapped type to iterate over the keys in K and create a new type that has the same keys, but all of their values are of type T. This can be useful when working with dictionaries or maps, or when you need to define a fixed set of keys for a particular object.

The `Nullable` Type

The Nullable type in TypeScript allows you to create a new type that includes the original type as well as null and undefined. Here's how it's implemented under the hood:

type Nullable<T> = T | null | undefined;

The Nullable type is implemented as a simple union type that includes the original type T, as well as null and undefined. This can be useful when you want to allow a property to be null or undefined, but still want to maintain the original type.

Conclusion

Learning how to build TypeScript types can take your coding skills to the next level! We've covered ten powerful types that can make your code more flexible and robust. Whether you're using Pick or Omit, these types can save you time and make your code more readable.

Don't forget to leave a comment if you liked the blog or you have some questions.
Follow us, and share your experiences with these types in the comments.
I will be exploring another set of TypeScript types in the next part of this blog series. And based on your feedback we can improve how we present these explanations to you

Thanks for reading, and happy coding!

Resources:

Testing File Upload Component with RTL

Belghith Omar — Sun, 15 Jan 2023 11:18:08 +0000

React Testing Library

React Testing Library is a testing framework for React applications that helps you test the behaviour of your components rather than their implementation details. It is built on top of DOM Testing Library, which is a set of utilities for testing web pages. The main advantage of using React Testing Library over other testing frameworks, such as Enzyme, is that it encourages testing in a way that is more similar to how a user interacts with the application.

File Upload Component

import React, { useState } from 'react';
interface Props {
    onSubmit: (file: File) => void;
}
const FileUpload: React.FC<Props> = ({ onSubmit }) => {
    const [file, setFile] = useState<File | null>(null);

    const handleFileSelect = (e: React.ChangeEvent<HTMLInputElement>) => {
        setFile(e.target.files?.[0]);
    };
    const handleSubmit = (e: React.FormEvent) => {
        e.preventDefault();
        if(file){
            onSubmit(file);
        }
    };
    return (
        <form onSubmit={handleSubmit}>
            <input
                type="file"
                onChange={handleFileSelect}
                data-testid="file-input"
            />
            {file && <p data-testid="file-name">{file.name}</p>}
            <button type="submit" data-testid="submit-button">
                Upload
            </button>
        </form>
    );
};
export default FileUpload;

This component uses React's useState hook to keep track of the selected file, and it has an input field of type "file" which allows the user to select a file. When the form is submitted, it calls the onSubmit function and passes the selected file as a parameter.

It also includes data-testid attributes in the input and button elements, so that you can select them in your tests with RTL's getByTestId function.

Testing the File Upload Component with RTL

To test a file upload component with React Testing Library (RTL) and TypeScript, you can follow these steps:

Import the necessary modules: In addition to RTL, you will also need to import the component you want to test and any additional modules it depends on.
Create the test: Use the render function from RTL to render the component, and the fireEvent function to simulate a file being selected and the form is submitted.
Test the component's behaviour: Once the component is rendered, you can use RTL's getBy* functions to select elements within the component and make assertions about their behaviour. For example, you can check that the component displays the selected file's name and that the form's onSubmit function is called when the form is submitted.
Test the component's state: you can use the debug() function to check the component's state, it will show the component's html code and you can check that the component's state is updated correctly when the file is selected and the form is submitted.

Here is an example of how your test file might look like:

import { render, fireEvent, waitFor, debug } from '@testing-library/react';
import FileUpload from './fileUpload';

describe('FileUpload', () => {
    it('should display the selected file name', async () => {
        const { getByTestId } = render(<FileUpload />);

        const fileInput = getByTestId('file-input');
        const file = new File(['test file content'], 'test.txt', {
            type: 'text/plain',
        });
        fireEvent.change(fileInput, { target: { files: [file] } });

        const fileName = getByTestId('file-name');
        expect(fileName.textContent).toBe('test.txt');
    });

    it('should call the onSubmit function when the form is submitted', async () => {
        const onSubmit = jest.fn();
        const { getByTestId } = render(<FileUpload onSubmit={onSubmit} />);

        const fileInput = getByTestId('file-input');
        const file = new File(['test file content'], 'test.txt', {
            type: 'text/plain',
        });
        fireEvent.change(fileInput, { target: { files: [file] } });

        const submitButton = getByTestId('submit-button');
        fireEvent.click(submitButton);

        expect(onSubmit).toHaveBeenCalled();
        debug()
    });
});

Keep in mind that you should focus on testing the component's behavior rather than its implementation details. You should also test the component with different kind of files, empty files, or even no files at all.

File Upload Component that accepts only JPEG

import React, { useState } from 'react';

interface Props {
    onSubmit: (file: File) => void;
}
const FileUpload: React.FC<Props> = ({ onSubmit }) => {
    const [file, setFile] = useState<File | null>(null);
    const handleFileSelect = (e: React.ChangeEvent<HTMLInputElement>) => {
        const selectedFile = e.target.files?.[0];
        if (selectedFile && selectedFile.type === 'image/jpeg') {
            setFile(selectedFile);
        }
    };

    const handleSubmit = (e: React.FormEvent) => {
        e.preventDefault();
        if(file){
            onSubmit(file);
        }
    };

    return (
        <form onSubmit={handleSubmit}>
            <input
                type="file"
                accept="image/jpeg"
                onChange={handleFileSelect}
                data-testid="file-input"
            />
            {file && <p data-testid="file-name">{file.name}</p>}
            <button type="submit" data-testid="submit-button">
                Upload
            </button>
        </form>
    );
};
export default FileUpload;

In this version, I added an accept attribute to the file input element, which tells the browser to only display files that are of type image/jpeg.

I also added a check in the handleFileSelect function to make sure the selected file is of type 'image/jpeg' before setting the state.

In this way, you ensure that the user can only select JPEG files, and that the component only accepts and processes JPEG files, so you can be sure that you are working with the correct type of file.

Testing the modified File Upload Component

import { render, fireEvent, waitFor, debug } from '@testing-library/react';
import FileUpload from './fileUpload'

describe('FileUpload', () => {
    it('should display the selected file name', async () => {
        const { getByTestId } = render(<FileUpload />);

        const fileInput = getByTestId('file-input');
        const file = new File(['test file content'], 'test.jpg', {
            type: 'image/jpeg',
        });
        fireEvent.change(fileInput, { target: { files: [file] } });

        const fileName = getByTestId('file-name');
        expect(fileName.textContent).toBe('test.jpg');
    });

    it('should not display the selected file name and not call the onSubmit function when the file is not JPEG', async () => {
        const onSubmit = jest.fn();
        const { getByTestId } = render(<FileUpload onSubmit={onSubmit} />);

        const fileInput = getByTestId('file-input');
        const file = new File(['test file content'], 'test.txt', {
            type: 'text/plain',
        });
        fireEvent.change(fileInput, { target: { files: [file] } });

        const submitButton = getByTestId('submit-button');
        fireEvent.click(submitButton);

        const fileName = getByTestId('file-name');
        expect(fileName).toBe(null);
        expect(onSubmit).not.toHaveBeenCalled();
    });

    it('should call the onSubmit function when the form is submitted', async () => {
        const onSubmit = jest.fn();
        const { getByTestId } = render(<FileUpload onSubmit={onSubmit} />);

        const fileInput = getByTestId('file-input');
        const file = new File(['test file content'], 'test.jpg', {
            type: 'image/jpeg',
        });
        fireEvent.change(file
        fireEvent.change(fileInput, { target: { files: [file] } });

        const submitButton = getByTestId('submit-button');
        fireEvent.click(submitButton);

        expect(onSubmit).toHaveBeenCalled();
        debug()
    });
});

In this test case, I added a test that simulates the user selecting a file that is not of type image/jpeg, and asserts that the component does not display the file name and does not call the onSubmit function.

I also updated the existing test case that selects a file to use a JPEG file instead of a plain text file. And also the test case asserts that the component displays the selected file name and that the form's onSubmit function is called when the form is submitted.

It is also a good idea to add test cases that cover edge cases, like when the user tries to submit the form without selecting a file, or when the user selects multiple files.

Please keep in mind that this is just an example, and you will need to adjust the test to match the specific implementation of your component.

Conclusion

In conclusion, testing file upload components can be a bit tricky, as it involves both the component's behaviour and the file handling. To ensure that the component is working correctly, it is important to test the component's behaviour with different types of files, including valid and invalid file types, and also test the component's behaviour when the user tries to submit the form without selecting a file, or when the user selects multiple files.

React Testing Library (RTL) is a great tool for testing React components and it provides a lot of useful functions that help you test the component's behaviour.

It's worth noting that, when testing file upload components, you should focus on testing the component's behaviour rather than its implementation details.

I hope this blog post was helpful and if you liked it and found it helpful, please don't hesitate to hit the like button and follow me for more, also if you have any specific component you would like me to test with RTL feel free to comment and I will be happy to help.

Interview Process Landscape in Tech Companies

Belghith Omar — Fri, 28 Oct 2022 21:57:56 +0000

TLDR;

This document Explains how the process of interviewing in different levels of companies (Big Tech, Medium, Start up) looks like. We need to understand what is the current landscape of the interview process in Tech companies to better prepare for them. In this article we will detail every step you will encounter and how it is done in reality.

Interview Process Landscape in Big Tech Companies

Step 1: CV Screening

In big tech companies, usually you will find a high usage of AI based programs to do the screening process. These AI programs, will usually select a handful of candidates that much a handful of criteria. Then the recommended CVs will be screened again by hiring managers and tech recruiters. Thus, the CV screening process usually contains multiple layers of evaluation.
Tech recruiters, often find these AI based screening programs are flawless. They can get easily confused by fancy words, or something else. So, it is still very much important to involve a human being in the screening process.
This is the second round screening. After all this process, the CVs are usually sent to the interview managers, who will call the top candidates and get them to the interviews.
From here, the questions in the interview will be the final major step in order to make or break the hiring process.
This is a general workflow. The way different companies work is different from each other, even though there are a lot of similarities.

Step 2: Coding Assignment

In this step, Candidates are presented with a set of 2 problems that they need to fix in a constrained time. The problems are generally complex and revolve around Algorithms and Data structures. Companies want to evaluate how good are candidates at taking an existing piece of code, identify the issues with it, and come up with a solution. Candidates should be able to: Understand the problem, break the larger problem into smaller and more manageable chunks, choose the appropriate data structure to handle and store data, analyze the running time of different algorithms and pick the most optimum one.
You should be good at solving at least 2 problems in the time constraint. Candidates who clear this step get promoted to the next level. In addition to this, candidates are judged on the efficiency with which they solved the code. Hence, candidates need to solve the problems in the most optimal, clear and efficient way.

Step 3: Live Coding Interview

In this step, you are usually presented with a problem that reflects your job description. This challenge will assess multiple aspects of your programming knowledge and will include live coding, which means that you need to get the solution worked out on your screen in front of a panel of people. It is essential that you remember that the company wants to see how good you are at working in a team and how confident you are about the language you know.

Front End Developers:
- You will usually be presented with an in house challenge using the front end framework of their choice. Keep in mind that this isn't about how long it takes you to complete the challenge, but how clean and efficient your code is. The live coding part will also include JS frameworks and patterns like MVC, MV*. They may also ask you to build a mock-up of a page based on their UI standards.
- You will be presented with something that looks most likely like this
Back End Developers:
- You will usually be presented with a problem that is based on web development, database and network programming. The challenge will assess multiple things. How well are you able to solve a problem? How can you write clean, maintainable and efficient code? In this problem, you will be faced with creating APIs and connecting them to databases. You will be expected to write a program that can work with big datasets and how you go about doing it. You will be expected to come up with code that will be scalable and extensible.

Step 4: On site Interview

The onsite technical interview is unlike any other job interview: it’s a specialized, rigorous process that tests your coding skills, problem-solving abilities, and personality. You have to prove that you have the skills required to do the job, rather than just tell the interviewers that you have them.
An onsite interview happens in person, at the company’s office or virtually. The onsite usually consists of 2–6 individual, one-on-one technical interviews (usually in a small conference room). Each interview will be about an hour and have the same basic form as a phone screen—technical questions, book ended by some chitchat at the beginning and a chance for you to ask questions at the end.
If a technical phone interview is a sprint, an onsite is a marathon. The day can get really long. Best to keep it open—don’t make other plans for the afternoon or evening.
The onsite interview will usually encompass all of these different software engineering principles:

System design Interview: In this interview, you will be asked to design a software application. You will be trying to architect the different parts of the requirements defined by the interviewer.
Class Design Interview: In this interview, you will be given a class, and then asked multiple questions on it. The requirements will start increasing along the way, you will have to design a class that follows SOLID engineering principles.
Coding Interview: In this interview, everything will be revolved around your problem-solving capabilities. You will be given a prompt where you need to write an algorithm that will test how you approach the problem. In fact, you have to show all your work along the way, be as concise as possible. This interview's theme is usually Data Structure and algorithms.

Interview Landscape in Small to medium Companies

Step 1: Call with a recruiter/HR

After you send in your application, usually someone from the HR department will get in touch with you after a few days if they think your profile suits the role. If you applied through a recruiter, then the recruiter might be the one letting you know. This round consists of general, non-technical questions about your background, motivation and experience, and your salary expectations.

Step 2: Call or meeting with tech team

This step might or might not happen depending on the company. The call with the HR is sometimes followed by a call or an on-site meeting with someone from the tech team. This is an opportunity for you to get to know them and for them to get to know you to make sure you are a good fit for each other. They will usually ask you more details about your technical and non-technical skills and previous experience, and you have the chance to ask for more details about the tasks and responsibilities that the role entails. Although the technical questions are important, do not underestimate the importance of non-technical questions, such as those about your motivation and soft skills.

Step 3: Coding test or take-home coding assignment

The next round usually involves you solving a coding test or a coding assignment. Coding tests are either held online on a platform, such as Hackerrank, DevSkiller or Codility where you have to solve a set of problems on the platform within a given time, or live where you are given one or more problems in person or via a video call and have to solve it while the interviewer reviews your solution simultaneously. Succeeding in coding tests needs practice and some understanding of the common patterns underlying the questions.

Conclusion

You may encounter various interview formats in your software engineer interviews (from early to late stage):

1. Quiz

Frequency: Occasional

Quizzes are meant to be a first-pass filter as a quick and dirty way of weeding out extremely weak (or even non-technical) candidates. They are structured questions and have clear-cut answers, which makes them possible to be administered by recruiters/non-technical folks or automated graders. They are typically done early in the process.
Examples:

What is 4 & 5 (in binary)? Answer: 4
What is the time complexity of bubble sort? Answer: O(n2)

2. Online coding assessment

Frequency: Frequent

Like quizzes, online coding assessments are more frequently given early in the process. An algorithm problem is given with well-formed input and output, and candidates are expected to write code in an online coding interface to solve the problem. HackerRank is a very common platform for conducting online coding assessments. LeetCode would be a good way to practice for the problem-solving aspects of online coding assessments.

3. Take home assignment

Frequency: Rare

There have been numerous debates on whether asking algorithm questions are a good way of assessing individual abilities as they aren't exactly the most relevant skills needed on a day-to-day basis at a job. Take home assignment is a format designed to address the shortcomings of the algorithm interview by getting candidates to work on larger projects which allow them to demonstrate software design skills.
However, this interview format takes up more time from both the candidates and the company and hence it is not as commonly seen in large companies where they have a high volume of candidates. This format is more common among startups and small companies. Examples

Build a flights listing app
Build a kanban app
Build a snake game

4. Phone screen interviews

Frequency: Common

Phone interviews are the most common format and every candidate will face this at least once while interviewing. You will be asked to speak with an interviewer either over a phone call or VoIP (BlueJeans/Skype/Google Hangout). A question will be given to you and you will work on that question using an online collaborative editor (CoderPad/CodePen/Google Docs).
You are usually not allowed to execute the code even if the editor supports execution. So don't rely on that for verifying the correctness of your solution. Formats would differ slightly depending on the roles you are applying to. Many companies like to use CoderPad for collaborative code editing. CoderPad supports running of the program, so it is possible that you will be asked to fix your code such that it can be run. For front end interviews, many companies like to use CodePen, or CodeSandbox, and it will be worth your time to familiarize yourself with the user interfaces of such web-based coding environments.

5. Onsite

Frequency: Always(Big Tech), Rare(Small to Medium)

If you have made it to this stage, congratulations! This is usually the final stage before an offer decision. Candidates who made it to the onsite stage will be required to have an in-person interview at the office. If you are an overseas candidate, companies might even fly you in and pay for your accommodations!
The onsite stage usually consists of multiple rounds (coding, system design, behavioral) and is expected to last for a few hours. Since you are onsite, it is possible that you will be asked to do a whiteboard exercise with an interviewer, usually either solving an algorithm question or a system design question. It is also possible that you have to bring your own laptop and work on a project/solve a coding problem on the spot.
For onsite interviews at smaller (non-public) companies, most will allow (and prefer) that you use your own laptop. Hence it is important that you prepare your development environment in advance.

Forem: Belghith Omar

Typescript Made Easy - Part 1

Build Your own Types From Scratch

The Pick Type

The Readonly Type

The First Type

The Length Type

The Exclude Type

The Omit Type

The Required Type

The Partial Type

The Record Type

The Nullable Type

Conclusion

Resources:

Testing File Upload Component with RTL

React Testing Library

File Upload Component

Testing the File Upload Component with RTL

File Upload Component that accepts only JPEG

Testing the modified File Upload Component

Conclusion

Interview Process Landscape in Tech Companies

TLDR;

Interview Process Landscape in Big Tech Companies

Step 1: CV Screening

Step 2: Coding Assignment

Step 3: Live Coding Interview

Step 4: On site Interview

Interview Landscape in Small to medium Companies

Step 1: Call with a recruiter/HR

Step 2: Call or meeting with tech team

Step 3: Coding test or take-home coding assignment

Conclusion

1. Quiz

2. Online coding assessment

3. Take home assignment

4. Phone screen interviews

5. Onsite

The `Pick` Type

The `Readonly` Type

The `First` Type

The `Length` Type

The `Exclude` Type

The `Omit` Type

The `Required` Type

The `Partial` Type

The `Record` Type

The `Nullable` Type