small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

Server actions were the last missing part of the server-first approach encouraged by Next.js since introducing the app directory in version 13. First in alpha, then to be marked as a stable, “production ready” feature in the most recent update to version 14. It goes without saying that the introduction of server actions had a rocky start to say the least. Social media like X or Reddit flooded with an unfortunate photo of a simplified server action use case and rapidly became a meme in the IT community. 

The unfortunate server action use case:

![qxwioqacqowb1.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/qxwioqacqowb1_95c0586b37.jpg)


This, and already big confusion about server and client components, did not help Next's team convince developers to migrate to the new app directory. Nevertheless, it is a new way of developing web applications, so this is worth checking out.

Server actions are a very complex topic that might be hard to get a head around due to many different ways of implementation.
Some of these are Inline, inside a component, or in separate files. To top it all off, server action implementation will differ depending on whether it's used in a client component (with a "use client" clause) or a server component.

_Note: by client component, it does not mean CSR (Client Side Rendering). The clause "use client" still renders components on the server first, but it also sends javascript code to handle any interactivity, states, events etc. (also known as hydration)._

The goal of this blog post is to create a comprehensive, easy to follow and hands-on guide that will bring some order to all of this chaos. First, explaining the basics to then dive deeper tackle this complex feature to give a solid foundation to how server actions work and how to implement them.


#### The tip of the iceberg

Before more complex examples can be introduced, the basics must be mastered. One of the first questions that might be asked is, *What is a server action?* Answering this question is best led by example.


The simple answer to the above question is that a server action is just an async method with a `”use server"` clause that is used in the form’s `action` prop. This is just scratching the surface, and to better understand server actions, it is required to look under the hood.
Next.js sees a `login` server action, creates an endpoint and then makes a `POST` request to that endpoint when the form is being submitted. Moreover, Next.js also handles parsing the incoming request and gives the server action access to the `FormData` object (from which any data of the form can be extracted). 

This makes code cleaner and cuts out the necessity for creating an endpoint and handling form submission by the developer, which removes a lot of boilerplate code. Less boilerplate code is always welcomed, but this is not the best part. 

What makes server actions so vital in the server-first approach is that this form does not require **any** javascript to be shipped to the browser. The above example will work as expected even if the end user has javascript disabled. Rendering the page and all the functionality regarding the form is handled on the server.


#### What Next.js does not show - handling out of scope data

When using a server action inside a component, it can be inviting to use some variables outside of the scope of the server action. Just like in any other regular methods defined inside a component.


The server action will still work as expected. Next.js handles this case in a very interesting way. In the hidden layers of abstraction, Vercel’s meta framework changes the shape of the form that is being rendered in the browser by adding all the out of scope variables as **hidden inputs**. 

When inspecting the code in the dev tools, the above example will be rendered like so:

Using out of scope variables can be useful because it removes the need to handle a `FormData` object, which can get tedious when working with bigger, more complex forms. However, it's important to note that **any variable that's out of server action scope will be shipped to and rendered in the browser**, so it's advised against passing any private information, such as secrets or environment variables.

#### Storing server actions in separate files

There can be multiple use cases where one server action logic could be used in different places in the codebase, e.g. deleting or updating an item. Server actions can be stored in separate files, thus making them reusable. 

_Using "use server" at the top level of the file, will also prevent exporting anything else, but functions from that file._


Storing server actions in separate files can make a codebase more organized. This pattern at first can make it impossible to use out of scope variables, though. To get the required data it's also required to parse the `FormData` object. It can be viewed as counterproductive, especially when server action just needs the ID of an item. Next.js still allows passing custom data to server action with the help of a well known `.bind()` method.

### Adding custom values to server actions

To pass custom variables to server action, can be achieved by using the `.bind()` method. Next.js, similarly to `fetch()`, has created its own implementation of `.bind()` that does exactly the same thing as using out of scope variables - it tells Next to change the shape of the form rendered in the browser so that the server action knows what data to expect. 

