The answer to all these questions is mutation testing. Interested? Read on

Code Coverage – Our Old Friend

You probably know what code coverage is. Traditionally, many teams tend to measure how good their tests’ suite is by percentage line / statements / functions coverage. Some even require this metric to be 100%. Let’s start with this well-known approach first.

We are working with TicketsPriceCalculator class today. It contains some simple business logic:

As you can see, the class has one function whith returns the total price to be paid for a set of tickets. On the way, it applies various discounts based on some business rules. Fair enough.

It’s a critical piece of business logic for the app we’re working on, but it has never had any tests. We were asked to write unit tests for this class. Our manager strictly requires the code coverage to be 100%. Let’s do it then. We will go line by line, analyze the business logic and add the tests. Below, you can see the results of running those tests (you can find the tests code here):

Wow, that’s awesome! We did a great job. We have 8 unit tests which provide 100% statements, branch, functions and lines coverage!

So now we are really safe, aren’t we?

Yeah… until you know what mutation testing is

What Is Mutation Testing?

The idea of mutation testing is to mutate (change) our code. Mutation testing tools introduce changes into our production code. These changes can be really anything – from reverting a condition of an if statement, to changing some operators or changing a string value. For instance, here are some logical mutations Stryker Mutator is able to introduce (you can find the list of all mutations supported by Stryker here):

In effect, they generate modified versions of our code, which are called mutants. Makes sense

Each mutant contains a single modification in our source code. What happens next is crucial. Mutation testing tool takes this mutant (it is used as the code under tests now) and executes all of our unit tests against it. The result may be twofold:

• all tests have passed. In other words, the mutant has survived. This is a bad situation. It implies that the modification of our source code was not detected by our tests
• at least one test has failed. In other words, the mutant has been killed. This is a good scenario. It means that our tests detect changes in the production code and efficiently cover this particular scenario.

The flow is more or less like this schema from Peter Evans’ blog presents:

But why would anyone change the production code on purpose by introducing some stupid changes? It may seem counterintuitive for now, but let’s see how we can use it to our leverage.

Mutation Testing with Stryker Mutator

Let’s clearly state what we are starting with:

8 unit tests, 100% code coverage

Let’s now run mutation testing on our code. We are using TypeScript here, so let’s go with Stryker Mutator.

Here’s the result of running Stryker with npx stryker run on our code:

As you can see, 53 mutants were killed, but 15 of them survived. This gives us a mutation score of 78%. Let’s call it mutation coverage from now on. So to make it clear, this is our starting situation:

8 unit tests, 100% code coverage, 78% mutation coverage

Let’s now see how to kill those remaining mutants.

Killing First Mutants

In order to kill the mutants and improve our mutation score, we need to write more unit tests. Sounds logical, doesn’t it?

If still not, let’s take a deeper look at mutation tests results in VS Code. Stryker lists details of every survived mutant, for example this one:

Stryker changed the greater or equal (>=) operator to greater operator (>). This is a very common and very useful mutation. It usually means that our tests don’t cover the edge case associated with this particular condition.

In this case, the edge case value seems to be 5. More precisely, what happens if the number of business class tickets is exactly 5? We don’t know, because there is no test for this particular edge case!

Let’s add it:

The test passes. Let’s run mutation tests again:

That’s it! We have a new unit test and 1 more mutant killed Current state:

9 (+1) unit tests, 100% code coverage, 79% mutation coverage

I think you’re now getting what this is all about. We should be adding unit tests to cover the edge cases detected by mutations until all (or most) mutants are killed.

Mutation Testing – Free Unit Tests Generator

After adding 1 more test, the results look as follows:

10 (+2) unit tests, 100% code coverage, 86% mutation coverage

Finally, this is what we managed to get after a few minutes of work:

And we now have 17 unit tests in our suite! The final score looks like that:

17 (+9) unit tests, 100% code coverage, 96% mutation coverage

Notice what happened here. We started with 8 unit tests and finished with 17! This is awesome! That’s how mutation testing is a free unit tests generator. And you don’t even need AI for that

What’s more, the generated mutations even forced me to make a little tweak to the production code. It exposed some things that didn’t make sense. I could make this change to the production code, because my tests’ suite was already quite substantial.

