DEV Community: Dawid Sibiński

5 Reasons To Not Use C# IDE For TypeScript Development

Dawid Sibiński — Sun, 05 Nov 2023 09:40:15 +0000

I know a few fellow devs who still use Visual Studio or Rider as their IDE for Typescript. If you’re one of them, this is going to be a little rant on you all 😄

In this short article, I will give you 5 reasons why your backend code editor is not the best IDE for frontend development 😉

1. Rider and Visual Studio are slow

While I consider Rider much faster than Visual Studio, even the JetBrains editor is too heavy for TypeScript development. Both of these apps are not good candidates for an IDE for TypeScript. They were designed to work with complex, backend solutions. These IDEs include a lot of features by default that can’t be turned off, most of which are not needed when working with frontend code.

This gets even worse if the solution you open contains both backend C# project and React app’s code, as it is in Visual Studio’s .NET+React template. With time, even loading such a solution takes a lot of time. Especially if you use Visual Studio with ReSharper 🙈

2. Less IntelliSense and tooling support

From my experience, Visual Studio doesn’t show as much IntelliSense info as, for instance, Visual Studio Code does. The navigation in TypeScript code doesn’t feel as smooth as it should.

When I tried to use Rider or Visual Studio as IDE for TypeScript, I had issues working with popular frontend tooling like Prettier and ESLint. Theoretically, there are plugins for both of these IDEs, but in my experience they don’t always work properly. For instance, the “Format on save” feature of Prettier often doesn’t work in Rider for me. ESLint makes Visual Studio even slower (is that even possible?! 😅).

It’s hard to fully explain if you only worked with TypeScript in Rider or Visual Studio, but I promise you that switching to VS Code makes a huge difference 🤪 Read on to get to know why!

3. Confusion of concepts

Let me explain my approach to frontend and backend first. To me, as a full stack developer, working on a frontend app requires a different mindset than working on backend. For instance, developing a React app requires me to think The React Way (we discussed it already in an article about React state management).

In my view, editing both frontend and backend code in the same editor makes you confuse concepts. If you learned JavaScript/TypeScript after working with C# for some time, you probably experienced trying to use let in C# or declaring C# types with colon (:) 😅 But this is only a tip of the iceberg.

I think having a separate IDE for TypeScript makes you nicely switch context when working on the frontend app. Opening my TypeScript code editor, I immediately start thinking in frontend. It instantly switches my approach to writing code. I somehow start to behave like a frontend developer, not a full stack one.

I think such approach is beneficial. For instance, it lets me work on my frontend code as I would be a real consumer of the backend API, not the person who can implement the backend in whichever way I want. Thanks to that switching of viewpoint, I can focus on designing my frontend code properly, without worrying about the backend.

I also tend to make less assumptions like oh no worries, I will do it on the server. At that moment, with my IDE for TypeScript open, I am a frontend developer. It often leads to better API design later on, because I don’t make any assumptions about the backend. Working on a frontend part of the app, I usually use API mocks first, knowing only the shape of data that should come from the API. Only later, when I’m done with the frontend part, I switch to Rider to actually implement the API.

Of course, this can also work the other way around. You can first work on the backend, design your API according to the best practices (again – without even thinking about your frontend app) and finally switch to the frontend IDE, build the UI and consume the API instead of using mock in the first place.

I hope you got what I mean here, but it’s not easy to clearly explain 🤪

4. Temptation to sneak C# concepts to TS

This point is a consequence of the previous one. If your IDE for TypeScript is the same as your C# code editor, you will be tempted to sneak C# concepts into TypeScript. I often see .NET developers entering TypeScript world using var by default (which is kinda deprecated in JavaScript and considered a bad practice today) or enforcing C# brackets formatting style in their frontend code. I also noticed overuse of classes and inheritance in TypeScript, as well as confusing passing value/reference data directly into components instead of properly using state and props in React.

To sum it up: isolating yourself as a frontend developer by using a TypeScript-specific IDE (like VS Code) will help you learn good frontend practices quicker 🙂

5. Because VS Code is better 😀

Last, but not least: the main reason to not use Visual Studio or Rider for TypeScript development is simple: Visual Studio Code is better!😀

VS Code is industry standard for frontend development today. According to Stack Overflow Developer Survey 2023, over 70% of all developers use Visual Studio Code:

VS Code is lightweight. It doesn’t have all heavy features included by default. If you want something additional, it must be installed as an extension. By the way, the extensions are really great and actively developed by the community.

VS Code is mostly written in TypeScript, which makes is somewhat designed for TypeScript. It has great search features, awesome IntelliSense for TypeScript and works really fast. Especially compared to Visual Studio or even Rider.

Visual Studio Code can also be run on any platform. It even has a fully-featured web version. The IDE is also completely free and open-source.

I think I won’t continue listing numerous advantages of VS Code here. If you’re reading this, and you are still not encouraged to switch to VS Code for TypeScript development, please give it a try 🙂 Or another try if you already tried, but it didn’t click. This time, first watch some introductory videos with tips on how to get started and get the most of the editor. You can also check the VS Code extensions I use on a daily basis to make your work with this editor easier.

Summary

That’s it! I really wanted to write this article one day. Do you know that feeling when you learned something new or made significant progress in some area of your life, and you see people still struggling with what you have overcome? It’s this moment when you would really love to give these people all of your knowledge and make them magically change their lives – the same way you did 😀 I feel exactly that when I see fellow developers struggling (it’s a matter of opinion, I know 😀) with Typescript in Visual Studio 🙈

I know I can’t change you and your beliefs and I don’t want to do that. But the great thing is that I can share my point of view and try to encourage you to alter yours a little. At least try and let me know what are your thoughts on that 😉

Also, if you’re a frontend or full stack developer working in a backend IDE like Rider or Visual Studio, let me know why! I’m really curious. Did you try VS Code? If yes, what didn’t fit?

The post 5 Reasons To Not Use C# IDE For TypeScript Development appeared first on CodeJourney.net.

React State Management Basics

Dawid Sibiński — Sun, 29 Oct 2023 06:49:10 +0000

If I were to point out a single concept that is critical to understand in React development, it would be state management.

So what is React state management? How is it different from managing data in C# or Java? Let’s find out! 🙂

State

If you are a backend or desktop developer, you may have never come across the term of state. At least, I never used it before learning frontend web development. Surely not in the context it is used in frameworks like React. The term more familiar to me at that time was data binding known from WPF or WinForms.

This is what WPF documentation says:

Data binding is the process that establishes a connection between the app UI and the data it displays. If the binding has the correct settings and the data provides the proper notifications, when the data changes its value, the elements that are bound to the data reflect changes automatically

In case of WPF, the crucial part to me is If the binding has the correct settings and the data provides the proper notifications (…). If you have ever worked with WPF, you know how frustrating can these notifications be (any INotifyPropertyChanged fans here?).

WPF’s state management it not that bad. However, React has something better 😉

React introduces us to a concept of state. In React components, you do not set anything directly, like calling some code to update an input’s value (this is possible, we’re still in JavaScript world, but it’s not a React way of doing stuff). You don’t directly bind your UI controls with data like you would in WPF or WinForms. Instead, you keep the data in memory, which is a current state of the UI (the whole app or a piece of it).

When the state changes, your UI is updated by React. In other words – in React, UI is a function of state :

UI = fn(state)

It means that your React app (or its individual pieces called components) take some state and output the actual, rendered UI.

This is React state management in a nutshell. Let’s explore it a bit more 😉

