small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

#### What is a design system?

Whenever we're talking about a group of components e.g buttons, inputs, icons that share similarities in the design e.g colors, fonts - we're talking about a **design system**.

Whenever we're talking about font families line-heights, or font sizes for given headings and paragraphs (a.k.a typography) - we're talking about a **design system**.

To summarize, a design system is a set of guidelines and components that together create a coherent application. 


#### Advantages of a design system

1. **Consistency:** By introducing visual and interactive elements with a similar color scheme and fonts, a design system ensures that a given application looks and behaves consistently across a whole app or even multiple apps.
 
2. **Implement once, reuse everywhere**: It streamlines the design and development process by providing reusable components and patterns, reducing the need to reinvent solutions for common design challenges.
    
3.  **Scalability:** As applications evolve and new features are added, a design system helps maintain coherence and adapt to changes without compromising the overall user experience.


#### What makes a good implementation of a design system component?

Now that we know what a design system is and its benefits, let's consider for a second what we, front-end developers, need to keep in mind when implementing a component from the design system.

**Ease of use** - every component should have a simple and intuitive API that builds on top of or extends native HTML element attributes. Here are a couple of examples:
- every prop that corresponds to an event handler should start with the `on` prefix `onClick` `onInputChange` `onSelect` since it fits react elements event handlers `onClick` `onMouseEnter` `onMouseLeave`;
- every prop that is a boolean should be in the past participle form, e.g., `disabled`, `focused`, `selected`, since it fits  native HTML attributes, e.g buttons or inputs;

_**These rules are not set in stone and may differ from project to project. However, it's important to decide on one way, before implementation and document it as a guideline for other developers to be aware and follow.**_

**Extensibility** - there can be places within the application where the same component e.g. inputs, has a fixed width of 200px, but should take a full container width in other places. So,  each component should have some form of flexibility to also cover some out of ordinary scenarios.


####  Tools to implement a design system

At Bitnoise, we've designed and implemented many unique and beautiful design systems in React-based applications. Thus, we have a selection of proven tools that help us implement quickly and painlessly.

_**Keep in mind that this tool selection is mostly based on our team’s preferences. Selected tools may differ based on your project demands and team preferences.**_