Note that I didn’t push to gain 100% mutation coverage. The 3 mutants that survived don’t make much sense in our case. I encourage you to get the code and execute npx stryker run in the application folder to see for yourself

The percentage value doesn’t matter in that case. What matters is that we got 9 new unit tests and our tests’ suite is more robust. Now we can go and tell our manager that the business-critical code is well tested

So What Now?

I hope you see how valuable mutation testing is. It’s not a perfect tool that suits all cases. For example, it’s not easy to use mutation testing for complex legacy code. However, if your logic is nicely isolated, it could be a great tool. Especially if your production code heavily depends on calculations and many conditions. You may be surprised how many edge cases mutation testing can find.

I also love using mutation testing with TDD. These two techniques nicely complement each other.

I encourage you to go and try mutation testing. There are different mutation tools for various programming languages:

• C#, JavaScript, TypeScript, Scala: Stryker Mutator
• Ruby: mutant
• Java: pitest
• PHP: Infection
• C++: Mutate++

…and probably many more. Just do some research for the language you work with and give it a try Because testing is cool, isn’t it?

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

The post What is Mutation Testing and Why Should You Use It? appeared first on CodeJourney.net.

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.

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. We will not explore the inner workings of the TypeScript compiler Instead, we’ll see some practical implications of its workings for TypeScript developer. Let’s dive in

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.json 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:

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:

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

If you’re a .NET developer, and you enjoyed this article, I think you may also find my free guide useful:

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

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

If you’re a .NET developer, and you enjoyed this article, I think you may also find my free guide useful:

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

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:

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:

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:

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:

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:

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

The post How (And Why?) To Wrap External Libraries? appeared first on CodeJourney.net.

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:

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:

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. Line 14 shows 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:

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:

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:

<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:

<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!

The post Adding Meatballs Menu To React-Table Rows appeared first on CodeJourney.net.

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! Just take a look, how beautiful that is:

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!

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.

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.

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

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

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!

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.

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!

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?

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 to 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?

The post 10 VS Code Extensions I Couldn’t Live Without appeared first on CodeJourney.net.

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

The post How To Fix Visual Studio Code IntelliSense Loading Infinitely appeared first on CodeJourney.net.

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 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, inferred from UserViewModelSchema.

Validating API responses 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.

The post Typing API Responses With Zod appeared first on CodeJourney.net.

Finally, I found a solution and a reason for that issue.

The error occurred when I was trying to install @testing-library/react npm package. It looked like that:

Hotfix

If you ever get this error, the hotfix is to follow these steps:

• delete node-modules folder
• run command npm cache clean --force
• run command npm install
• install the package again with npm install your-package-name

It should all work fine after that.

If these commands still don’t solve your issue, and you use git as a source control system, you can try the unbeatable git clean -fdx command. After that, run npm install again. Beware – it removes all files not checked in to git. It may also remove your IDE settings etc., so use with care.

But it’s only a hotfix, a solution for now to unblock you.

Coldfix (solution)

The real reason for this issue in my case turned out to be related to jest. However, not to the testing library itself, but to jest extension for Visual Studio Code.

The reason for the issue is the jest tests runner working in the background. You can see that in the VS Code bottom bar:

The real solution is to disable jest runner when installing new packages. You can do it with a Jest: Stop Runner command in Ctrl+Shift+P:

I don’t know exactly why this is an issue. I guess jest runner is blocking some files in node-modules, so they cannot be renamed/processed. I hope it helps you too

The post How to fix: npm ERR! enoent ENOENT: no such file or directory, rename appeared first on CodeJourney.net.

Today I can say that it was the best decision we could make. TypeScript makes working with JavaScript, which is sometimes surprising and quite hard to understand, so much better experience. However, there were some challenges on this journey. If you want to know what issues we met and how we solved them, but also what huge advantages TypeScript gave us – read on

I will not discuss TypeScript itself in this article. This is a pure recap of challenges and the experience I gained when migrating to TypeScript.

Choosing migration strategy