_Small disclaimer: _I will focus on state in React functional componets. I consider class components somewhat legacy. I think this meme summarizes it best 😀:

The Naive Way

Let’s try to approach React state management as C# developer. In React, the basic piece of UI we create is a component. Let’s add one:

import Button from "react-bootstrap/Button";

export const NaiveComponent = () => {
  return (
    <>
      <div>I am a naive component</div>
      <Button variant="success">Click me!</Button>
    </>
  );
};

For now, we render some text and a button which does nothing. What we want is to have some data displayed, like a number, which is incremented on every button click. Let’s try to implement that naively:

export const NaiveComponent = () => {
  let myCount = 0;

  return (
    <>
      <div>I am a naive component</div>
      <div>Current count: {myCount}</div>
      <Button
        variant="success"
        onClick={() => {
          myCount++;
        }}
      >
        Click me!
      </Button>
    </>
  );
};

Now, let’s check if it works:

It looks nothing happens 🥹 To investigate that, we can add a console.log (the most common debugging technique in JavaScript world 😅) to the onClick event:

onClick={() => {
          myCount++;
          console.log(myCount);
        }}

How does that look in the console now?

Woooow, something is really going wrong here! The data is updated in memory, but not reflected in the UI 🤔

Why does that happen? Because myCount is not a state. It’s just some variable we created hoping that it will work fine as part of the UI. Remember what we have discussed in the previous section – we need to start thinking in React. This is The React way, not Java way or C# way anymore.

The React Way

So, how to use React state management properly in our example? We need to make myCount be a part of component’s state. The simplest way to do that looks as follows:

export const TheReactWayComponent = () => {
  const [myCount, setMyCount] = useState(0);

  return (
    <>
      <div>I am a React Way component</div>
      <div>Current count: {myCount}</div>
      <Button
        variant="success"
        onClick={() => {
          setMyCount(myCount + 1);
        }}
      >
        Click me!
      </Button>
    </>
  );
};

First, instead of declaring a “normal” variable for storing our UI-related data, we used the useState hook. As you can see, it returns an array with two things: our state variable (myCount)and a function to update its value(setMyCount). We also set the initial value to 0. A good practice is to always use a construct like [myCount, setMyCount] to destructure what useState returns into named, separate objects.

Now we are managing our component’s state The React Way. Does it work? Let’s see:

Great! We have just learned how the basic form of state management works in React. That was easy, wasn’t it? 😉

Now, let us discuss one more aspect related to the state itself.

Reference vs value

We know the React Way for state management now. We feel confident. However, we are also used to how data is managed in C# or Java, especially in terms of handling reference and value types. This knowledge will come very handy now 🙂

Let’s try to create a bit more complex component:

type Person = {
  id: number;
  name: string;
  age: number;
};

export const ObjectHolderComponent = () => {
  const johnInitialValue: Person = {
    id: 1,
    name: "John Doe",
    age: 30,
  };

  const [john, setJohn] = useState<Person>(johnInitialValue);

  return (
    <>
      <div>ID: {john.id}</div>
      <div>Name: {john.name}</div>
      <div>Age: {john.age}</div>
      <Button
        variant="success"
        onClick={() => {
          const currentJohnObject = john;
          currentJohnObject.age = currentJohnObject.age + 1;
          console.log(currentJohnObject);
          setJohn(currentJohnObject);
        }}
      >
        Make John older
      </Button>
    </>
  );
};

Now, instead of storing a single value in our component’s state, we store a whole object of type Person. The object has a few properties: id, name and age.

There is also a button. We want this button to take the current john object, increment the value of age on it and update the state. We do it The React Way using setJohn function returned by useState. Just to be sure, we also have the console.log(john) just before updating the state. Does that work as we expected?

Eh, what’s happening here this time? We can clearly see that age is updated on the object on each click, but why isn’t the UI re-rendered? 🤔

As I mentioned before, it’s critical to understand the difference between reference and value types here. If you don’t know it, go and make up for it now.

The reason it does not work is that we haven’t updated the actual content of john state variable by calling setJohn(currentJohnObject). What is really being hold in john variable is the reference (pointer, address in memory) to the actual object. And this is what React tracks. We didn’t really update it, because we assigned the same instance of the object to the state. It doesn’t matter that we updated its internal property age – the reference itself wasn’t updated.

How do we solve that? Well, in current solution we’d need to create a copy of john object before using setJohn to alter the state. In effect, we’ll get a new instance of the object in memory and john variable will hold a new reference (address) to it.

So, if we only change our onClick implementation to this one:

onClick={() => {
          const johnCopy = { ...john };
          johnCopy.age = john.age + 1;
          setJohn(johnCopy);
        }}

Everything starts to work as expected:

I think you now understand how React state management works. I also hope that you see the issues managing state in such a way can bring. Even in this trivial example, we create a new instance of an object on every button click. Apart from memory usage considerations, this just looks ugly. Imagine manually creating copies of much more complex objects, like classes storing arrays or dictionaries. This gets pretty wild 🤪

We will see how this issue can be addressed by the end of this article. But first, let’s discuss props – another concept critical to really understand React state management.

Props

Apart from state, we also use props to control the state of our React components. The name is a short for properties, which quite well describes its purpose. Props are the data input provided to a component from outside (from a parent component). They are immutable and cannot be changed inside the component which receives them. Let’s see some examples.

Sharing state between components

The most common usage for props is sharing state between components. Imagine that you have an input, where the user manually enters some data. You want to use the current value of this input in two other components. This is where you need to share your component’s state (the value of the input) with these two other components. We often call it lifting the state up – you keep your state higher in the components tree, so the child components can use it.

Let’s try to see an example of connecting state with props:

export const PersonData = () => {
  const minimumAge = 5;
  const maximumAge = 100;
  const [age, setAge] = useState<number>(minimumAge);

  const handleAgeChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const enteredAge = parseInt(event.target.value);
    if (enteredAge >= minimumAge && enteredAge <= maximumAge) {
      setAge(enteredAge);
    }
  };

  return (
    <>
      <Form>
        <Form.Group controlId="age">
          <Form.Label>Your age</Form.Label>
          <Form.Control
            type="number"
            value={age}
            onChange={handleAgeChange}
            min={minimumAge}
            max={maximumAge}
          />
        </Form.Group>
      </Form>
      <DaysLiving currentAge={age} />
      <YearsUntilCentenarian currentAge={age} />
    </>
  );
};

As you can see, at lines 4 and 9 we manage the state variable age. This is the old stuff we have already seen.

However, at lines 27 and 28 we are passing the age state variable into DaysLiving and YearsUntilCentenarian children components as currentAge prop. This is how the DaysLiving component is implemented:

type DaysLivingProps = {
  currentAge: number;
};

export const DaysLiving = (props: DaysLivingProps) => {
  const daysLived = props.currentAge * 365;

  return (
    <div>
      <p>You have lived for {daysLived} days.</p>
    </div>
  );
};

Notice that props is simply a typed object you pass to a function component. To make things easier, you can also use object destructuring and accept the props in the following way:

export const DaysLiving = ({currentAge}: DaysLivingProps) => {
  const daysLived = currentAge * 365;
  /// ... rest of the code

That way, you don’t need to write props.currentAge every time you want to use this property inside the component.

Does changing props always trigger a re-render?

Well, generally the answer to this question is yes. Every time a prop of a component changes, this component will get re-rendered. However, this is not entirely true 🤪

To make this belief true, we need to assume that this prop is changed in a React way. So, to take things literally, consider this component we saw before:

export const DaysLiving = ({currentAge}: DaysLivingProps) => {
  const daysLived = currentAge * 365;

  return (
    <div>
      <p>You have lived for {daysLived} days.</p>
    </div>
  );
};

From its perspective only, it accepts a currentAge property. For this component to re-render, it’s not enough that the currentAge property changes in any way. Its value must be changed by mutating the state in the parent component.

So, if the value provided as currentAge to DaysLiving component changes in the parent component by properly mutating the state (with setAge mutation callback, in our case):

export const PersonData = () => {
  // ...
  const [age, setAge] = useState<number>(minimumAge);

  const handleAgeChange = (event: React.ChangeEvent<HTMLInputElement>) => {
      // ...
      setAge(enteredAge);
    }
  };

  return (
    <>
      // ...
      <DaysLiving currentAge={age} />
      // ...
    </>
  );
};

the child component (DaysLiving) will get re-rendered.

This is because when a parent component changes, React by default re-renders the parent component itself and all of its children.

If you modified the age variable in the parent compont directly, without using setAge (which we already know it’s incorrect), the currentAge prop would technically change, but the DaysLiving component will not get re-rendered.

state vs props

This is a question that people oftern ask: what’s the difference between props and state in React? 🤔

I would start with addressing this differently: what do props and state have in common?

As you already know, both are used for React state management. Both of them influence when the components will be re-rendered by React. Props and state are the absolute foundations of React.

The main difference is that state is used internally in a component, while props are used to pass information from parent to children components. State is also naturally mutable within a component where it’s defined, but props are immutable and cannot be changed in a component that receives and uses them.

React state management libraries

That’s basically everything you need to know to be able to comfortably work with React state management. However, I mentioned before that managing state using only built-in React mechanisms actually sucks 🤪 That’s why I’d like to make a short point on state management libraries.

Maybe you heard about Redux, Zustand or MobX. All of them are state management libraires for React. But why would you even need one? And should you learn one now?

In my opinion, you can easily start working with React using the built-in state management mechanisms we discussed today. It’s good to know how it works in practice. However, the truth is that as your application grows and you want to keep it scalable and maintenable, you will need a state management library at some point. As soon as your components tree gets bigger, sharing data and state will not be as easy as “passing props to a children component”. You will need to share state between multiple components in the tree, sometimes not only between parent and children, but also with another components defined on the same level or even in a totally different place of the tree.

This is where React state management libraries come very handy. They solve many of the React’s issues that come to the surface as your state gets complex. But even if you use one, you will still always need state and props. That’s why it’s critical to understand these two basic concepts first and play with them for some time.

If you’re starting out, it’s good to know that state management libraries exist and that one day you will have to get your hands on one (or more 😉) of them. I hope to share my thoughts on state management libraries in a separate article one day.

Summary

That’s it! Now you should know how React manages state of its components. Of course, we didn’t cover everything related to state management in React, but I hope you got the basics 😉

You can find all of the source code used in this article here.

How do you manage state in your React apps? Do you use a state management library? If yes, which one and why? Let me know in the comments below!

The post React State Management Basics appeared first on CodeJourney.net.

TypeScript Compiler Explained

Dawid Sibiński — Tue, 17 Oct 2023 04:08:05 +0000

As a frontend developer, one of the things you should know is how TypeScript compiler works. Sooner or later you will work with this language (which I sincerely wish you!), so it’s good to know your stuff 😉

In this article, I will explain TypeScript compiler to you in simple terms. We will avoid complex stuff – only what you need for your everyday frontend developer’s work 🙂

Few basic facts about TypeScript

For starters, let’s establish some quick facts about TypeScript as a language.

TypeScript is a superset of JavaScript

You may have heard that TypeScript is a superset of JavaScript. In other words, every JavaScript code is a valid TypeScript code. In case of TypeScript, being a “superset” means adding types information on top of perfectly legit JavaScript code.

Why is TypeScript only adding its types on top of JavaScript? In order to be able to remove them easily 🙂 But why would it do that?!

Browser doesn’t understand TypeScript

The answer is that TypeScript cannot be run directly by a web browser (or NodeJS).

Let’s take this trivial TypeScript code:

let age : number = 27;

and try to paste it into Google Chrome’s console in order to execute it:

As you can see, it fails. The number type annotation is unknown to the browser. It means that before any TypeScript code is run in the browser, the information about types must be stripped out. In the end, browsers and NodeJS environments can only execute JavaScript. This is in short what TypeScript compiler does, and we’ll get into the details soon. For now, this leads us to another conclusion, that…

TypeScript is for developers

As we have just discovered, types must be removed by the TypeScript compiler before the code can be executed by the browser. In fact, this line of TypeScript:

let age : number = 27;

produces the following JavaScript output when processed by the TypeScript compiler:

var age = 27;

This is effectively the same code we wrote in TypeScript, but without type annotations.

Wrong data types assignments will only be detected at compile time:

but as soon as it’s compiled, this protection is not there anymore 🤷‍♂️

This discovery means that TypeScript is for developers. Its job is to make our lives easier, Of course, in the end it also improves the end users’ experience, because programming in TypeScript is much better than using pure JS. But you can already see that TypeScript it not present at runtime at all. It only protects us until the compilation step by static types checking.

The philosophy is more or less as follows 😀:

What’s worth mentioning, as the language’s specification says, “TypeScript never changes the runtime behavior of JavaScript code”.

TypeScript compiler in practice

tsc

TypeScript compiler is actually a CLI tool called tsc. It can be installed globally on your machine and used directly or built into your IDE. Refer to official documentation for installation details.

The compiler can also be installed locally in your project. It can then be set up as part of the build pipeline, which is supported by many bundlers. That’s why, when working on a TypeScript project, you may never encounter any direct usages of the tsc command.

tsconfig.json

In order to make working with TypeScript compiler easier, you should use a tsconfig.json file. It’s a JSON file containing all compilation settings. This is quite important, because, in opposite to C# or Java compilers, the TypeScript’s one allows for quite extensive (and flexible) configuration.

When you use the tsc command, it looks for tsconfig.file in the current directory or any of the parent directories until it finds one. You can also provide a custom tsconfig.json location via --project parameter.

The simplest tsconfig.json file you get after initializing a new TypeScript project with tsc --init looks as follows:

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

We will not explore all the individual settings in this article. The official documentation does a great job.

TypeScript compiler – example

Let’s now see how it works.

Having a bit more complex TypeScript file as an example:

// test.ts
class Person {
  private name: string;
  private age: number;

  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }

  public getName(): string {
    return this.name;
  }

  public getAge(): number {
    return this.age;
  }
}

const person = new Person("John", 27);
console.log(person.getName()); // Output: John
console.log(person.getAge()); // Output: 27

Notice the .ts extension. This tells the compiler that this file contains TypeScript code.

Having tsc installed globally, we can compile it by executing the following command:

tsc test.ts

For the file given above, the output of this command is the following JavaScript file:

// test.js
var Person = /** @class */ (function () {
  function Person(name, age) {
    this.name = name;
    this.age = age;
  }
  Person.prototype.getName = function () {
    return this.name;
  };
  Person.prototype.getAge = function () {
    return this.age;
  };
  return Person;
})();
var person = new Person("John", 27);
console.log(person.getName()); // Output: John
console.log(person.getAge()); // Output: 27

Few things to note:

there is no information about types in the .js file. As we discussed before, this is intentional – only pure JavaScript code can be understood by the browser
notice there is no class keyword used in the compiled JS code, even though classes were introduced in ES2015. This is one of TypeScript compiler’s features – to produce code which is supported in most of the browsers and JS engines, without having to wait for support of new JavaScript versions
comments are left untouched

This explains how the TypeScript compiler works. It also confirms what we stated before, that TypeScript is for programmers. As soon as your code is deployed to production, the types you added in .ts files are absent. The way this process is built gives a lot of advantages, but it may also be a source of confusion – let’s see how exactly.

TypeScript compilation flaws

Finally, knowing how TS -> JS compilation works, let’s quickly explore some of its common flaws.

No runtime protection

As you now know, TypeScript stripes out the types during compilation. It means that the information about types is not present at runtime (when our code executes). Because of that, we are not protected by TypeScript at runtime. Consequently, if an input comes from a user and the inputs themselves are not well validated, we may still get runtime type errors. Imagine that your code expects a number, but the user enters a string because of lack of proper input validation. TypeScript will not protect you here.

The same applies to validating API responses. Most data from HTTP APIs comes in a form of JSON. In TypeScript, we can represent such data as type or interface. Based on those expected shapes of data, we use objects of a given type and assume that given properties are present on them or not. However, APIs may change, and TypeScript will again not protect us at runtime. We still need to resort to alternative solutions for runtime types validation.

To be completely clear – I don’t think that no runtime protection is something TypeScript lacks. On the contrary – I love the flexibility of TypeScript which this approach gives. It’s just how the language has been designed, and we should be aware of that 🙂

Debugging complexity

When working on a TypeScript project, the code you see on production is different from the one in your IDE. Sometimes not only types are stripped out by TypeScript compiler, but as you saw earlier it may also convert some constructs to the other (like changing a class to a function). It makes debugging, especially directly on production, more complex.

In order to place breakpoints and actually have them hit in your TypeScript code, you need source maps. It does the job in most cases, but adds to the complexity at the same time, not always working seamlessly.

TypeScript is sometimes too strict

If you decide to migrate your JS project to TypeScript, you will quickly get frustrated by how strict this new language can be. Especially if you are coming from JavaScript world where everything is allowed 😅

There are countless memes about that, but here is the one I like:

Joking apart, most things TypeScript complaints about can be configured/turned off in tsconfig.json file. This is actually what I like about TypeScript. It brings static typing into JavaScript world, but lets you control how strict you want it to be. So, if you get frustrated with TypeScript compiler’s complaints, remember about configuration options 🙂

Summary

I hope that now you feel more comfortable working with TypeScript compiler 🙂

The post TypeScript Compiler Explained appeared first on CodeJourney.net.

What Is A JavaScript Bundler?

Dawid Sibiński — Sat, 02 Sep 2023 08:16:11 +0000

If you asked me 5 years ago what a JavaScript bundler is, I’d probably tell you it’s something people fight with for hours, just to get a simple web app set up 🤪 While this might have been closer to the truth in 2018, a lot has changed in JavaScript ecosystem until today.

If you’re starting your web development journey, or maybe have already dived into it, but are not really sure what JS bundlers are and what’s their role, you’re reading a proper piece of explanation 🙂

Chaos and complexity – the issues

Let’s consider a very simple JavaScript app. We have just one page index.html. Our HTML is hydrated with index.js file, which adds some interactivity to it. In order to use it, we need to import index.js script in index.html file. We also decided to use an external library (Bootstrap), so we should also link the necessary CSS.

We are linking the index.js with a script tag in head section:

<head>
    <script type="module" src="index.js"></script>
    <link
      href="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/css/bootstrap.min.css"
      rel="stylesheet"
      integrity="sha384-rbsA2VBKQhggwzxH7pPCaAqO46MgnOM80zW1RWuH61DGLwZJEdK2Kadq2F9CUG65"
      crossorigin="anonymous"
    />
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My WebPage</title>
  </head>

Of course, as we are building a web application, we won’t put all the JavaScript code in index.js. That’s why we created two separate files with some functionalities: my-utils.js and navigation.js.

For instance, the my-utils.js exports a few functions:

export function doSomethingNice() {
  alert("Nice!");
}

export function notUsedFunctionA() {
  alert("Not used function A");
}

export function notUsedFunctionB() {
  alert("Not used function B");
}

export function notUsedFunctionC() {
  alert("Not used function C");
}

Notice the not used functions there – we’ll get to the point of them soon.

Next, our index.js file imports what it needs and adds some interactivity to the HTML elements:

import { doSomethingNice } from "./my-utils.js";
import { reloadThePage } from "./navigation.js";

document
  .getElementById("reload-page-btn")
  .addEventListener("click", reloadThePage);

document
  .getElementById("say-sth-nice-btn")
  .addEventListener("click", doSomethingNice);

If we now open our webpage, we can see the network activity when the page is loaded:

Notice that all 3 JavaScript files are fetched separately: index.js, my-utils.js and navigation.js.

What’s more, if you check the contents of my-utils.js, it obviously loads the whole script, containing even the not used functions:

I think you might already feel that this can get a little problematic 😉 Imagine managing this when you have hundreds of your own JavaScript files plus dozens of external libraries. Not only will your app be making hundreds of network requests to fetch every single file, but it will always fetch everything – even the stuff your page doesn’t use.

Here’s where a JavaScript bundler comes into the field.

You can find full source code of this JavaScript app here.

What does a JavaScript bundler do?

JavaScript bundler produces bundles 🙂 But what is a bundle? It’s basically a static file, optimized to be served to the client (in our case: a web browser). The main goal is to produce a single bundle file from multiple dependencies. In effect, the user’s browser doesn’t need to fetch so many files separately. But how is such a bundle created?

First, a JavaScript bundler needs to know the entry point. It’s a kind of root in which our “code tree” begins. In the case of our sample JavaScript application from the previous paragraph, a perfect candidate for an entry point would be the index.js file. Modern bundlers support multiple entry points. It can be very useful if you’re building a multipage application, so each page can have its own entry point.

The next step is to create a dependency graph. The JavaScript bundler is basically starting from the root (entry point) and traverses all dependencies referenced from it, as well as all of these dependencies’ dependencies. Having the dependency graph, bundler knows what is exactly used by what and in which place of our app.

This is how you can imagine the graph of dependencies:

Module bundlers like webpack not only know the dependencies of your entry point. These tools even check what each dependency uses. Thanks to building such a detailed dependency graph, the bundler can introduce multiple optimizations into the bundle file.

Finally, JavaScript bundler outputs the actual bundles. As I mentioned, bundles can be highly optimized by applying techniques like code splitting, CSS inlining, HMR and various performance optimizations.

JavaScript bundler might also ensure the backwards-compatibility with older web browsers by converting some newer JavaScript constructs used in your code to their equivalents from previous JS versions.

What’s interesting, modern bundlers can handle not only JS files, but also CSS, HTML and even images.

JavaScript bundler in action

Currently, the most popular JavaScript bundles is (still) webpack. It has been the first really advanced bundler created for both the browser and NodeJS.

You might have heard unpleasant things about webpack and in fact, its configuration can get really spaghetti 🤪 There are simpler alternatives out there, but let’s start with what’s the most common tool used in web development today.

Adding webpack to a JavaScript app

Our sample app already has a package.json file (we used JavaScript modules), so we can install webpack with this command:

npm install --save-dev webpack webpack-cli

Now we should reorganize the files a bit. Let’s put all scripts in src folder and move index.html to dist folder. Finally, it looks like that:

Using the folder named dist is very common. It stands for distributable, which means the code ready to be distributed = served to the public. This is where our bundles will be located. As the index.html is directly served to the public, we also place it there.

With such a folders structure, there’s nothing more we need to configure for webpack to work. By default, webpack looks for src/index.js file which we already have and outputs bundles into the dist folder. To use more advanced features or multiple entry points, a configuration file should be added.

In our case, let’s go with the zero-config approach. The only thing we need is to add a script entry to package.json:

 "scripts": {
    "build": "webpack",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Let’s now run npm run build and see what happens:

It seems that webpack created the main.js asset (bundle):

Let’s make sure that our index.html page links this bundle file properly:

<!DOCTYPE html>
<html lang="en">
  <head>
    <script type="module" src="main.js"></script>

Now, let’s open our index.html page and see how the network requests look like now:

Wow, that’s something different from what we had previously! Notice that now only 1 script, the main.js file, is fetched by the webpage. There were 3 before: index.js, my-utils.js and navigation.js. Of course, the web page works exactly as before.

Let us also examine the contents of the fetched main.js file:

Pay attention what happened here. Webpack has nicely inlined all the external code we used directly into the main.js bundle. What’s more, the exported, but not used functions from my-utils.js are not present here at all! When building the dependency graph, webpack noticed that those functions are not used, so it didn’t include them 😉

This is basically how webpack and most JavaScript bundlers work. Their role is to deliver the smallest and the most optimized bundles possible. This ultimately saves a lot of bandwidth by avoiding unnecessary network requests the client browser would otherwise need to make. Cutting out the unused code makes the bundles smaller, again reducing the network usage.

You can find full source code of the webpack app here.

Webpack has a lot more to offer

From all the JavaScript bundlers used today, webpack is the most advanced one. It’s the most mature one as well. It offers dozens of customizations, plugins and loaders. You can also easily add TypeScript support.

You can do really crazy stuff with webpack 😉 However, if you are starting your web development journey, don’t get overwhelmed by learning it all. Just be aware that webpack can do almost everything you might need. It’s just a matter of searching StackOverflow or asking Copilot 😉

Alternatives to webpack

In recent years, developers created a few other amazing JavaScript bundlers. I recommend you to pay attention to them, because webpack doesn’t have to be your first choice today. Webpack is still used in CRA, which is believed to be a default way of creating new React applications. This is what makes it very widely used, but you don’t need to follow this path 🙂

I recommend checking Parcel, esbuild and ViteJS. These are modern bundlers created to, among others, eliminate some of webpack’s burdens. If you’re starting out and don’t want to get yourself busy with bundling configuration, I especially recommend creating your next app with Parcel.

Summary

That’s all that you need to know about JavaScript bundlers to be able to work with them and understand what’s happening when executing this magic npm run build script 😉

The post What Is A JavaScript Bundler? appeared first on CodeJourney.net.

How (And Why?) To Wrap External Libraries?

Dawid Sibiński — Mon, 20 Feb 2023 18:40:00 +0000

If you use external libraries in your application, wrapping them may be very helpful. How to wrap external libraries and why it’s worth doing that? Today we’re going to dive into that, based on a TypeScript web app example 😉

Why?

You probably know what a wrapper is. As its name suggests, it’s a practice of putting another layer on a piece of something. In our case, wrapping a piece of code in another piece of code 🙂

But why would you do that? To make your life easier! 💪
Wrapping external libraries lets you abstract your code from their implementation details. In effect, it makes your life a lot easier when you want to keep the behavior, but change the library providing it. This approach also lets you use only those features from a given external dependency that you actually need.

Let’s see that with an example.

Wrapping HTTP client

A very good example is HTTP client wrapper. HTTP calls are used in almost every web application. In order to perform them, we need to choose an HTTP client. We can either use fetch, or something more sophisticated like axios.

However, with time, we may decide to replace it with something else. There might be many reasons for that – either the library stops to be maintained or something new and better is out there. It would be a shame if we’d now need to change the code in those thousands of places where the current library is being used. This would take a lot of time and might be error-prone. We can definitely prepare better for such cases 😉

Create HttpClient wrapper for axios

Let’s say that, for now, we will go with axios. Instead of calling it directly from our code:

// ProductsList.tsx – calling axios directly from component's code 
import { useEffect, useState } from "react";
import axios from "axios";
import { Product } from "../types/product";
import { DummyJsonProductsResult } from "../types/dummyJsonProductsResult";

export const ProductsList = () => {
  const [products, setProducts] = useState<Product[] | null>(null);

  useEffect(() => {
    axios
      .get<DummyJsonProductsResult>("https://dummyjson.com/products")
      .then((result) => {
        setProducts(result.data.products);
      });
  }, []);

 // ...
};

I will create an HttpClient wrapper for it and use it instead.

First, I create httpClient.ts file in wrappers folder. I like to have such a catalog in my React projects and keep all the wrappers there.

I start writing all wrappers with an interface. In that case, I treat the interface as a contract. It should say what I need this small wrapper to do, without worrying about implementation details.

IHttpClient interface initially looks as follows:

// httpClient.ts – IHttpClient interface (get only)
interface IHttpClient {
  get<TResponse>(url: string): Promise<TResponse>;
}

That’s what we have so far. We just need to retrieve the data with GET method.

Next step is to create the actual implementation of IHttpClient using axios. This is pretty straightforward using a class implementing IHttpClient interface and taking a look at axios‘s documentation:

// httpClient.ts – AxiosHttpClient implementation (get only)
class AxiosHttpClient implements IHttpClient {
  private instance: AxiosInstance | null = null;

  private get axiosClient(): AxiosInstance {
    return this.instance ?? this.initAxiosClient();
  }

  private initAxiosClient() {
    return axios.create();
  }

  get<TResponse>(url: string): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      this.axiosClient
        .get<TResponse, AxiosResponse<TResponse>>(url)
        .then((result) => {
          resolve(result.data);
        })
        .catch((error: Error | AxiosError) => {
          reject(error);
        });
    });
  }
}

This implementation lets us encapsulate a simple singleton inside the class.

The last step here is to expose the instance of our HTTP client. Remember to always export the interface type variable :

export const httpClient: IHttpClient = new AxiosHttpClient();

That’s basically how we wrap external libraries in TypeScript. Easy-peasy 😉

Using the wrapper

I can now use our wrapper in ProductsList.tsx component:

// ProductsList.tsx – using IHttpClient wrapper
import { useEffect, useState } from "react";
import { httpClient } from "../wrappers/httpClient"; // we don't import axios here anymore
import { Product } from "../types/product";
import { DummyJsonProductsResult } from "../types/dummyJsonProductsResult";

export const ProductsList = () => {
  const [products, setProducts] = useState<Product[] | null>(null);

  useEffect(() => {
    httpClient // instead of axios, we use our wrapper in components
      .get<DummyJsonProductsResult>("https://dummyjson.com/products")
      .then((result) => {
        setProducts(result.data.products);
      });
  }, []);

 // ...
};

Notice how easy that was. Since now, we only import stuff from axios package in httpClient.ts file. Only this single file is dependent on axios npm package. None of our components (and other project files) know about axios. Our IDE only knows that the wrapper is an object instance fulfilling IHttpClient contract:

Extra wrapper features

Apart from nicely isolating us from dependencies, wrappers have more advantages. One of them is a possibility to configure the library in a single place. In our example with axios – imagine that one day you want to add custom headers to each HTTP request. Having all API calls going via AxiosHttpClient, you can configure such things there, in a single place. That way, you follow the DRY principle and keep all the logic related to axios (or to any other external dependency) in a single place. It also comes with benefits like easy testability etc.

