small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

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


As a frontend developer, you are sometimes challenged with optimisation projects. 

Nowadays people perceive the web pages and Internet mostly visually. Apart from the design and pleasing visual appearance, websites need to stand out in areas like short loading time, smooth animations, and small payload.

You, the developer, might also know (or at least intuitively adopt) the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle)
, which more or less states that 20% of the effort generates 80% of the results. 

Sounds great, right? Do some coding, make things work, hand out results to the client, and make some cash. All is fine until the client requests the remaining 20% of the results - to make things pixel-perfect, super smooth, and generally outstanding. 

But sometimes there’s a catch.

**The code of other people**

On occasions, you might be asked to polish someone else's work.

This is precisely a situation that we sometimes encounter at Bitnoise. We improve good things so they become even better. We do the remaining 80% of the hard work so the client ultimately gets the last 20% of awesomeness. 

So what striving for perfection looks like? Well, as Pareto pointed out, it’s not easy. It requires discovering unknown unknowns and it takes a lot of resources (in the coding world - mostly time and money). But it’s worth the effort when excellence is at stake and the client accepts that.

**Where did 16 milliseconds go?**

Recently we got to work on the optimisation of a very nice looking website from Loaded, a gaming industry company. In the world of gaming everything has to be 60fps and smooth like butter. This definitely wasn’t the case with the webpage. The 3D content and layout animations were promising but when you visited the page on a not-the-most-expensive computer, the experience was far from optimal.

Animations were choppy, loading of the page took ages and the laptop fan was spinning so fast that your computer would almost fly away. 

However, when we looked into the code it seemed to be very well organised and structured. You could see at the first glance that it was made by someone who knows how to build a good frontend. We checked out who the original author was and indeed he was quite a respected and known developer on another continent. This was a bit intimidating. If he couldn’t make this site look perfect, how can we do it? But then we thought, “Well maybe he just did the 20% of the work and achieved 80% of the result”?

So we took the challenge and tracked down the pain points of the website. Fixing the performance wasn’t that easy though since it’s not really obvious if changes in existing code won’t break something in an unexpected way or place. Also, discovering what makes the animation degrade from optimal and sustainable 60fps is not trivial. In the process, you usually face code scattered with breakpoints, “console.logs” and “temporary solutions” in order to find out why it takes more than 16 milliseconds for the browser to render some of the animation frames. 

**Make the fan silent again**

In the case of our client's website, the bottleneck appeared to be the overuse of external JS library calculations. The internal workings of that library put too much unnecessary stress on CPU and GPU. The exact same effect could have been achieved with some handcrafted CSS styles and much simpler JS calculations. Modern browsers have quite outstanding optimisations of their CSS rendering algorithms that we as developers should leverage as much as possible. And in this case, we did. 

In the end, the performance boost was huge and the difference was like night and day. No more lost frames, no more low and inconsistent frame rates. And the fan got finally silent. 

There were also a couple of additional optimisations done in the webpage which helped to shorten the initial loading of the page and improve the user experience but the most impactful change was relatively small in terms of lines of code but huge in terms of client satisfaction. 

The lesson learned is that while Pareto is often a great friend, the law can also cause underwhelming results when we strive for a pixel-perfect frontend. At Bitnoise we believe in near ideal interfaces, that's why a 100/100 rule is often our guiding principle. 100% effort means 100% results.  



small_Blog_artykul_Marek_cover_high.png

thumbnail_Blog_artykul_Marek_cover_high.png

Blog_artykul_Marek_cover_high.png

Dev Snapshot: Why is Pareto not Universal in Software Development

Next.js has emerged as a premier framework, excelling in creating applications with React that prioritize performance, superior SEO, and enhanced user experience.

When it comes to deploying Next.js applications, there are two predominant methods:

- Vercel deployment: Originating from the creators of Next.js, Vercel offers a serverless deployment avenue that is straightforward to set up. However, it does not offer complete control over the infrastructure and might prove costly for expansive applications.
- Self-Hosted Infrastructure: While various platforms cater to this requirement, AWS stands out, offering pivotal advantages such as scalability by demand, an extensive suite of cloud services, a cost-effective pricing model, and ubiquitous accessibility.

#### Challenges of AWS Application Orchestration

Orchestrating an application within AWS can pose challenges and consume significant time, more so when establishing distinct many environments with varying configurations.