Before starting migrating to TypeScript, we had to choose the best strategy for this process. There were two possibilities we considered: migrating the whole JavaScript codebase to TypeScript at once or switching to TypeScript compiler and migrating part-by-part.

For those who are not familiar with TypeScript – it is a superset of JavaScript which adds typing information to your JS code. It means that every JavaScript code is also a valid TypeScript code. When compiling TypeScript code, TS compiler removes the typing data and outputs readable, vanilla JavaScript code ready to be executed.

Migrating the whole codebase to TypeScript would mean to change all files extensions to TypeScript ones: .js to .ts and .jsx to .tsx. It would also mean that TypeScript compiler starts checking types in those files. This approach is doable, but – depending on the size of your project – can take a long time. During migration the code would be frozen until you fully migrate the project. Also, for TypeScript beginners, it could be a bit frustrating having to type everything at once or use some tricks to tell TypeScript to ignore checking types in many cases (because the type is not known at this stage, or we want to do it later etc.).

Because of that, we decided to migrate part-by-part, having JavaScript and TypeScript files at the same time. It is possible thanks to enabling allowJs TS compiler option. It means that TypeScript will compile both TS and JS files. Such approach allows the coexistence of old JS code with the new TS parts. It also allows moving only chosen parts of the application to TypeScript at the beginning and come back to the others later.

In our web application the biggest JS files have few thousand lines of code. Some of this legacy code still didn’t use React, but Backbone as their framework. We didn’t want to touch these oldest files in the beginning. Instead, we moved few recently written functionalities to TypeScript straightaway and decided to implement everything new in TS as well.

Bright side of migrating to TypeScript

If you are a JavaScript developer, the best advice I can give you is to start using TypeScript In this section I’m describing what positively surprised me since the beginning of starting to use TypeScript.

Types “for free”

As soon as we changed our transpiler from babel-loader to ts-loader, I wanted to know how we can get typing information for already-installed npm packages. It turns out that for 98% of the packages we used there’s already a typing information available as a separate npm package.

In most cases if you have a npm package called abc there’s a typing package available called @types/abc. I explored our package.json and for each package listed there I just executed npm install @types/package-name. 2 or 3 older or not-so-popular packages didn’t have types definitions available, but for the rest we got types for free, without having to type anything ourselves. This was a first, very nice surprise

You can find more information about TypeScript types definition packages, as well as contribute one yourself, here.

All new code is typed

As I wrote before, every new feature we’ve added since the migration is written in TypeScript. Thanks to that, all new code we write is strongly typed. What’s remarkable here is that it required almost no effort. We just switched the compiler to TS (with a small struggle with webpack configuration, about which you can read below) and suddenly got into typed world for every new feature we implement. Quite impressive, isn’t it?

JS-TS friendship

Coexistence and friendship between JavaScript and TypeScript is HUGE. These two creatures are not enemies – they are best friends We’ve already gone through many scenarios when we needed to use something written in TS in a JS file and otherwise. It turns out that all of these scenarios are manageable. Sometimes you need to import something differently (for example using require instead of import), but it’s all possible. We found it super easy to write new features or even add parts of new features to already-existing JS code, writing everything in TypeScript.

We also rewrote some JS files that were used from multiple places in the app to TypeScript. As an example of JS-TS coexistence, I’m presenting below the potential .ts source code you might have. It contains both old, legacy JS code when we used module.exports and prototype to expose various services for data fetching, as well as a brand-new, nicely-exported TypeScript class:

Such code can of course be in separate files, but it only shows how good TS and JS can coexist together. You can keep your old code working, while implementing anything new in TypeScript.

Flexibility in partial migrating to TypeScript

It turns out that choosing to partially move our web project to TypeScript was a great decision. The team wouldn’t be so happy and enthusiastic about TS if we told them to move legacy Backbone code to TypeScript. Instead, we gave them a nice tool which can be used for all new stuff. Also, if someone likes the idea and wants to move already-existing JS file to TS, he or she is welcome to do so.

That’s how we are still migrating our project to TypeScript, without any hustle and frustration

Wisdom of TypeScript

I’m positively surprised by TypeScript almost every day. At some point I get to the issue that seems hard to be solved or quite non-standard. Then I find a solution online and it makes me really impressed about the job the community and Microsoft has been doing around the language.