For clarity, I also added post support to our IHttpClient. You can check it here.

Replacing the wrapped library

Ok, it’s time to have our solution battle-tested. We have the HTTP client nicely wrapped and exposed as an instance of IHttpClient. However, we came to the conclusion that axios is not good enough, and we want to have it replaced with fetch.

Remember that in the real web application, you would have hundreds or thousands of usages of IHttpClient instance. That’s where the power of wrappers comes into play 😎

So how do I make sure those thousands of usages will now use fetch instead of axios? That’s actually pretty straightforward. I’ll simply add a new class – FetchHttpClient implementing IHttpClient interface:

// httpClient.ts – new FetchHttpClient using fetch for get and post
class FetchHttpClient implements IHttpClient {
  get<TResponse>(url: string): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      fetch(url)
        .then((response) =>
          response
            .json()
            .then((responseJson) => {
              resolve(responseJson as TResponse);
            })
            .catch((error: Error) => {
              reject(`Response JSON parsing error: ${error}`);
            })
        )
        .catch((error: Error) => {
          reject(error);
        });
    });
  }

  post<TResponse>(url: string, data?: object): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      fetch(url, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify(data),
      })
        .then((response) =>
          response
            .json()
            .then((responseJson) => {
              resolve(responseJson as TResponse);
            })
            .catch((error: Error) => {
              reject(`Response JSON parsing error: ${error}`);
            })
        )
        .catch((error: Error) => {
          reject(error);
        });
    });
  }
}

For completion, I included POST here as well.

The one last thing I have to do to make our new FetchHttpClient be used in the whole app in place of AxiosHttpClient is to change a single line with export:

export const httpClient: IHttpClient = new FetchHttpClient(); // instead of new AxiosHttpClient()

and that’s it! Our whole application now uses fetch for GET and POST HTTP requests 🙂 And it even still works 😅

Summary and source code

I hope that now you see how important it is to wrap external libraries. We have seen that on JavaScript/TypeScript app example, but this is applicable to any programming language and framework.

It’s always good to be as independent as possible of 3rd party stuff. Too many times I’ve been in a situation that some npm package is so extensively used in a project, directly in the source code in hundreds of places, that it cannot be replaced without spending several days on it. Creating wrappers forces us to think abstract, which is another great advantage.

You can find the complete source code here: https://github.com/dsibinski/codejourney/tree/main/wrapping-external-libraries

Adding Meatballs Menu To React-Table Rows

Dawid Sibiński — Mon, 06 Feb 2023 16:46:17 +0000

Meatballs menu (⋯), also called three horizontal dots menu, is a great way of providing contextual options for grid rows. In this article, I will show you how to add the meatballs menu to a table built with @tanstack/react-table.

After reading this article, you will know how to add such a menu to your React app. The end result will look as in the highlighted picture of this article 😉

Creating a table with row selection support

First, let’s define a type of data that we want to display. For our example, we will display a list of Cars:

// Car.ts
export type Car = {
  id: string;
  brand: string;
  model: string;
  productionYear: number;
  isAvailable: boolean;
};

Next, we create a new component called CarsTable, responsible for rendering the table. We will use @tanstack/react-table for the table behavior and react-bootstrap for UI elements.

I implemented the CarsTable component in quite a standard way according to react-table docs, so I won’t copy-paste it here. You can check the whole component’s code here. What’s interesting is that I added support for row selection in a way that makes our table a controlled React component:

// CarsTable.tsx – controlled row selection 
type CarsTableProps = {
  selectedCar: Car | null;
  onCarSelected: (car: Car) => void;
};
export const CarsTable = (props: CarsTableProps) => {
  return (
    // ...
    <tbody>
        {table.getRowModel().rows.map((row) => {
          const isActive = row.original.id === props.selectedCar?.id;
          return (
            <tr
              key={row.id}
              style={isActive === true ? { backgroundColor: "#3a7a11" } : undefined}
              onClick={() => {
                props.onCarSelected(row.original);
              }}
            >
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
            </tr>
          );
        })}
      </tbody>
    // ...
  )
}

As you can see, selectedCar and onCarSelected are managed from outside. See settings the style - this is how the row color gets changed for the currently selected car. I recently had to deal with such a case in one of my projects.

So far, so good. This is how it looks, populated with sample data:

Adding meatballs menu

Ok, we have a table. Now we want to add the meatballs menu. We need a three dots icon and a dropdown menu to open on clicking it.

After quickly going through the react-bootstrap docs, let’s create a new component for that:

// CarRowContextMenu.tsx
import { Dropdown } from "react-bootstrap";
import { Car } from "../types/Car";
import CustomDivToggle from "./CustomDivToggle";
import { BsThreeDots } from "react-icons/bs";

export const CarRowContextMenu = ({ carRow }: { carRow: Car }) => {
  return (
    <Dropdown key={carRow.id}>
      <Dropdown.Toggle as={CustomDivToggle} style={{ cursor: "pointer" }}>
        <BsThreeDots />
      </Dropdown.Toggle>
      <Dropdown.Menu>
        <Dropdown.Item>Option 1</Dropdown.Item>
        <Dropdown.Item>Option 2</Dropdown.Item>
      </Dropdown.Menu>
    </Dropdown>
  );
};

As we want our dropdown toggle to have custom style, I had to provide CustomDivToggle as a custom dropdown component. It’s nothing very interesting, but you can check its implementation here 😉

Next, as we’d like our meatballs menu to be an additional column in the grid, it seems natural to use react-table‘s display column. Let’s try adding it:

// CarsTable.tsx – adding meatballs menu with display-type column
columnHelper.display({
      id: "context-menu",
      cell: (cellContext) => {
        const row = cellContext.row.original;
        return <CarRowContextMenu carRow={row} />;
      },
    }),

It looks we have it:

However, after clicking through it for a while, it seems we have an issue. The toggle only opens on every 2nd click:

Why is that? The reason is our controlled CarsTable component. On clicking a new row, the change event occurs, which triggers the re-render of the CarsTable component (because selectedCar actually changes). It makes react-table re-render the table, with the meatballs menu in its default state (collapsed). On clicking the menu in the same row again, the change event occurs, but the selectedCar does not actually change, which does not trigger the re-render. Initially, it took me a while to figure that out 😀

Fixing double-click issue

In our case, a fix for the double click issue is quite simple. Instead of adding the column with the menu using columnHelper.display() function from react-table, we can render it manually. To do that, we should simply add a new <td> to each row of the table:

// CarsTable.tsx – context menu added as a separate <td>
<tbody>
        {table.getRowModel().rows.map((row) => {
          const isActive = row.original.id === props.selectedCar?.id;
          return (
            <tr
              key={row.id}
              style={isActive === true ? { backgroundColor: "#3a7a11" } : undefined}
              onClick={() => {
                props.onCarSelected(row.original);
              }}
            >
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
              <td>
                <CarRowContextMenu carRow={row.original} />
              </td>
            </tr>
          );
        })}
</tbody>

Additionally, to make it work, we need an additional table’s header placeholder:

// CarsTable.tsx – placeholder <th> for context menu
<thead>
        {table.getHeaderGroups().map((headerGroup) => (
          <tr key={headerGroup.id}>
            {headerGroup.headers.map((header) => (
              <th key={header.id}>
                {header.isPlaceholder
                  ? null
                  : flexRender(
                      header.column.columnDef.header,
                      header.getContext()
                    )}
              </th>
            ))}
            {/* placeholder header for context menu */}
            <th></th>
          </tr>
        ))}