_Is it good that Next.js has its own abstractions of native methods like `fetch` or `bind` is a topic of its own, and was explained more by Kent C. Dodds in his recent article: [Why i won't use Next.js](https://www.epicweb.dev/why-i-wont-use-nextjs)._


_RevalidatePath will tell Next to refetch every data that is used in the `todos` directory to keep client and server state in sync when marking some todo as done._


Even though the `.bind()` method was used, the rule of **no javascript shipped to the browser** still applies!

_Alternatively, instead of using `.bind()` values can be passed by creating `<input type=”hidden” />`, however the `.bind()` method also encodes the values._

#### Server action in client components

Up to this point, server actions were used inside of server components exclusively. Nowadays, in modern web applications, it's important to provide feedback to the user about e.g. an error in the form field or that form is being processed. In the server-first approach in Next.js, handling any type of interactivity can be done only with the help of client components (with the "use client" clause).
React also provides 2 new hooks to help useserver actions in client components and managing the form state changes - `useFormState` and `useFormStatus`.

In the above example, the `SubmitButton` was implemented as an abstraction to the button component to change the button's label and give users feedback that the form is being submitted/processed.

_`useFormStatus`  will get the status of a parent form element, thus the need for `SubmitButton`_

#### Handling errors with server action state

Before handling the state of the form. Good help in managing the actions and forms states is to create custom, generic utility types. These utility types will enforce a similar return shape leading to a better organization of the codebase.

_If you are new to utility types or generics, you can read our Typescript tips and tricks blog post [here](https://www.bitnoise.pl/blog/Developer-is-sweaty-TypeScript-spaghetti) where we explain these concepts in greater detail._

Keep in mind that this step is optional, but it not only brings a structure to what action can and will return (thus, you always know what properties to expect from any server action), but also gives type safety in the `useFormStatus` hook. 
This next example will be more "real life" like, so it can take more time to understand it fully.


_Defining the return type `Promise<LoginUserFormState>` makes it easier to enforce the correct return shape in different if blocks._

#### Summary

The core fundamentals of web development shift towards server first patterns. The line between frontend and backend becomes more and more blurry with every new feature. Creating APIs becomes obsolete, being replaced by server components and server actions. As with any bigger change, it may be hard to grasp at first, making it feel like an unnecessary complication of something that was working well in the past. However, changes are often a sign of progress, and it seems that server-first is becoming a standard for the future. Definitely, these new patterns will require more time for the ever growing React community to catch up to. This blog post aims to make the transition less painful by trying to explain one of the core concepts of the new Next.js app directory feature and help other developers jump on the wagon of the bright future of the server-first pattern.

large_Ready set action_Michał Gąsiorek.png

medium_Ready set action_Michał Gąsiorek.png

small_Ready set action_Michał Gąsiorek.png

thumbnail_Ready set action_Michał Gąsiorek.png

Ready set action_Michał Gąsiorek.png

Ready, set, action! Diving deep into Next.JS Servers Actions


On Wednesday, July 7, we met in the Bitnoise headquarters for the first Bitnoise_Meet ever.

Due to the pandemic, we not only have lost the possibility to get in touch with developers outside of Bitnoise, but Covid-19 has also significantly limited our contacts with each other. And we really miss our creative brainstorming. We’ve decided it has to change. 

Bitnoise_meet is a space we’ve created to exchange experiences and learn from each other. We believe that sharing knowledge brings only benefits, and self-development is very important to us. A fresh look at the problem often brings surprising results, and the efficiency of our work increases.

The first meeting was dedicated to Node.js. Our senior developers, who, based on their previous backend experience, have started their adventure with Node.js at Bitnoise, shared their knowledge and their story during Q&A and networking. 

Meeting, exchanging experiences and getting to know your perspectives was wonderful.

A few interesting points from our deep conversation:

- With TypeScript and linting, you can still keep the syntax close to Java. We know from experience that whoever gets into TypeScript doesn't want to come back to JS.

- The backing of tech giants has pushed the most popular libraries to a new level and improved their quality significantly. The state-of-the-art technologies and tools provide a sense of security and programming comfort known to developers from statically typed languages.

- Undoubtedly, the greatest advantage of Node.js is its flexibility and the ability to adapt the application to business requirements instantly.




small_Blog_artykul_BitnoiseMeet01_cover_high.png

thumbnail_Blog_artykul_BitnoiseMeet01_cover_high.png

Blog_artykul_BitnoiseMeet01_cover_high.png

Bitnoise_meet #01

Prettier is like your very experienced colleague who constantly whispers advice about your code consistency and readability. Who wouldn’t want one? 


Unfortunately, very experienced developers are often busy, and that’s why [Prettier](https://prettier.io/)
 was created. In essence, it’s a tool that helps developers implement best coding practices automatically. 

Here is a concise **Prettier guide** including key benefits, **React** and **Typescript** code examples, and comments from our developers. 

#### **Key benefits**
- **Opinionated Formatting:** Prettier has a set of default formatting rules based on community best practices, making it easy to format your code without spending time on style debates. 

- **Multiple Language Support:** Prettier supports various programming languages such as JavaScript, TypeScript, CSS, HTML, and more. 

- **Customizable Rules:** Prettier allows you to customize the formatting rules to fit your project's specific needs, giving you more control over your code formatting. 

- **Easy Integration:** Prettier can be integrated into your development workflow with ease, enabling you to automate your code formatting and improve your productivity. 

- **Improved Readability:** By formatting your code consistently and following best practices, Prettier can make your code more readable and easier to understand. 

- **Reduced Maintenance Time:** Prettier can save you time on code maintenance, as it can automatically format your code as you write it, reducing the need for manual formatting.

- **Reduced Human Error:** By automating the code formatting process, Prettier can reduce the chance of human error and ensure that your code is always formatted correctly.


![ ](\uploads\blog-prettier_Lukasz_post_cytat_01-1_3tfodtSBNooCMUZATR9yqN.jpg)
#### **How does Prettier work?**
Prettier parses your code into an abstract syntax tree (AST) using a parser specific to the programming language you are using. 

1. Applies a set of formatting rules to the AST, modifying it to conform to the formatting rules. These rules are based on community best practices and are designed to ensure consistency and readability in your code. 

2. Generates formatted code based on the modified AST, producing a new code file that conforms to the formatting rules. 


Prettier also provides options to customize the formatting rules, allowing you to tailor the formatting to your project's specific needs. Once configured, you can integrate Prettier into your development workflow using various tools such as code editors or build scripts. This way, **you can automate your code** formatting and maintain a consistent code style across your team.

#### **How to install Prettier?**
To configure Prettier, you can create a configuration file in your project's root directory. Here is the step-by-step guide:

1. **Install Prettier:** You can install Prettier either globally or locally to your project using a package manager like npm or yarn. For example, to install Prettier globally, you can run the following command in your terminal:


``npm install -g prettier``

2. Create a configuration file: Create a ``.prettierrc`` or ``prettier.config.js`` file in your project's root directory.

3. Specify formatting rules: In your configuration file, you can specify the formatting rules you want Prettier to apply. You can find a list of available options in the Prettier documentation. Here's an example ``.prettierrc`` file that sets the maximum line length to 80 characters and uses single quotes for string literals:

![ ](\uploads\blog-prettier_Lukasz_post_cytat_01_C7f9YCZX42n8FbuHij8i2.jpg)
#### **How does Prettier work with JavaScript and Typescript?**
Here are some examples of how Prettier works with JavaScript and TypeScript:

1. Formatting JSX  

Before:




3. Formatting TypeScript in a Functional Component

Before:



#### **What are alternative and complementary tools?**
1. [ESLint](https://eslint.org/)
: ESLint is a popular static analysis tool for identifying problematic patterns found in JavaScript code. It has built-in rules and plugins for code formatting and styling.


2. [JSHint](https://jshint.com/)
: JSHint is a community-driven tool that helps detect errors and potential problems in JavaScript code. It has built-in options for enforcing code style and formatting.


3. [StandardJS](https://standardjs.com/)
: StandardJS is a style guide and linter for JavaScript code. It has a built-in code formatter and can be integrated into various editors and IDEs.


4. [Beautify](https://marketplace.visualstudio.com/items?itemName=HookyQR.beautify)
: Beautify is a code formatter that can be used with various programming languages, including JavaScript. It has plugins for popular editors and IDEs like VS Code, Atom, and Sublime Text.


5. [CodeMirror](https://codemirror.net/)
: CodeMirror is a versatile text editor for the web that can be used for formatting and styling code. It has built-in features for code highlighting, indentation, and autocomplete.


6. [JS Beautifier](https://beautifier.io/)
: JS Beautifier is a simple tool that can be used for formatting and beautifying JavaScript code. It has options for configuring the code style and formatting rules.


7. [Black:](https://github.com/psf/black)
 Black is a Python-based code formatter that can be used for formatting code in various programming languages, including JavaScript. It has options for configuring the code style and formatting rules.


#### **Summary**
Prettier is a code formatting tool that automatically implements best coding practices, and improves code consistency, and readability. 

It has default formatting rules based on community best practices, supports multiple programming languages, is customizable, and can be easily integrated into a development workflow. Prettier works by parsing code into an AST, applying formatting rules, and generating new formatted code. Developers can install Prettier by creating a configuration file with specified formatting rules. Prettier works - among others - JavaScript and TypeScript. 

I encourage you to try out Prettier and other similar tools. 

If you have any questions or are interested in our services, do not hesitate to reach out to us.

small_blog-prettier_Lukasz_cover_high.png

thumbnail_blog-prettier_Lukasz_cover_high.png

blog-prettier_Lukasz_cover_high.png

How to make your code better with Prettier?

#### Everywhere You look, there's TypeScript!

In JetBrains' "State of Developer Ecosystem 2022" report, TypeScript is recognized as the fastest-growing language in recent years. Undoubtedly, when working with technologies related to JavaScript, it's impossible not to notice that TypeScript is becoming increasingly prevalent and dominating tech stacks. TypeScript can be found in the development process of frontend applications in modern frameworks and libraries like React.js, Vue.js, and Angular. It's also present in backend projects using Node.js and its frameworks, mobile solutions like React Native, and can even be used in older solutions like jQuery. In other words, anywhere JavaScript is used, TypeScript can follow suit. But why do we need TypeScript in the first place? What is it used for?

#### What's wrong with JavaScript?

It's worth noting that TypeScript emerged as an extension of the JavaScript language. This means that any valid program implemented in JavaScript is also a valid TypeScript program. Furthermore, code implemented in TypeScript is transpiled into JavaScript. In other words, what's implemented in one programming language (TypeScript) is expressed in another language, JavaScript in this case. Ultimately, the program that is executed is always implemented in JavaScript.

One might wonder what's wrong with JavaScript that led people to decide to improve it. Moreover, why didn't they create TypeScript as an independent language, given that so many people see value in it and invest their time and quite often money to learn and implement it in commercial projects? In my opinion, the answer to this question is both the greatest advantage and disadvantage of the JavaScript language:


>JavaScript is a popular, simple language that offers tremendous flexibility in implementing solutions.

In the aforementioned survey, JavaScript has been the most widely used programming language for web and mobile applications for several years. Interestingly, the same report lists JavaScript as the least liked language among developers. This creates an intriguing dissonance that speaks volumes about the language itself.

So, why didn't the creators of TypeScript decide to release it as an independent language? If Microsoft, the company that developed TypeScript, had done so, it's likely that few people would be using the language today. This move reflects the lessons Microsoft learned from its past. Remember that in the early days of the internet, Microsoft proposed its own technology, ActiveX, to compete with JavaScript, but today it's virtually unheard of.


#### JavaScript is everywhere!

One of the key reasons for JavaScript's popularity is its cross-platform nature. JavaScript began as a scripting language meant to enhance interactivity on websites. Over time, it expanded its use beyond websites to server-side and native device applications, including mobile apps and desktop applications. Learning one programming language, with relatively low effort, enables developers to implement programs for various devices. Such a developer is more flexible in the job market and is not limited to a specific type of application. There's a slim chance that TypeScript could surpass the popularity of JavaScript. Despite being considered a separate language, TypeScript is closely tied to JavaScript.

#### JavaScript is simple!

JavaScript is simple, but some context is necessary. It's simple compared to other programming languages like C/C++, Java, C#, and even Python or PHP. If you look at the history of programming languages, you'll notice a trend. Later languages have simpler syntax, automate many operations, or encapsulate them in ready-made functions that you can use. Initially, we had only bitwise operations on processors. Assembly language was introduced as a way to operate on memory more easily. Assembly, however, is still a low-level language. Later, languages like C provided a friendlier environment for developers. Despite this, they still required direct memory management, including memory allocation and deallocation. Programs had to be compiled separately for different hardware architectures. To solve this problem, more layers of abstraction were introduced, such as virtual machines for Java or C#, and script interpreters for Perl, PHP, or Python.

As the internet and websites grew in complexity, there was a need for greater interactivity. Websites are applications that run within a runtime environment – the browser. The browser, in turn, is a program executed natively by the operating system. Originally, JavaScript was confined within a limited environment and lacked the capability to interact with the operating system or file system. In this context, a complicated language wasn't necessary. To simplify things, JavaScript introduced dynamic typing. Unlike "classical" programming languages, where you had to specify whether a variable would hold text, numbers, or boolean values, JavaScript can infer this based on the value's type. Its straightforward syntax, limited capabilities, dynamic typing, and the reduction of everything to basic types (text, numbers, boolean values) and data structures (arrays and objects) make JavaScript easier for beginners compared to other programming languages.

#### JavaScript is flexible!

JavaScript's flexibility is both its greatest advantage and disadvantage. JavaScript allows you to write code in the way you find most convenient. If a programmer thinks it's most convenient to change the behavior of a function that works in a specific way, there's nothing stopping them. JavaScript is a prototype-based scripting language. When we refer to an "object," we mean a combination of data and behaviors within a shared context, representing what we can do with that data. In traditional object-oriented programming, objects are created based on "classes" that describe the behaviors and data within an object. However, JavaScript doesn't have typical "classes"; instead, it employs the concept of objects that share data and behaviors via prototypes. A prototype is an object that serves as a base from which other objects can inherit. All objects ultimately inherit from the "object" prototype.



**“object” ←”Person” ←”Employee”**

In the example above, "Employee" is also a "Person," and "Person" is also an "object". This means that both "Employee" and "Person" can use the same behaviors as "object," and additionally, "Employee" can use behaviors available for "Person."

The problem arises when we overwrite the behavior of an object in the prototype chain while the program is running. This change affects all objects that inherit from it. Other object-oriented languages, due to the way classes are structured, don't have this issue. Even if you change the behavior of the code in the base class, it won't affect existing objects. Furthermore, the possibility to change the behavior of prototypes extends to built-in JavaScript objects as well.

#### Things can get very messy…

Imagine a scenario where you use a library created by someone else for a particular purpose. However, you're unaware that the library's creator has changed the behavior of base prototypes. In such a situation, your program might start behaving in ways you can't understand. It's extremely challenging to identify and eliminate these types of errors.

There's a popular joke that in languages like C/C++, C#, or Java, errors are mostly reported by the compiler during software development, while in JavaScript, errors are reported by the client. Unfortunately, this joke has a basis in reality. JavaScript makes it easy to write unreadable code. As a result, it's challenging to predict the consequences of even the simplest changes in the future. In compiled languages, the static determination of expected types offers a significant advantage because the compiler can quickly identify potential errors. In JavaScript, dynamic typing is performed during program execution. During code execution, in a specific use case, only one code path is executed. If the use case relies on input data, testing it becomes even more complicated, and a single execution may not suffice. As a result, such testing is often omitted or limited to critical paths.


#### We need to take a step back!

In my opinion, TypeScript represents a step backwards in the context of the evolution of programming languages. However, it's a step in the right direction. JavaScript has proven that too much freedom and simplicity in a programming language place too much responsibility on humans, in this case, on the programmer and the tester. When implementing software, we need quick feedback on whether what we've created works or not. We can distinguish two types of feedback here:

1. Technical feedback, which is about whether our program executes correctly.
2.  Business feedback, which pertains to whether the program delivers the expected added value and meets functional requirements.

TypeScript can help us to some extent with both of these aspects.

#### Business feedback

Although not directly, TypeScript can also help us when delivering software that needs to meet specific functional requirements. One of the fundamental principles of object-oriented programming is modelling the real world. When building software, we attempt to reflect real-world concepts in our code, while keeping it to a necessary minimum. For example, in an employee management system, we need information about employees, but only the data required for managing them within the organization, while other data can be omitted.

As I mentioned at the beginning, JavaScript, besides simple types, provides an "object" type, allowing us to create arbitrary data structures and behaviors. However, it doesn't enable the creation of new types describing other objects based on it; it's quite generic. Although newer versions of JavaScript introduced the concept of "classes," it's essentially syntactic sugar for "objects." In TypeScript, we can speak of classes that create new complex types. This allows us to create a type like "Employee," which enforces specific data and enables specific behaviors, such as "change hourly rate" or "set vacation days." Furthermore, just like with simple types, the correctness of using these classes is controlled by the language itself.

So, we gain a powerful mechanism for control, fast feedback, and data modelling, making the code more readable and understandable. This not only reduces technical errors but also functional errors, which often result from a lack of understanding of a given solution within the team.

#### A Solution to All Evils?

TypeScript solves many of the problems that JavaScript developers face on a daily basis. However, it can't solve them all. JavaScript is everywhere, especially on almost every website. It's difficult to introduce new versions that break away from the old ones due to the multitude of browsers and the millions of places where it's used, requiring backward compatibility. Therefore, it's easier to improve the software development process itself and then transpile nice and modern code into JavaScript that's backwards compatible. In the resulting code, we don't need to worry too much about errors related to incorrect data types because they have been verified in an earlier stage.

#### Help for the Programmer or Art for Art's Sake?
When trying to answer the question posed in the title of this article, we need to consider our motivations for using such solutions. TypeScript restricts the programmer and controls the code, making it harder to make simple mistakes. At the same time, one can go to extremes. For example, imagine building a front-end application that uses a technique to control CSS styles (which describe how a webpage should look) on the JavaScript side (typically these are two separate technologies). With a very rigid approach, a programmer might conclude that they need to describe, using types in TypeScript, the capabilities for managing CSS styles. Anyone who has ever implemented CSS styles knows that it would be cumbersome, time-consuming, and ultimately unnecessary. In this case, it could become art for art's sake.

It's essential to remember that TypeScript isn't a language used during program execution. It was created to enhance the work of developers during the software development process and to shorten the feedback loop. With this approach, a programmer can create more robust, maintainable, less error-prone, and ultimately more cost-effective code in the long term.

Furthermore, TypeScript helps us describe code, providing priceless context. This context is invaluable when using supporting tools such as Github Copilot. With this context, the tool can offer code suggestions that are more precise, speeding up work.

In my opinion, with the right approach, TypeScript is a wonderful aid for developers that eliminates many of the problems we face daily in pure JavaScript. However, it's also essential to recognize that it's not always worth using it in every possible aspect and to apply appropriate compromises in cases where its use would be too time-consuming, and potential benefits would be minimal.

Do you think TypeScript is a step forward or backwards in the development of programming languages? What are your personal experiences with TypeScript? 

Leave your opinion on our social media!


Sources:
JetBrains, [The State of Developer Ecosystem 2022](https://www.jetbrains.com/lp/devecosystem-2022/ )
JavaScript, [Prototypal Inheritance](https://ii.uni.wroc.pl/~wzychla/ra2I2J/weppo/WEPPO_05.pdf)
[JavaScript](https://en.wikipedia.org/wiki/JavaScript)
[TypeScript](https://www.typescriptlang.org/)

large_blog-TS_LukaszD_cover_high.png

medium_blog-TS_LukaszD_cover_high.png

small_blog-TS_LukaszD_cover_high.png

thumbnail_blog-TS_LukaszD_cover_high.png

blog-TS_LukaszD_cover_high.png

TypeScript - A Boon for Developers or an Art for Art's Sake?

### Cracking the Code: TypeScript Tips & Tricks to Catapult Your React Application

#### Introduction

Every project that uses Typescript under the hood will contain some custom types that are being used across the application. As an application evolves or demands shift, it's important to manage all those types in accordance with DRY and KISS foundations. In the name of type safety, it might be tempting to type every single element within the codebase. However, it can be beneficial to stop for a minute and ask those 2 questions:

- **Why** is there a need for a given type?
- **What** is it needed for?
- **Where** will it be used?

It's important to note that creating too many custom types can lead to the over engineered codebase. When one change request or a new feature requires updating x amount of custom types, it can make the codebase harder to maintain.
This blog post will cover some useful tips and tricks to add to the cauldron of typescript magic to keep in mind when working with custom types.

### The less typescript, the better

Excessive inclusion of types for every single data structure may seem like a good thing at first. However, having a lot of custom types can lead to an unnecessarily bloated and redundant codebase, where some types may be duplicated unnecessarily.

To better understand why often less is more it's best to show by example:


At first glance, the above code looks good. Everything is type safe, but this code can definitely be improved.
By following the three questions asked in the introduction:

- **Why** is there a need for `ParsedUser`? - So that an array returned by `parseUserData` could be used in different places in the codebase.
- **What** is `ParsedUser` needed for? - To have a simplified type of `User` type.
- **Where** is `ParsedUser` used? - For example, in some components' prop types.

Doing one thing at a time. `ParsedUser` is just a simplified version of the `User` type, so it makes sense that when `id` or `username` on the `User` type changes,  `ParsedUser` would also adapt.

This can be achieved by introducing typescript's built-in utility types. It's possible to reuse the `User` type to construct the `ParsedUser` type by using `Pick`.


With that small change, `ParsedUser` and `User` are "connected" so whenever `username` or `id` changes the `ParsedUser` will also update.

The next thing to consider would be how to handle the return type of the `parseUserData` function. If there ever will be a need to change the shape of `ParsedUser`,  e.g. adding a `fullName`. With the current state of the code, every change to `parseUserData` must be followed by updating the `ParsedUser` type, which may not be ideal.

Since `ParsedUser` type is closely related to what `parseUserData` returns, it's possible to use `ReturnType` utility type from typescript and create this type like so:

Two things have happened:

1) Typescript is smart enough to understand what types will be returned from a given function so it's possible to skip it in function declaration.

2) By using the `ReturnType` utility, the `ParsedUser` type will not only be dependent on the `User` type, but also on the `parseUserData` function. When the shape returned by `parseUserData` changes, the `ParsedUser` type will reflect that change as well.

  
_As an addition, it is still possible to use this approach with async functions by introducing yet another utility type `Awaited`, e.g._


_Adding [number] to array type will tell Typescript to look on type of an item within that array._

As the above example presents, with less typescript the code is still type safe AND highly adaptable to any changes.

Utility types used in this example are just the tip of an iceberg.
In typescript's documentation, there are   way more utility types that can lead to enhancing the implementation of custom types and reducing the number of types needed in the application.

[https://www.typescriptlang.org/docs/handbook/utility-types.html](link)

### Master union types

A type union is most commonly used when a given property can have more than one type or when creating a custom type.
Basic type unions could look like this:

However, type unions can also enhance the developer experience when working with React components.
Again, best explained by example:

This example is invalid because `UserCard` requires to pass both `userStatus` and `adminStatus` no matter what user role is passed. A better experience would be to require passing the `userStatus` only when the user's role is `USER` and vice versa.

Possible fixes would be:
- Make both `userStatus` and `adminStatus` optional, but that may not be the intended behavior of `UserCard`.
- Create a separate `AdminCard` for handling admin stuff, but that can lead to code duplication, which could violate the DRY rule.

In this simple example, it would not be the end of the world to make `adminStatus` and `userStatus` optional. Oftentimes, components have more complex structures and making a lot of optional types can make it harder to understand what components require and when.

There is a better way of solving this issue with both type unions and typescript magic:

By extracting the common properties (`fullName`) to separate type and creating additional two separate types joined by union `UserCard` now have props that will be required based on the provided `role` prop.

_Typescript will know that both types used in the union have a role property, so it will "merge" these into one type. In the end, the role will be of type "USER" | "ADMIN"._

This behavior improves the developer experience, when working with this component because it requires different props depending on the user's role.

With great power comes great responsibility, so this pattern should be used wisely as it has some drawbacks:
- it can make props type less readable
- can be difficult to implement when there are two or more props that change the outcome overall props shape

#### Generic types for not a generic dev

Implementing generics enhances the flexibility and reusability of code segments within a codebase. This typescript is a fundamental tool that developers should frequently reach out for, becoming an essential tool in the toolkit of every developer working with typescript.

Generics can simply be used to create custom utility types e.g.


Function `swap` can only be used with strings, but what if there is a requirement to swap numbers, or some other custom typed data? It's a good idea to make this function generic:

_Specifying return type [T, T] makes sense here, because this array will always consist of just two elements._

Now this function can swap not only numbers, but any data thrown in as arguments.

When working with React, generics can be used to create generic components f.g
instead of creating Lists components for every single array the codebase has, it can be done with one generic component:

_Thanks to adding <T extends { id: string }>, id which is used in item's key will be required part of item type._

The list can now be used with any type of data structure, which makes it a highly reusable component.

#### Summary

TypeScript is approachable for beginners with its gradual typing and JavaScript compatibility, but mastering its advanced features like typing nuances and generics can be challenging. Despite the learning curve, the benefits of static typing lead to more reliable code, better collaboration, and reduced bugs. TypeScript's robust tooling and community support further enhance its appeal. The initial ease of use gives way to long-term advantages, making it a worthwhile choice for developers aiming for code quality and maintainability.

Typescript is easy enough for beginners to start their journey with static typing, but some more complex features (generics or type unions) can be hard to get around at first. Still, they can improve the maintainability and reusability of some parts of the codebase, so it's worth getting to know them.

I hope this blog post will ease the learning curve of the more complex topics of Typescript.

Ready, set, action! Diving deep into Next.JS Servers Actions

Michał

How to make your code better with Prettier?

Łukasz

TypeScript - A Boon for Developers or an Art for Art's Sake?

Łukasz

Developer is sweaty, TypeScript spaghetti

Michał

Bitnoise_meet #01

Magdalena

GET IN TOUCH