These are sometimes small, but smart things. Recently we got surprised by keyof, which lets you get names of the allowed properties of your type. Generally the typing system is really advanced and impressive. For some it can be a disadvantage, but I think it gives an enormous flexibility.

This is somehow the JavaScript you-can-do-whatever-you-want philosophy smuggled into TypeScript But in a much smarter way. I’m sure that when you start working with TypeScript you’ll get what I mean by its wisdom

Small effort, huge benefits

Last, but not least, I must admit that migrating to TypeScript was quite an easy and smooth process. The value for the effort is huge. You get a typed world with very little work.

Migrating to TypeScript struggles

During the migration process we met few difficulties. Some of them we managed to solve fully or partially. If you have any better ideas on these things, feel free to let me know in the comments.

Complexity of webpack configuration

When switching to TypeScript we had few issues with webpack configuration. We have used babel-loader before for transpiling JavaScript and initially we wanted to keep it in the TS compilation process. We first tried to keep babel-loader for JS(X) files and use ts-loader for TS(X) files, but it didn’t work – we were getting weird compilation errors.

Then we tried to compile everything using ts-loader and then recompile it again using babel to ensure (as we initially thought would be wise) backwards compatibility. We also couldn’t make it working.

Finally, we decided to compile everything – both JavaScript and TypeScript files – using ts-loader (including React files). It worked, except source code maps. When we tried to debug in Chrome console it seemed the source code is not refreshing properly after rebuilding. Breakpoints were often not hit and the debugging didn’t seem right.

After a bit of struggling we found a solution. We set devtool webpack option to eval-source-map and configured source-map-loader for .js files. Finally, the proper part of webpack config looks as follows:

So far we also haven’t noticed any issues related to backwards compatibility that were theoretically solved by babel. TypeScript compiler does its job very well.

Complicated JS -> TS refactoring

I found out that JS to TS refactoring is not always an easy task. Some things that are allowed by JavaScript are not valid in TypeScript. In most cases it means that something was wrong with your JavaScript code, but we all know how it is with legacy code refactoring

As an example, we had several functions that we added to a String prototype in JavaScript:

Such code becomes invalid in TypeScript:

A non-obvious solution to that issue is to extend String interface by declaring typed functions you want to add:

There are more subtle difficulties like that you can meet while migrating JS code to TypeScript. However, in the end it gives you a possibility to make your codebase better.

Keeping view models in sync

An issue I didn’t think about before migrating to TypeScript was a need to keep frontend and backend view models in sync.

One of the first things you’d like to have in your TypeScript codebase is to have as much typed data as possible. We use .NET and C# as the backend of our application. ASP.NET MVC controllers returned the strongly-typed objects into the previously chaotic and untyped JS world. Now we are strongly-typed with TypeScript, so we’d like all this data typed as well

Here comes the problem. First of all our C# data models which we returned from the controllers were not the best. In most cases we returned a DTO object which contained many properties from which only few were used by JavaScript code. We never saw this problem, because in JS we just dynamically typed properties names we wanted to use. We didn’t see how much of not needed data is sent from ASP controllers to the web browser.

Now with TypeScript we needed to create these objects definitions also in TypeScript. Having a huge DTO object returned from the controller, with another X objects on which this DTO depends, it was a nightmare. It turned out that for a single DTO I had to create 10-15 TypeScript objects just to use 5-10 properties in the frontend code!

That’s the moment when we came to the necessity of creating web view models. The idea is to return a view model from a controller, not the whole DTO object. This view model contains only the data which is needed by TypeScript (frontend).