</thead>

That’s it! Our react-table table with row selection support and the meatballs menu works like a charm now:

Meatballs menu with react-table – source code

You can find the complete source code here. I hope you find it useful! 🙂

10 VS Code Extensions I Couldn’t Live Without

Dawid Sibiński — Thu, 19 Jan 2023 19:12:07 +0000

I love VS Code 😍 There’s no better web code editor out there for me. Today, I’m going to share with you the 10 VS Code extensions that make my life easier. I can’t imagine coding without them. Let’s dive into it!

1. Prettier

My number one. I was a bit skeptical initially, but today I can’t imagine my life without Prettier 😀 For those unfamiliar with the tool, Prettier is an opinionated code formatted. Opinionated, because it allows for almost no configuration. It reformats your code automatically based on its own rules.

It may sound scary and limiting, but it really frees your mind. Suddenly you forget about all those spaces vs tabs wars and discussions on which column shall the code be wrapped. Prettier does that all automatically. It can even be done on saving the file! If you haven't yet, you should definitely give Prettier a try.

It is also very easy to execute prettier formatting with pre-commit git hook, so the checked-in code is always formatted, even if some team members don’t use it in their IDE.

Never again without Prettier! 🙂

2. ES7+ React/Redux/React-Native snippets

This is one of the first VS Code extensions I installed. It’s simple, yet very powerful! This plugin adds multiple JavaScript/React snippets. I create many new components every day. Snippets make it very easy:

I recommend trying this extension out and exploring its built-in snippets.

3. C# to TypeScript

This one is a time-saver for .NET developers working with TypeScript. It allows generating TypeScript interfaces from C# classes. You can simply copy a C# class and paste is as a TypeScript’s interface in Visual Studio Code:

You can also paste using keyboard shortcuts. There’s even a CLI tool available in case you’d want to automate this process. This extension doesn’t support all scenarios (especially no support for records 😭), but it still covers most simple copy-paste cases. By the way, synchronizing C# with TypeScript types is one of the challenges for full stack .NET developers.

4. Total TypeScript

From all VS Code extensions I use, this is the only one that actually helps me learn on the job. It was called TypeScript Error Translator before, and this is what I initially used it for. It basically provides more meaningful, crowdsourced translations for often enigmatic TypeScript errors:

When a translation is missing, you can always contribute one. Additionally, as its new name suggests, it also lets you learn programming concepts directly inside your code. As soon as it finds a new concept in the code, a brief explanation is shown:

It will stop highlighting this particular type of concept as soon as you mark it as learned. I think it’s a quite interesting way of learning on the job 😉

5. ESLint

This is the extension for integrating the most well-known linter for JavaScript into Visual Studio Code. ESLint is a static analyzer of your source code which helps you find problems quickly. It will highlight issues in your code for all loaded files from your workspace. I don’t feel there’s much to write about here – just check their website and give this extension a try 😉

6. Thunder Client

Thunder Client is like Postman, but built into VS Code. It lets you easily play with HTTP APIs. You can create your own collections of requests and export them to JSON, which can be checked into the source control.

Yet another very useful extension! 👍

7. Preview.js

This is one of my recent discoveries. Preview.js allows to live-preview React, Solid or Vue components directly in VS Code. It also generates the initial props data, sometimes even for complex objects:

The plugin is also configurable for custom scenarios like external dependencies. You can find more information in the documentation.

8. WakaTime

If you like analytics, you should check this VS Code extension. WakaTime measures how much time you spend actually writing code. It shows exactly in which language you programmed for how much time. It also divides time entries into projects you worked on:

It’s interesting to get such insights “for free” and see how little time we spend actually coding 😀 Try it for yourself and let me know your results!

9. One Dark Pro

Who never started a new project by installing fancy tools, text editors or choosing the best color theme for your IDE? 😄 Of course – good colors = smooth -and pleasant – coding 😎 One Dark Pro is a must-have theme for my Visual Studio Code. I love it, it makes source code much more readable for me. What’s your favorite color theme for VS Code? 😉

10. vscode-icons

Last but not least, a good friend to the One Dard Pro theme, legendary VS Code icons set. It has over 13M installs! 🤯

Apart from getting +100 fanciness 😉, it makes icons more explicit in the explorer:

As you can see, it even guesses the folder type based on its name – see types or utils folders’ icons above.

Not critical, yet helpful. Undeniably adds a million to your professionalism as a web developer 😎😎😎

Summary

So, that’s it! The list of my 10 favorite Visual Studio Code extensions.

What about you? What are your must-have VS Code extensions? 😉

How To Fix Visual Studio Code IntelliSense Loading Infinitely

Dawid Sibiński — Sun, 09 Oct 2022 08:57:31 +0000

Continuing with weird errors you might encounter in JavaScript world, I have another one: Visual Studio Code IntelliSense loading infinitely😀Solution included, of course!

The symptoms of this issue are putting your mouse on something where you’d expect the IntelliSense guidelines, but instead you only see the “Loading…” text.

In this short article, I’m sharing the reason of this issue and my way of fixing it.

How VS Code Infinite IntelliSense Loading Looks Like

This is what I struggled with:

As you can see, I didn’t get any IntelliSense while hovering my mouse on various elements in the editor.

A similar thing happened when I tried to use Go to References (or Shift + F12 on Windows) for any object:

As you can see, the loading bar at the top of VS Code was showing progress infinitely.

Let’s now see how to fix this annoying issue 😉

Fixing Visual Studio Code IntelliSense Loading Infinitely

After quite long investigation, I finally found the reason. It turned out that sometimes your Visual Studio Code might be using a different TypeScript version than your workspace uses. In my case, it was exactly the cause of the infinite loading problem 🧐

In order to fix it, use TypeScript: Select TypeScript Version... command. You can access commands with Ctrl + Shift + P on Windows or ⇧⌘P on Mac:

Select this command and tell Visual Studio Code to use the workspace version of TypeScript:

As you can see on the screenshot above, in my case the VS Code’s TypeScript version was 4.8.2, while the workspace version was 4.8.3. Changing it to use the newer, workspace version solved the problem. Visual Studio Code IntelliSense loading infinitely issue was gone 🎉

If it doesn’t work straightaway, you might need restarting your VS Code editor.

I hope that worked for you and saved you some hours of debugging and exploring StackOverflow 🙂

Improve your tests with Assert Object Pattern

Dawid Sibiński — Fri, 29 Jul 2022 16:42:34 +0000

Today I’d like to share with you a very interesting concept in software testing – Assert Object pattern. It makes the Assert part of a test much simpler and more readable. Let’s dive right into it !😉

The Asserts Hell

Let’s consider the following unit test:

What’s wrong here? Given and When sections are great single-liners. We know straightaway what’s the input and the action executed. However, Then block is too complex. It’s hard to figure out, just passing quickly through this test, what is expected. This case is even not that bad thanks to the usage of FluentAssertions.

I spend a lot of time writing tests, but I spend even more time reading them. I always hope that I will find these idyllic tests that act as code documentation… 🧐

However, let’s go step by step. Some time ago I attended a software testing course. That’s where I discovered the solution to The Asserts Hell.

Assert Object for Better Asserts

Assert Object pattern is what solves our problem. The idea is to create an Assert class which wraps the original object being tested. In our case, the tested object is of Product class, so our assert class will be called ProductAssert.