These are the tools we commonly use:
- **[clsx](https://github.com/lukeed/clsx)** - for managing components classes.
- **[tailwind-merge](https://github.com/dcastil/tailwind-merge)**—to ensure that tailwind classes do not contradict one another.
- **[class-variance-authority](https://cva.style/docs)**—for handling complex component styling that differs based on provided props. For example, a button can have a primary, secondary, or ghost variant.
- **[react-aria-components](https://react-spectrum.adobe.com/react-aria/getting-started.html)** - to ensure our components are accessible and meet WCAG requirements.
- **[storybook](https://storybook.js.org/)** - for having all components list out and documented. It helps to avoid duplicated components and to introduce a new developer into a project.


#### Implementing a component

In this section I will guide you through my process of implementing the components from design systems.

##### 1. Looking at a provided design system

First things first, we need to examine the beautiful design system provided by a UI designer (for simplicity, let's focus on a single part of the design system - typography). 

![blog-heading.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_heading_f729018df3.jpg)


Here are a couple of notes I took by looking at the design:
- we have 6 headings and 2 body texts,
- font sizes, font weights and line heights are as follows:
	- **Heading 1** - 92px, 700, 120%
	- **Heading 2** - 73px, 600, 120%
	- **Heading 3** - 59px, 600, 120%
	- **Heading 4** - 48px, 400, 120%
	- **Heading 5** - 38px, 400, 120% 
	- **Heading 6** - 30px, 400, 120%
	- **paragraph 1** - 24px, 400, 125%
	- **paragraph 2** - 16px, 400, 125%
	- **small text** - Manrope, 12px, 500, 125%


##### 2. Creating utils and utility types

Before implementing the component itself, we will add one utility function and one utility type that will help us in implementing this and other components. 

These utils help keep already long tailwind classes clean and noncontradictory to each other. 

_**If you're not using tailwind, you don't need to have this util... duh.**_

Similar to the built-in react utility type `PropsWithChildren` we're implementing a generic utility type `PropsWithClassName`  to ensure that our components will also accept the className prop and so that we don't need to add them manually in each and every component props.

##### 3. Implementing the component

Now it's time to get our hands dirty and actually start to implement the component itself.
-	Keeping in mind **ease of use** rule described above, we can map Heading 1, ..., Heading 6 to `h1` to `h6` html tags, which is convenient. Paragraphs 1 and 2 should be a `p` tag, and small text can be a `span`.


Now that the basis of the components were implemented, we should add styles for a given tag to match the design system. 


And then we can apply the styles to the component.

So far, so good, but what if we want to have a different color or we want to head 1 to be semibold instead of bold in some places in the application? The component should allow updating styles when needed.

Now overwriting basic styles is possible with new classes provided in the Parent component by using `className` prop. 

##### 4. Using the component in the application

Here's how it looks in the browser:

![blog-hello world.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_hello_world_a7d7835f53.jpg)

#### **Whole component code:**


####  Summary

In this blog post, we've created a very intuitive and simple-to-use component that will handle typography in the application. If the styling of any given tag needs to be updated, it will only require a change in one place instead of looking for specific tags across multiple files.

I hope that walking you through my work process, from looking at a design system to implementing a React component will help you think differently about building components, ensuring they are both intuitive and highly reusable.


large_blog-MICHAŁ GĄSIOREK_cover_high.jpg

medium_blog-MICHAŁ GĄSIOREK_cover_high.jpg

small_blog-MICHAŁ GĄSIOREK_cover_high.jpg

thumbnail_blog-MICHAŁ GĄSIOREK_cover_high.jpg

blog-MICHAŁ GĄSIOREK_cover_high.jpg

Implementing a design system in React

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

Career

About us

Blog

#### **Why do you need automation?**
 When working on a new feature, improvement, or bug fix, it is crucial to ensure that all changes adhere to the rules specified by the linting tools, such as [ESLint](https://eslint.org/)
 and/or [prettier](https://prettier.io/)
. Similarly, it is essential to run tests whenever changes are made to guarantee that there are no regressions.

 With a simple project setup utilizing ESLint for linting, and [jest](https://jestjs.io/)
 and [cypress ](https://www.cypress.io/)
for testing, at some point, you will need to execute the  following command:



 This is a lot to remember and as the project grows there can be more commands to run.  It can become annoying and repetitive really fast to run all of these commands by hand. Moreover, forgetting to run some of them can cause production builds to fail or introduce bugs that could’ve been easily avoided by executing these commands locally.

 It can become quite challenging to remember and manage all of these  commands, especially as the project grows. The list of commands can  quickly become overwhelming and repetitive to execute manually.  Additionally, forgetting to run some of these commands can lead to  production build failures or introduce bugs that could have been easily  avoided by running these commands locally.

Fortunately, there are tools available that can assist you in configuring all the necessary commands to run automatically whenever you need them, relieving you of the need to think about them ever again.

#### **Knock-out repetitiveness with Lefthook!**
[Lefthook](https://github.com/evilmartians/lefthook)
 is an incredibly useful, lightweight, and easy-to-configure tool that automates various aspects of your workflow, including code formatting, test execution, and more!

To begin, you'll need to install Lefthook in your project.





#### **Configure it with ease**
After the installation is complete, you can begin configuring Lefthook by creating a ``lefthook.yml`` file in the project's root directory.



So clean and simple! Now, whenever you commit changes, Lefthook will automatically execute all of these commands. Whenever you commit changes, you should expect to see something similar to this:

![ ](\uploads\blog-Leftook_post_01_6VHv6PDrJMZOEMQSUR0YMM.png)
If Lefthook is not firing, try running the following command:



#### **Built-in features**
 However, this script can be further improved. For example, there is no need to lint the entire project every time you commit changes. Ideally, linting should only be performed on the staged files. 

Moreover, it would be beneficial if the script could also handle fixing any auto-fixable warnings and errors automatically.

Lefthook has you covered with built-in lists of files that can be used for that exact purpose for example ``{staged_files}``.

Updated configuration will look like this:



- ``staged_fixed: true`` makes sure that any file that was changed by ESLint auto-fixing will be re-added to staged files.

- ``glob: “/*.{ts,tsx,js,jsx}”`` makes sure that ESLint is run only against javascript / typescript files within all the staged files.

#### **Running concurrently**
Running each command individually can be time-consuming, particularly when there are numerous commands involved. To expedite the process, Lefthook can execute all the commands in parallel by adding a single line to the configuration file, as demonstrated below:



- ``parallel: true`` will run all the commands concurrently, which should make the whole process a little bit faster.

#### **What else can be automated?**
 Another command that can be automated is the installation of packages whenever you merge changes into your working branch. Other developers may have added different packages at any given time, so it can be advantageous to install them automatically before starting your work.

How to achieve this in Lefthook:





Important to note: ``post-merge`` hook will not run if any conflicts were detected!

Whole lefthook.yml file should like like this:





#### **Conclusion**
Lefthook is a very powerful tool that can help with automating repetitive processes, thus improving the overall developer experience by allowing your team to focus on delivering code that will be linted and tested automatically.

It is very easy to configure in new and existing projects, so I highly recommend trying it out on your own!



small_blog-Lefthook_cover_high.png

thumbnail_blog-Lefthook_cover_high.png

blog-Lefthook_cover_high.png

How Lefthook helps improve development teams’ workflows

Storing information, showing it and giving users the ability to interact with it in some way, shape, or form is the core of every application. The quality of the application is often measured, based on the level of interactivity and responsiveness provided.

In React, when talking about storing something, the first thing that comes to mind is a state. However, as the application grows, it’ll have more and more information to store, so it’s important to manage the state in ***a clean*** and ***readable*** way that is not only ***performant*** but also ***scalable***.

#### **50 shades of state**
From opening modal or handling forms to storing user’s information (like email and password), state comes in many shades, thus it is important to divide it into two categories - **server state** and **client state**:

- **server state** - like the name suggests is anything stored on the server (for example user’s email and password).

- **client state** - to put it simply it’s everything else that is not needed to be stored on a server, for example whether modal is opened or closed.  


It goes without saying, but it’s crucial that both states work together and are in sync, for example when a user updates email, which is stored on a server, the client state should react to that change somehow f.e showing a confirmation snackbar.  

**In this blog post I will tackle client state only so It’s not unnecessary bloated and easier to digest.**

#### **Built-in tools for Client State**
React gives us multiple built-in ways of managing an application’s state with the help of hooks.

**useState**



It’s probably the first react hook anyone trying to learn React gets accustomed to. It’s straightforward and easy to use as it gives a possibility to simply retrieve and update some information.

It’s great for storing simple, ***in more professional language we would call them primitive***, values like booleans, strings or number. However it’s still possible to store more complex data structures like arrays or objects, but it’s important to remember that **state in React is immutable**.

When working with just useState, we can find ourselves calling multiple setStates in a single function, for example, clearing form state:



> React is smart and batches multiple sequential setStates into singular re-render, so it will not have performance implications to have sequential setStates functions, but it can get hard to manage.


And for that reason React has another way for managing state:


**useReducer**



More advanced hook that is useful when working with complex state that have values depending on one another, providing a more redux-like implementation.

A good example would be managing the cart state. As we add items to the cart we also need to update the total price of the order. Instead of calling two separate ***setStates*** from ***useState*** we can just dispatch an action to handle both things **at the same time**.

#### **Limitations of useState and useReducer**
Both **useState** and **useReducer** are good for managing state, but their limitations can emerge as the application grows in size. Especially when:

1. components have similar functionalities (e.g., forms, or modals), so with using just useState and useReducer app can become harder to maintain, due to lots of duplicated code,

2. there are instances where state needs to be shared between multiple components that are not necessarily descendant of one another, and with just useState or useReducer and one-directional data flow in React it can lead to a *prop drilling,*


> prop drilling - passing data through nested components, even those that are not dependent on that state.


#### **Custom hooks abstractions**
The first state management that can be introduced in any react app is ***custom hooks***, by extracting common functionalities and then reusing it anywhere in the codebase, for example **useForm**:



> It is a good practice to wrap any function inside a custom hook in useCallback to prevent unwanted re-renders and behaviors.



By extracting common form functions and making the hook generic it’s now re-usable in every component that requires it. Additionally extending the logic by adding more functionalities to a form can be done in only one place - the hook itself.  

What’s important to note is that each component that uses the hook will have a new instance of the state - **state from custom hooks is not shared between components**, to make sure that state is shared we need to use something else.

#### **Let’s give it some more context…**
To prevent *prop drilling* we can use another built-in feature of React - Context API.

It is a powerful tool that allows moving state ***outside*** of components tree and access or update it in any component inside of its provider. Handling dark mode is a perfect use case.



> It is a common pattern to use context together with custom hooks, so that it's not required to import useContext and context itself in every component.


However, on the [react documentation](https://react.dev/learn/passing-data-deeply-with-context#before-you-use-context)
 is stated, that one should be very mindful when choosing to use context. More often it is just better to send props multiple levels down the component tree, as it helps visualize the data flow within the app.

#### **So what are some drawbacks of using Context API?**
- It requires some boilerplate to create a context.      

- Any change to the state within context will trigger re-render of **any** component that is wrapped with provider (so its best to go as deep in the component tree as possible).      

- It can get messy in figuring out which components are wrapped in which contexts when there are many providers in different places within the app.


#### **Third party joins the chat**
There are plenty of additional third-party libraries that can help with managing the state within the app.

**Redux** could be one of the most known example of such library, however it can introduce some unnecessary complexity as it requires a lot of boilerplate code with setting up store, reducers, selectors and actions making most apps **over engineered** (and can only get more complex as middleware like ***redux-thunk*** is added into the mix).

Thankfully, nowadays there are more modernized tools to choose from, that could be a better fit to specific needs.

I wanted to highlight one specific state management library that I have come to know and love in couple of projects I’ve been working on recently:

#### [**Jotai**](https://jotai.org)

> Jotai means "state" in Japanese



A Light-weight atomic state manager that can be used as a replacement for  React’s Context API. It’s simple to implement with little to none  boilerplate required. Simply:




and that’s it. Atom can be accessed by any component with a help of Jotai hooks:



**It also fixes issue with Context API redundant re-renders - just components that are using the atom will rerender when that specific atom updates.**

When using Context sometimes there is a need to have some on mount functionality, and jotai also provides a solution with **onMount** property, that’s similar to React’s built-in useEffect hook:



Jotai also gives developer a full control over atoms read (getting) and write (setting) behaviors by using read / write function:



which allows to create private atoms that can be changed in only specific ways:





Jotai is also compatible with **Server-side rendering**, but it does require additional step of wrapping the app with ***Provider***.

#### **NextJS (app directory)**


You can learn more about Jotai from it’s nicely prepared [documentation](https://jotai.org/)
.



#### **What goes around comes around...**
For most modern applications, where keeping UI and client state in sync with server state is already solved by libraries like ***react-query*** or ***swr***, there is very little state left to manage solely by the client.

Keeping that in mind more often than not, using just the built-in React hooks and Context API with custom hooks will be **good enough** as it makes your client future-proofed by preventing issues with third party packages, and can make your bundle size more lean.

***Still, handling state on a client is a battle like any other, so it’s good to know your options for when you may need them ;).***



small_blog-FightOfTwoWolves_cover_high.png

thumbnail_blog-FightOfTwoWolves_cover_high.png

blog-FightOfTwoWolves_cover_high.png

The fight of two wolves within state

### 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.

large_blog-DecodingReactUI_cover_high (3).png

medium_blog-DecodingReactUI_cover_high (3).png

small_blog-DecodingReactUI_cover_high (3).png

thumbnail_blog-DecodingReactUI_cover_high (3).png

blog-DecodingReactUI_cover_high (3).png

Developer is sweaty, TypeScript spaghetti


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


Git is a fundamental tool that every developer must have in their arsenal. In a modern and agile world of software development, where codebases are managed by huge teams, having a tool that helps to streamline the process of adding features, changes, or fixes is, without a doubt, a necessity.

Like many tools, git is, with no exception, easy to learn and hard to master. In just one day, an inexperienced developer can learn how to connect to a remote repository, create a branch, push commits, create pull requests, and merge the code. This blog post aims to help developers become more mindful about what and when is being committed to keeping the history well organized, informative and clean.

Keeping the commits history clean helps understand what changes were made to the codebase to backtrack easier if something is not working properly. Not having descriptive commit messages or having too many changes in a single commit are common issues of larger codebases.

![blog-DecodingReactUI_blog_01.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_Decoding_React_UI_blog_01_8c93667a61.png)

#### The easy parts

Every developer knows these commands by heart:

These commands are the foundation of working with Git. However, some of these commands can be slightly modified to create better commits.

##### git add

When working on a new feature, it is often hard to stop in the middle of the process just to create a commit. After some time, the feature is fully implemented. X number of files have been altered, and Y files were added. The time to commit code has come. Instead of creating one big commit, it is often better to have multiple smaller ones, e.g., creating a UI component, creating a test case, updating the types, etc. But the work is already done, so how can one split it now?

Simply by adding `-p` (patch) flag to `git add` command will open an interactive window that will go change by change (it **will not** go through newly created files). Developer will be able to decide whether or not to add given change, skip it or break it down even more. Now all changes regarding the tests, creating new ui components or updating the types can be separated into a different commits. Same file can be committed multiple times containing different changes that are part of a given commit, thus bringing it one step closer to create a clean commit history.

##### git commit

Now that the bigger changes can be grouped into smaller chunks adding a descriptive commit message is next in order.

Adding one `-m` flag will create a header for the commit message that will be shown in the history. However, sometimes one liner is not enough to fully describe the changes because more context is required. Adding another `-m` flag will create a commit's description:

When running the `git log` to display the commit history, it will be displayed as so:

_To quit the git log command, click 'q' on the keyboard._

Descriptions can be improved by adding `$` before the description to introduce better text formatting.


_Adding \n creates a new line_

This will be visible as:


Not every commit requires a description. It is always up to a developer to consider if changes that are being committed require more context or not.

_At Bitnoise, we follow the guidelines laid out by the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) to ensure that our commit messages are well structured. This ensures that commits in the history have a similar structure, making them easier to read._

There can be cases where the commit was made, but there was a typo in the code, or some small improvement was still missing. Instead of creating a new "fix typo" or "remove console.log" commit ```--amend``` flag can be used.


It will add all new changes to the last existing commit, so it's super useful for small updates on the last commit (how to update commits that are higher in the history will also be covered later in the blog post).

_Amending will change the commit hash, so if the commit has been pushed to the remote branch, it will be required to force push; thus, amending on shared branches must be avoided!_

#### Bringing it all together

Moving changes from one branch to another is a crucial part of working with git. It serves three purposes:

- shared branch can be merged to a local branch to have it up-to-date with the latest changes made by the rest of the team,
Local branches can be merged into a shared branch to make the new feature or bug fix accessible to other developers in the team (usually via pull request).
- local branch can be merged to another local branch to have them up-to-date

These cases may seem the same at first - making one branch up-to-date with the changes of the other. However, there is an important difference between the shared branch that is being used by the whole team and the local branch that's being used by one developer. The difference is that on a shared branch, the commit hashes should never change (pushing with force should never be required). On local branches, commit hashes can change (until the changes are not merged to the shared branch), and it will not impact the team's work.

In those scenarios, the developer has access to two different strategies: **merging** and **rebasing**.



**When is it safe to rebase?**

- when updating the private branch with the shared / main branch to preserve linear history.
- When making changes to the commits made on the private branch that are not a part of the shared branch, e.g., editing commits, rewording commit messages, squashing commits, or deleting them.

**When is it not safe to rebase?**

- when working on a shared branch like development or main, it's always better to use merge over rebase to ensure that commit hashes will not change and no forcing push will be required. If merge commits are not needed, `git merge branch-name --ff-only` can be utilized to merge changes without adding the merge commit.

  
##### Interactive rebasing

Where rebase surely shines is the interactive version, which can be used to alter the commit history in many ways.

_ n - number of commits in the history to take into the rebasing from latest to oldest f.g if two latest commits should be rebased, then n = 2_

Interactive rebasing allows you to edit committed files, reword commit messages and even squash or delete commits.

When running the command, it will show a window that can look like this:


For example, above following actions can be utilized to organize the commits better:

_When editing a commit, after editing was finalized, `git rebase --continue` should be executed to move to the next commit_

Rebase will go through each listed commit, execute the desired action, and after completion, replace a commit, thus **changing commit hash**, and move to the next one.

_If the commits were already pushed to the remote branch push with force will be required._

When a need arises to edit a commit message or whole commit that is not the latest one (the latest one can be updated by amending with `git commit—-amend`), interactive rebasing truly becomes handy.

#### More is not always better

On the other hand, having 30 commits for a single feature or bug fix might be an overkill and reduce the history's readability rather than improve it. Sometimes, it makes more sense to join or squash some commits into one bigger commit with more substance.

For example:


The commits above are very granular, and it does not make sense to have them separated like that. One can leverage interactive rebasing to squash these commits easily.

The end result may look something like this:

Now, instead of having multiple remove console.logs, typo fix commits can be organized into one big, easy-to-understand commit.

#### Conclusion

Many developers stop learning git after understanding the basics, which can negatively influence the team's work. Clean history is a part of code documentation and improves not only tracking what was done and when but also reviewing the code in pull requests. Tracking where something could've gone wrong when bug fixing is also less painful if commits are well organized.

This blog post shows that small changes to well-known commands can drastically improve the quality of the commits being created. Adding interactive rebasing into the mix will also make any developer an even better team player.

#### Useful tips and tricks

##### Git game

If you're a beginner and those topics still appear too advanced, you may want to check out this [game](https://learngitbranching.js.org) to familiarize yourself with the git basics.

###### Editing name of the branch

Sometimes, a typo can sneak into a branch when creating it. So here is a flow that will allow me to edit branches to fix the typo. 


##### Removing all local branches

When working on a big project, sometimes a lot of old branches can be deleted. Instead of going branch by branch, this command can be used to delete all local branches:

Implementing a design system in React

Michał

How Lefthook helps improve development teams’ workflows

Michał

The fight of two wolves within state

Michał

Developer is sweaty, TypeScript spaghetti

Michał

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

Michał

Git Gut: Take care of your commits history like a pro

Michał

GET IN TOUCH