I think this is nothing new for experienced web developers. However, now comes the question: how do we keep backend (C#) view models in sync with frontend (TypeScript) ones?

Unfortunately, I haven’t found a perfect solution for that. The best method I came up with is… manually keeping these view models in sync.

There’s a C# to TypeScript VS Code extension which allows to paste the copied C# code as its TypeScript equivalent. It makes the job a bit easier. It even has a CLI tool, but it produces a single .ts file from a single .cs file. If you have multiple objects in a single C# file it will produce a single TypeScript file with all these objects. If any of those objects is used in other files (unfortunately we have many of such cases), these dependencies will not be automatically added as imports in the auto-generated .ts files.

However, I don’t find it very problematic for now. As soon as the TS view models are created, we just need to update them as often as we update C# view models. I think this is a very common issue so if you know any better solution here – please share in the comments

Migrating to TypeScript – summary

Migrating to TypeScript has been a very interesting and rewarding process. Compared to vanilla JavaScript, TypeScript lets programmers see many problems. This allows to see how bad our codebase was. We even realized that our server-side C# code was not the best (see the section about view models above). Thanks to introducing TypeScript we improved a lot of our JavaScript and C# code, including its architecture.

I think that TypeScript uses many simple concepts under the hood and it makes a lot of things possible (see keyof or unknown). In many cases TypeScript lets you do something, but doesn’t force you to do it. That’s the beauty of this typed JavaScript world

The post Is It Worth Migrating to TypeScript? appeared first on CodeJourney.net.

These features of JavaScript language are the most striking differences compared to C# ecosystem. If you’re about to learn JavaScript, sooner or later you’ll also have to deal with them.

Before we begin, one disclaimer: the goal of this post isn’t stating which language is better or worse. JavaScript and C# are different programming languages and their use cases are also completely different. One is better for some usages, while the other is better for others. The list is my and other readers’ subjective one and you don’t need to agree with all points. I’m myself a C# developer on my JavaScript learning journey, so I’d like to help you grasping these confusing concepts

1. Dynamic Typing

Obviously, the first difference JavaScript newbie notices is that the language is dynamically-typed. It means that the types (of variables, functions, actually of almost everything) are checked at runtime, not at compile time like in C# or Java.

Because of that, there’s not much difference in defining variables and assigning them data of various data types:

JavaScript’s variables are not associated with any particular data type. That’s why it’s completely legit to write something like that:

Because JavaScript is dynamically-typed, issues with types are detected at runtime (e.g. error is thrown as soon as you try to use a variable in a context which expects another data type), not during compilation time as it would be in C# or Java.

If you have some experience with statically-typed languages, you may now feel how much confusion and troubles dynamic typing can bring. At least at the beginning.

2. Implicit types coercion

JavaScript has one more interesting feature – types coercion. Even though this term’s name sounds a bit weird , it’s quite simple: types coercion happens when a value of one type is converted to another one.

3. null and undefined

In JavaScript there are two values which represent kind of unassigned variables: undefined and null. What’s the difference between them? The snippet below clarifies:

5. Hoisting

In JavaScript you can legally write such a code:

As you can notice, name variable is used before it’s declared 2 lines below. This is maybe not that weird, as in JS we can even declare variables without the var keyword, but we can do the same with functions:

So here we call the function before declaring it. Why does this work?

This works thanks to hoisting. It’s a compile-time mechanism which “moves” all variables and functions declarations to the top of our JavaScript code. In fact, during the execution of above-listed code, JavaScript engine processes variables and functions declarations before executing any other code.

It however applies only to declarations, not to assignments:

6. Lexical scoping and this keyword

To create a scope (space in which the variables defined in it are accessible) in JS, we need to create a new function. Variable defined in a function is not accessible outside this function:

It means that other blocks like the ones associated with if statement don’t introduce a new scope:

If a variable is defined outside of any function, it’s assigned to a global scope.

However, in JavaScript we also have something called lexical scoping. It basically makes functions declared within another functions having access to the parent function’s scope, as the following example presents:

Forming such “hierarchy” of functions is also referred to as scope chain. You should remember that it refers to the order in which functions are lexically written, not in which they are called:

As you can see above, as soon as we call a(), which then calls b(), within which we define variable x and then call function c(), inside of function c() we don’t have access to x variable (x is not defined). Why does it happen even though function b() in which x variable is declared called function c()? Because function c() is not lexically written as the child function of b(). Parent scope for function c() is always the global scope.

7. this keyword

All these scoping rules examined above somehow lead to another confusing concept with this keyword. As soon as we define a method on some object and try to print the this keyword in this object’s method, the result seems reasonable:

However, if we just define an inner function in our method and try to print this keyword inside it, weird stuff happens:

As you can see, the this keyword in the innerFunc() function doesn’t point to the blogger object anymore. Instead it points to a Window object, which represents the browser’s window (this used in the global scope points to it).

This happens because in a regular function the this keyword points to the global object (Window object in our case). innerFunc() is here considered as a regular function, not as an object’s method. This behavior may be confusing and is often a subject of dispute in JavaScript community.

8. sort() function

You’re a newbie JS developer and you’d like to sort an array of numbers. You found a sort() method on the array, so why not to use it? You write such code:

What do you expect to be logged in the console? Let’s see:

(5) [-5, 15, 20, 40, 7]

Nice! What happens here? 7 is greater than 40? Well, yes It works as expected, because the sort() function sorts array’s elements as strings and alphabetically. Therefore, if our array contains numbers, the final order depends on the Unicode representations values of each number.

Fortunately, there are ways to use sort() function correctly for numbers, but this functionality is still confusing for new JavaScript developers.

9. Prototypes

Every object in JavaScript has a __proto__ property. We can access it directly on our object or by using Object.getPrototypeOf() method. In both cases, having created an empty object and printing its prototype to the console like that:

produces the same output:

On the top of objects hierarchy, there’s Object. Because of that, our x object is an instance of Object. That’s why the prototype of our x object is actually the Object.prototype, which contains some common methods we can use (like toString()).

If we try to access Object.prototype.__proto__, we’ll see that is contains null.

Prototypes in JavaScript are mainly used to provide some connection between two or more objects (like exposing some common methods).

All this “hierarchy” of prototypes is used to search for fields and methods of objects: the JS engine first searches in the object itself and if it cannot find particular property, it looks in this object’s prototype, and then in its prototype until it finds the first matching occurrence. As soon as it reaches null in the Object.prototype.__proto__ it means that the prototypes chain has ended and undefined is returned.

This kind of prototype inheritance is different than class inheritance, so it’s often confusing for developers willing to learn JavaScript. Actually, I could write a separate post on this, so if you’re interested you can read more for instance here.

10. IIFE

IIFE is an acronym for Immediately-Invoked Function Expression. So what is it and how can it be useful?

Going straight into the code, IIFE can be written as follows:

As a result of executing such script in a web browser, we’ll see the following console output:

Hey!

How does it work? We neither declared a function’s name nor called it, right? Actually, we did

There are two unusual parts of IIFE implementation: outer parentheses in which we “wrapped” our function and “empty” parentheses together at its end.

Let’s start by “wrapping parentheses”:

Why do we declare them? Because if you don’t, JavaScript parser will give you an error:

script.js:1 Uncaught SyntaxError: Unexpected token (

In such case it thinks that we’re writing a function declaration and we forgot about providing the function’s name after the function keyword. Wrapping this into parentheses (…..) tells the parser that we’re declaring a function expression, not a declaration. After doing this, there are no errors anymore.

The second important part is the “empty” parentheses () just after the function expression:

As you know, () allows to call the function. That’s exactly what we do here here – our function is immediately executed.

Why would we need such construct as IIFE? Developers say that it doesn’t “pollute” the global scope. In effect, we are not leaving the function somewhere after being executed, so no one else can call it accidentally from another place. What’s more, IIFE is even considered a design pattern.

You should know that such construct exists even only to know what it does seeing it in someone else’s code. If you want to know more about its use cases, I recommend reading this article.

Summary

In this post we’ve gone through some of the most shocking features of JavaScript language for C# developers. Most of them are confusing for programmers coming from statically-typed and class-based languages and can bring a lot of issues in the beginning of their JavaScript journey.

Just remember that these are the JavaScript’s language features, not its issues or bugs. That’s just how it is, but it cannot be said that JavaScript is worse or better than other languages like Java or C#.

The list for sure is not exhaustive, so if you have anything to add or correct don’t hesitate to leave a comment!

For the end, I’ll just leave you with the following meme-but-true (thanks Youenn ):

Stay tuned!

The post 10 Most Shocking JavaScript Features for C# Developers appeared first on CodeJourney.net.