Let’s see the implementation:

As you can see, we simply moved the asserts from our test’s Then section into ProductAssert class’s methods. Additionally, we always return this from each asserting method, which allows chaining functions calls.

We can now use such assert object in our unit test:

You must agree, it’s much more readable now !😉

We can of course improve it even more, for example by wrapping these 3 assertion methods (BeAvailable(), HaveDiscount() and Cost()) into a single one. We can also easily create an extension method for the Product class itself, so the assert object doesn’t have to be instantiated in our unit test. I could even add an extension to FluentAssertions library.

You can find complete source code used as examples in this article here.

Assert Object – summary

I personally find Assert Object a very useful tests code refactoring method. As a programmer, you spend most of your time not on writing, but on reading the source code. Clear and simple tests can make your (and your colleagues’) life much better !😉

Of course, the Assert Object pattern should not be your default way of asserting. If you can complete your test with one or two assertions, then it’s probably better to keep it without wrapping into any additional objects. Having too many assert statements might also mean that the objects being tested are poorly designed. However, as we often work with legacy code which we can’t easily change or refactor, it might be a good solution.

What patterns for writing better tests do you use? Share your tips in the comments!

The post Improve your tests with Assert Object Pattern appeared first on CodeJourney.net.

Typing API Responses With Zod

Dawid Sibiński — Fri, 15 Jul 2022 04:54:07 +0000

Have you ever needed to synchronize types in your frontend app with the backend API?

If you ever had an API action defined like that in your controller:

and fetched this data using TypeScript in the following way:

at some point, you probably also experienced the desynchronization of backend (C#, in our example) and frontend (TypeScript) types definitions. What if someone has changed the C# version of UserViewModel, but no one corrected its TypeScript’s equivalent?

Your TypeScript fetching code will tell nothing about that. There will be no error, even though the fetched data doesn’t match the expected UserViewModel type.

I’ll try to address this issue in this article 🙂 Let’s see how typing API responses with zod can help us here.

Synchronization of Backend and Frontend API Typings

First, why would we want to keep the backend and frontend models in sync?

For me, that’s the purpose of using TypeScript. We want our code to be as well-typed as possible.

For instance, we normally want the data displayed to the user to be fully typed. TypeScript enhances our programming experience by providing us with typing information. Thanks to that, we know what is what and what contains what. We also express what types of data we expect in particular cases.

The APIs mostly return JSON data, which can be anything. Because of that, it is much easier to have the data returned from the API fully typed in TypeScript. Thanks to that, we know what properties are available on the data models received from the API and whether we can use and display them to the users.

The sample code used within this article is available on GitHub. We will use ASP.NET Core (C#) and React (TypeScript) apps as examples.

Models Synchronization Example

As we saw in the beginning, a classic example is an API controller that returns a strongly-typed data:

The returned data type is a collection of UserViewModel objects. Here’s the C# definition of this type:

Its equivalent is also defined on TypeScript side:

Usage in TypeScript

Cool. With this simple code, we can create a usersService.ts file and fetch our users’ data from the API. Notice how we make this call strongly typed:

Everything looks legit. We can use the data retrieved from the API in UsersList component and everything is nicely typed:

The data is even perfectly displayed:

So, what can go wrong here? 🤔

The Problem – Typings’ Desynchronization

Let’s say that a backend developer implements a requirement to rename “loyalty points” into “fidelity points”. Easy. (S)he renames LoyaltyPoints property in the C#’s UserViewModel to FidelityPoints.

The new C# model looks as follows:

Nice! The backend dev is a very good programmer, so (s)he even launches the React web application to make sure that everything still works correctly and there are no errors in the dev console:

After a quick look, everything looks awesome. The users list is displayed, there are no errors in the console. Apparently, these test users don’t have any loyalty points assigned – that’s why the empty values in “Loyalty points” column. What’s more, translators will update the column’s translation later. We are good! Let’s go on prod! 😎

I guess you already know what went wrong here. API definition changed, but TypeScript didn’t inform us about that 😔 Our UserViewModel still uses the old property name:

However, it still works. When rendering the UsersList, we simply get undefined in place of loyaltyPoints:

In the end, this is all JavaScript there. What’s interesting, the renamed fidelityPoints property is already there at runtime:

but no one cared about it 😔

With the current solution, we will never be informed soon enough about API models changes in our React application. In the best case, we’ll get an undefiend or null error when clicking through the app. However, it’s usually an end user who finds such problems on production. This is definitely not what we want 😶

We can solve this problem by typing API responses with zod. Let’s now see how to do that.

The Solution – zod

Our remedy – zod – is quite a decent npm package with ~600k weekly downloads. Its GitHub page advertises the library as TypeScript-first schema validation with static type inference.

You can definitely do many things with zod. It can be used together with libraries like react-hook-form to perform complex forms validation. However, in our case, we’ll treat zod as a solution for better typings in TypeScript.

Adding zod to React app

First, let’s install zod into our React application:

npm i zod

First Schema Definition with zod

With zod, we define our types in a slightly different way. Instead of creating a type or interface directly, we first create a schema. In our case, we can define a UserViewModelSchema using z.object creator function:

Few interesting parts here:

Line 2: notice how zod helps us to define types like Guid with built-in schemas like uuid()
Line 8: first, I used AddressViewModelSchema here. This is a custom schema of an AddressViewModel object, which is another type used internally in UserViewModel. You can use such custom schemas in other schemas. Also notice the nullable() call here, which makes the address property nullable

First step done – we have our UserViewModelSchema. But can we use it instead of UserViewModel type? Not really. Schema is used for validation purposes only. We still need the UserViewModel TypeScript’s type.

Inferring Type From zod’s Schema

Fortunately, zod comes with a handy z.infer function that allows us to infer the type from the schema.

Finally, the userViewModel.ts file looks as follows:

We can use the exported UserViewModel type as previously used type. It’s an equivalent to the previous, "classic" type we had defined, but this time inferred from UserViewModelSchema.

Validating API Eesponses With zod Schema

One last step is to make use of UserViewModelSchema. Let’s modify the getAllUsers function from usersService to validate the data received from the API against our schema:

Notice the usage of z.array. This function call tells zod to validate an array of objects meeting the rules defined by UserViewModelSchema, not a single object.

Now, let’s run our React app and see what happens when we click the “Fetch users” button:

This is awesome! Exactly what we wanted – a schema validation error for API response. Notice how the error message precisely points to the missing (or wrong, in other cases) property. It tells us we expected a number called loyaltyPoints, but instead we received undefined. The reason for this error message is that the loyaltyPoints field is Required in our schema.

After renaming loyaltyPoints to fidelityPoints in UserViewModelSchema and updating the UsersList component accordingly, everything works fine again.

We are now fully typed and prepared for the future, in case an issue with desynchronization of frontend and backend typings happens again 🚀

Summary

Today, we’ve seen how typing API responses with zod can help us detect frontend and backend models desynchronization. Schema validation throws errors when the data doesn’t match its expected shape.

Remember that zod is an extended library with many options. I recommend exploring them on your own. An interesting feature we didn’t cover in this article is strict mode, which doesn’t allow additional fields not present in the schema definition when validating the data object.

The open question remains whether to use schema validation on production. One could think that it’s better to not throw any validation errors, because JavaScript may just work. However, I think that throwing an error is always better than silently letting things through. An error lets programmers, automated tests or manual testers to detect the issue before the end user does 😉

You can explore the complete code presented in this article here.