Here's where the concept of 'infrastructure-as-code' becomes invaluable.

[STT](https://sst.dev/) is a notable solution in this domain. It's a framework optimized for constructing contemporary full-stack applications on the AWS platform. SST not only aids in deploying serverless applications built with Next.js as well as  Svelte, Remix, Astro, or Solid to your AWS account but also seamlessly integrates backend functionalities.

At its core, the framework is underpinned by [AWS CDK](https://aws.amazon.com/cdk/), a robust AWS utility crafted to delineate cloud application resources using familiar programming languages. Essentially, AWS CDK permits the code authoring, which subsequently translates to CloudFormation template files.

#### SST Implementation: A Step-by-Step Guide
Let's see what it looks like in practice:

Adding SST to your Next.js project is extremely simple.

Install the [sst](https://www.npmjs.com/package/sst) npm package in your project root.


`yarn add sst`

SST automatically detects AWS credentials in your environment and uses them for making requests to AWS. The only environment variables that you need to set are:

- `AWS_ACCESS_KEY_ID`
- `AWS_SECRET_ACCESS_KEY`

Now initialize SST in your project root.

`yarn create sst`

This will create the `sst.config.ts` file where all your infrastructure is described as Stacks. Stack contains the code that defines the app's infrastructure; you can create multiple stacks, each with different resources and dependencies, using constructs to add any feature to your app, like a frontend, database, API, cron job, etc.

Below is a sample config of a simple Next.js application:

sample config of a simple Next.js application

Now simply run `yarn sst deploy`, and the infrastructure will be created, and then your application will be deployed on autogenerated or your custom domain.

The final element of any modern development process is the automation of deployment and environment management. We can do this using a tool such as Circle CI, Bitbucket Pipelines, or GitHub Actions. Of course, sst is fully compatible with CI/CD solutions. Below is an example GitHub Actions workflow file that [use OpenID Connect to authenticate with AWS](https://docs.sst.dev/going-to-production#deploy-from-github-actions).

#### The Dev Environment & UI Console of SST
SST provides a dev environment and comes with its own UI console based on your CDK stack that allows you to debug and test your Lambda functions locally.

It invokes AWS resources by proxying the request from your AWS account to your local machine. Changes are automatically detected, built, and **live reloaded**. You can also use **breakpoints to debug** your functions live with your favourite IDE. 

#### The Transformative Benefits of SST

In summary, SST, offers transformative benefits for developers:

Developer Centricity: Serverless architecture liberates developers from the intricacies of infrastructure management. This allows them to focus solely on coding, enhancing productivity and innovation.

Automatic Resource Provisioning: SST cleverly perceives the application's needs and auto-provisions the requisite AWS resources. This not only streamlines the deployment process but also ensures optimal resource allocation, devoid of manual intervention.

Minimized Error Potential: By automating much of the provisioning and configuration process, SST drastically limits the scope for human errors. This augments the reliability and robustness of deployments.

Cost-Efficiency: With serverless, you only pay for what you use. As SST seamlessly manages resource provisioning based on actual usage, resulting in potential cost savings, as there are no over-provisioning or idle resources.

In essence, SST encapsulates the benefits of serverless while providing a streamlined, developer-friendly approach to deploying applications on AWS.

SST has a lot more to offer; you can read about all the features you can use in the excellent documentation. There is also a dedicated discord server where you can get support. Of course, nothing can replace the work of a specialist who will manually fine-tune every element of the environment, but when you need to launch an application or MVP quickly, I think SST is one of the best solutions.

Links:

https://sst.dev/

[SST uses it to build Nextjs apps](https://open-next.js.org/ )

[SST in 100 seconds](https://www.youtube.com/watch?v=JY_d0vf-rfw)

large_blog-Simplifying_NextJS_cover_high.png

medium_blog-Simplifying_NextJS_cover_high.png

small_blog-Simplifying_NextJS_cover_high.png

thumbnail_blog-Simplifying_NextJS_cover_high.png

blog-Simplifying_NextJS_cover_high.png

Simplifying Next.js Deployment with SST

#### 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/)

Developer is sweaty, TypeScript spaghetti

Michał

Simplifying Next.js Deployment with SST

Piotr

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

Łukasz

Dev Snapshot: Why is Pareto not Universal in Software Development

Marek

GET IN TOUCH