DEV Community: Emmanuel Isenah

Password Composition Policies Are Bad and Here's Why

Emmanuel Isenah — Mon, 23 Dec 2024 07:38:40 +0000

Passwords are the most widely used form of authentication on the internet. And unless you're Nelson Dellisa-six-time USA Memory Champion-most of us tend to pick the easiest passwords we can remember when creating one.

I must admit, I've never been a big fan of passwords, especially with the availability of more secure authentication options like OAuth, magic links, and passkeys. Passwords inherently carry more security risks compared to other alternatives and have to be paired with Multi-Factor Authentication (MFA) to be considered truly secure.

Secure password generation is complicated by the tradeoff between developing passwords which are both easy to remember and difficult to crack. To help guard against the latter, password composition policies are enforced to coerce users to create secure passwords. However, they often fail to achieve their intended purpose.

I'm sure you've experienced this before: you go to a website's sign-up page, and you're prompted to create a password with minimum 8 characters, 1 uppercase letter, 1 lowercase letter, 1 number, and 1 special character. Next thing you know, you find yourself substituting letters for special characters(e.g, a with @) and appending numbers to the end of your password. This can be really frustrating because your password may be secure already.

Fortunately, in recent years, the rise of password managers has helped dampen this issue. We are now able to create long, random passwords for each site we visit and at the same store them securely. But password managers aren't widely adopted yet in the space, so the original issue still semi persists.

This matter of subject is luckily very well researched and has been discussed by many security experts, with the most notable being the National Institute of Standards and Technology (NIST). They have published guidelines on digital identity management, which one of them talks about password composition policies called SP 800-63B. Not gonna lie--It's a long read. But it's definitely worth it, as it gets updated regularly to keep up with latest findings.

Also there's a published paper by Florida State University on password creation policies where they test real leaked passwords from database breaches against composition policies to examine the result effect.

I'll be referencing both of these in this article to better explain to you why password composition policies are bad and what better approaches we can take to encourage users to create secure passwords. It's also good note that I'll be focusing only in the application of online environments, not offline.

Without no further ado, let's dive in.

Composition Policies and Entropy

Composition policies are rules that dictate what constitutes an acceptable password to the user before they can proceed to create it. These rules typically include requirements like a minimum length, a mix of uppercase and lowercase letters, numbers, and special characters. The goal is to make the password more secure by increasing the entropy (more on that later). For example, a policy might mandate users include at least one digit in their password.

However, research consistently shows that users respond to these requirements in predictable ways when forced. In the Florida State University research paper, after performing a dictionary attack on 14 million passwords from RockYou database breach, researchers found that users often appended a digit to the end of an otherwise weak password. This highlights how composition policies can fail to deliver their intended security benefits. Heres what they further had to say:

"It shouldnt come as a surprise that most people simply add digits to the end of a base word when creating a password. If we filter the training list to only include passwords that also contained one non-digit, the number of users who appended a digit to the end of their password jumped to 77.46%."

You can utilize Have I Been Pwned API to confirm this yourself if in doubt.

Another important observation is that the numbers users choose are often predictable too. What do I mean? According to the same research paper, the digits 1 through 9 account for 36.25% of the top 10 most common digits used in passwords, with 1 being the most frequent.

The above pattern extends to uppercase letters and special characters as well. Over 50% of users capitalize the first letter of their password when required to include an uppercase character, while 36.37% append a special character to the end of their password.

Interestingly, when composition policies require both a special character and a digit -a common requirement seen in most policiesit was found that special characters are more often followed by a digit rather than the other way around.

All these significantly reduces the key-space of possible passwords, making them easier to guess. In the event of an attack, a malicious actor would be fully aware of these constraints and their predictable effects. They would leverage this knowledge to reduce the number of possible guesses needed to crack the password.

Quoting NIST, here's what they have to say on composition policy:

"Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."

Note: Verifiers are entities that verify user credentials during the authentication process, while CSPs (Credential Service Provider) are the entities that manage and store the user's credentials.

It might not be obvious, but increasing the key-space (the total number of possible combinations for a password) through composition policies doesn't out right reduce the number of guesses needed to crack the password. Yes, youre correct-it increases the entropy. But higher entropy doesn't always equate to lower guessability. Why?

Well Shannon's entropy theoretically assumes outcomes are evenly distributed which isn't true for most real-world password distributions. For example, "123456" is far more common to be found in human-choosen password than, say, "vH8$dq@".

Shannon's Entropy is the measure of theoretical unpredictability of a password based on the possible combinations of characters.

So in essence, even if it's higher, it doesn't necessarily convey to us how secure the password is. It's like saying a password with 10 bits of entropy is more secure than a password with 8 bits of entropy--it's hard to tell without extra analysis.

For example, "Abcdef123456@" has a higher entropy than "ohgreatsully" when calculated, yet the latter is significantly less guessable in a dictionary attack and would take centuries to crack using brute-force.

	Entropy	Strength
Qw3rtyui!	28.53	Weak
ohgreatsully	41.00	Strong
YjCK^i0jMYvjfp	46.55	Strong
Abcdef123456@	48.11	Weak
sillyunicornsflyhigh	68.93	Strong

This highlights that entropy alone isnt a reliable indicator.

Highly complex passwords introduce another challenge: they're harder to remember, making users more likely to write them down or store them insecurely.

This comic from xkcd perfectly summarizes it:

While secure storage solutions like password managers exist, survey shows that only about 32% of people (at best, based on data from a subset of countries) actually use them, according to Bitwarden's World Password Day Survey 2024. With such low adoption rates, I would say this should be an extra motivation not to enforce long and complex passwords upfront.

Despite everything I've said so far, there's one exception to the rule: the minimum length requirement. It is the only useful recommended composition policy--provided it's used within reason.

This is because the number of possible combinations increases exponentially with the length of the password. For example, a 10-character password has 26^10 possible combinations, while a 20-character password has 26^20 possible combinations.

Here's NIST's take on password length:

"Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length."

Password length is the primary factor in characterizing password strength, so users should be encouraged to make their passwords as lengthy as they want. The more characters in a password, the more secure it is. Too short would put the users at risk to brute-force and dictionary attacks.

A Better Approach

So far, we're looked at what not to do. Now, let's touch on what to do to improve password security without the need for composition policies:

Check Passwords Against a Blacklist

"...verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords"

"If the chosen password is found on the blocklist, the CSP or verifier SHALL require the subscriber to select a different secret and SHALL provide the reason for rejection"

One of the most effective ways to improve password security is to check passwords against a blacklist. This typically includes:

Compromised passwords from previous database breaches.
Common dictionary words.
Context-specific words, such as the name of the service or platform.

If a password matches an entry on the blacklist, it should be rejected, and the user should be prompted to choose a different password, with a clear reason for rejection provided.

According to one of the test cases carried out in the Florida research paper, a blacklist of 50,000 entries was tested against 32 million compromised passwords with a maximum of 256 guesses. The results showed that the percentage pool of passwords found to be crackable with the blacklist was 0.058% , compared to up to 14% without one.

You can use the Have I Been Pwned API to access up-to-date list of compromised passwords for your blacklist.

However, in as much as blacklists are incredibly useful, they come with a hard limitation: they can only compare entire strings, not substrings or individual words contained within a password. This caveat makes it impossible to detect sub-patterns.

But wait--theres solution!

Evaluate Password Strength, not Complexity

Building upon blacklists, we can take it a step further by creating a function to dynamically evaluate the guessability of the password based on multiple factors such as:

Length
Dates
Repeated characters (e.g., aaaaaa)
Sequences (e.g., abcdef, 123456)
Keyboard layout (e.g., qwerty)
Leet-speak substitutions (e.g., H3ll0Hello)
Brute-force weaknesses
Entropy

We take into account all these factors and score them individually, with their total sum forming the guessability score for the password. With this score in hand, we can reject any password whose guessability falls below a set threshold.

You might be thinking to yourself-- "That's sound like a lot of work". And you're absolutely right. Fortunately for us, some fantastic engineer at Dropbox already created a tool to solve this very issue a while back called zxcvbn.

Albeit, it's now old and unmaintained, there are fork implementations available for nearly every programming language out there. For JavaScript users, you can check out zxcvbn-ts.

Here's what NIST has to say on password strength estimation:

"Verifiers SHALL offer guidance to the subscriber to assist the user in choosing a strong password."

Effectively, with the guessability data from our password strength estimator of choice, we can use that response to create strength meters, alert cards, etc. to guide the user into creating more secure passwords.

Live Demo 🔴

To showcase estimating password strength, I built a web app that lets you compare composition policies against guessability metrics using zxcvbn-ts and Have I Been Pwned API. You can check it out here.

Upon inputting your password, you'll get to see its guessability score, estimated time to crack, pattern matches, and whether it has been compromised. You can find the source code here.

As shown in the screenshot below, P@ssword1 meets all composition policy requirements but returns a terrible guessability metric. Go ahead and give it a try for yourself.

Conclusion

Hopefully, I was able to demonstrate to you that the concept of password entropy, as commonly applied by the most websites (through composition policies), fails to serve as a reliable metric for assessing the security of password when used on its own.

A significant subset of users will still choose easy-to-guess passwords, like P@ssword1, that technically comply with the policy but remain highly vulnerable to attackers.

It's time we move past strict password composition policies--they're not helping anyone. We've seen that it's possible to improve password security without sacrificing user experience.

If you're still not convinced, you can also consider implementing Multi-Factor Authentication (MFA). That way even if a password is compromised, the attacker can't gain access without the second factor.

That's all I have for now. Thanks for reading and I hope you found this article helpful.

Unveiling React Server Components

Emmanuel Isenah — Tue, 23 Apr 2024 07:20:24 +0000

React has undergone a significant evolution since its inception in 2013, transitioning from Higher-Order Components (HOCs) and lifecycle methods to the introduction of hooks in 2019. Now, one of the most recent and monumental changes is the advent of React Server Components. It opens the doors to running React code exclusively on the server.

Similar to how hooks revolutionized how we code in React, RSCs represent another paradigm shift. However, there's been widespread confusion surrounding their functionality, particularly regarding how they tie well with traditional Client components.

In this blog post, we'll walk through the timeline of React, explaining Server-Side Rendering (SSR), Suspense, Component Boundaries, RSCs, what they aim to solve, and how they all interconnect to shape the React as we know today.

What is Server Side Rendering?

To understand React Server Components (RSCs), we need first to understand how Server Side Rendering works (SSR) and what it tackles. So what is the SSR you might ask? In the simplest terms, it is the generation of HTML from React components on the server. This server-rendered HTML is then sent down to the browser allowing users to view the content of the page while the JavaScript bundle loads and runs.

Before SSR became a thing, users would stare at a blank white page before React could bootstrap the page and attach event handlers. This rendered a bad user experience for users with a poor internet connection (because you have to download the JS bundle first) and users with low-end devices as the JS script has to be parsed and executed, leading to longer FCP (First Contentful Paint).

The typical HTML file sent down looks a lot like the below:

<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>
    <script type="module" src="/assets/js/bundle.js"></script>
  </body>
</html>

The bundle.js (usually named with random hash strings as the filename) is the minified bundled output of our application code and contains everything including third-party dependencies needed to run on the browser. This is commonly referred to as the traditional "client-side" rendering strategy (CSR).

Server Side Rendering was introduced specifically to solve this very problem. Instead of viewing a blank page till React bootstraps the page, the server can send a pre-rendered HTML presentation of the content. Albeit, it won't be interactive still event handlers are attached. This illusion creates a better UX.

It is achieved using react-dom/server APIs, specifically the renderToString method. This API method helps render a React tree to an HTML string like so:

//SERVER
import { renderToString } from "react-dom/server";
import App from "./App.js";

const html = renderToString(<App />);

Then on the client, the browser calls hydrateRoot to make the server-generated HTML interactive. This is accomplished through a technique called hydration.

//CLIENT
import { hydrateRoot } from "react-dom/client";

const domNode = document.getElementById("root");
const root = hydrateRoot(domNode, reactNode);

Hydration you say? What is that?

Well, hydration is the process of using client-side JavaScript to add application state and interactivity to server-rendered HTML. To quote Dan Abramov on his GitHub gist about SSR:

Hydration is like watering the “dry” HTML with the “water” of interactivity and event handlers.

React will attach to the HTML that exists inside the domNode, and take over managing the DOM inside it. It will attach event handlers, fire off any effects, and so on.

However, for frameworks like Next.js, Remix, etc., SSR could come in different forms or rendering strategies. It could be static or dynamic. Let me explain:

Static Rendering: With static rendering, components are pre-rendered at build time, or in the background after data revalidation. The output is then cached and pushed to be served by a CDN. This rendering strategy is only used when the data in a component can be known at build time, such as a static blog.
Dynamic Rendering: With dynamic rendering, all components or routes are rendered each time at request time. This means when a client fetches UI components from the server, it is rendered dynamically based on information that can only be known at request time such as cookies or URL search params. This strategy ensures that the returned response is always up-to-date and tailored to the specific request.

And that's everything to know about Server Side Rendering. It's not a new concept and has actually been part of React since its inception. Don't believe me? Here are the release notes from v0.4.0. Albeit, the SSR back then wasn't the same as what we have today, it was always in the works.

That aside, SSR until recently posed two major imperfections despite being better than "client-side" rendering (CSR).

Flaws of Legacy SSR

With the previous SSR, pre-rendering of the HTML and hydration were an "all-or-nothing" decision. This meant for the server to respond with HTML to the client, all components must have their data ready beforehand. It needed to wait for all blocking components to be ready before it could start sending any pre-rendered HTML. This was its first flaw.

The second major flaw was that React had to hydrate every JavaScript code before you could interact with the UI. This meant that once React starts calling your component functions, it won't stop until it's done with your entire tree. While this issue may be arguable for users with high-end devices, it proves untenable for general use cases. Especially if the user wants to navigate out of the current page quickly, but can't do so due to hydration blocking interactions.

The above problems contain one common pattern: they require the selection of performing only one task at a time. As recently discussed, in SSR, a sequence of stages must be completed before users can view and interact with a page. Due to this sequential nature, they act as blocking operations, preventing the server from advancing to the next stage until the preceding one is finished.

What if we could split up these sequential stages to be handled asynchronously for each part of the page?

Luckily, the React team foresaw this problem and created what we know today as Suspense.

Streaming with React Suspense

Streaming allows us to break down a page's HTML into smaller chunks and progressively send those chunks, bit by bit, from the server to the client. The result of this is:

Pages display earlier, eliminating the need to wait for data loading on the server.
Interactivity with the page is enabled sooner, bypassing the necessity to wait for the entire DOM tree to complete hydration. (More on this later on)

This is accomplished through the API renderToPipeableStream, which utilizes Streams API under the hood.

Streaming isn't anything new as browsers have long utilized it for handling media assets; videos buffer and play as additional content downloads.

It aligns perfectly with React's core component model as each component could be classified as a chunk. Components that don't depend on dynamic data, such as a Navbar, can be prioritized and sent down first for earlier hydration. Subsequently, other components could be transmitted once all their required data has been fetched.

For example, consider we have the following component structure:

const Page = () => (
  <Layout>
    <NavBar />
    <Sidebar />
    <main>
      <PostFeed />
      <Comments />
    </main>
  </Layout>
);

Which will be rendered to this:

The components <Comments/> and <PostFeed/> require data fetching. Thus, it's preferable to instruct the server not to wait for their readiness and instead send a fallback UI (e.g. skeleton, spinner) in their place. We can achieve this by wrapping them both in <Suspense>.

...
<Suspense fallback={<Spinner />}>
  <Post />
  <Comments />
</Suspense>
...

React will now display a spinner component while they get ready:

If we further inspect the returned HTML, we'll find neither component in the DOM tree - <Comments /> or <PostFeed /> .

<div id="root">
  <nav>
    <!--NavBar -->
    <a href="/">Home</a>
  </nav>
  <aside>
    <!-- Sidebar -->
    <a href="/profile">Profile</a>
  </aside>
  <main>
    <!-- Spinner -->
    <img width="200" height="200" src="/static/spinner.gif" alt="Loading..." />
  </main>
</div>

Once both components are ready on the server, using the pre-existing stream, additional HTML, along with an inline <script> , will be sent to replace the fallback element. Since this comprises solely of HTML, React doesn't even need to be loaded at the time for the components HTML to display.

With this approach, we don't have to delay our pre-rendered HTML from being sent down anymore due to a component or groups of components.

Early Adoption

Suspense queitly made its debut in 2018 in the form of React.lazy. Initially, it only supported lazy-loading code on the client. Despite its limited scope upon release though, its overarching goal was to integrate with Server-Side Rendering.

I previously hinted at the advantage of "Interactivity with the page is enabled sooner" when discussing the benefits of Suspense. This is enabled by a concept called "Selective Hydration."

Quick Memo on Selective Hydration

Wrapping our components with <Suspense> brings one more improvement that's not immediately apparent: hydration no longer blocks the browser from performing other tasks.

This improvement is due to React's intelligent prioritization of hydration based on user interaction. For instance, when a user triggers an event like a click, React ensures that the corresponding components along the interaction path are prioritized for hydration. This includes traversing up the component tree, ensuring that every relevant component is hydrated until a Suspense boundary is encountered.

Also when React hydrates components within a Suspense boundary, it does so in small intervals where the browser still retains its ability to handle events. This guarantees the UI remains responsive during prolonged hydration periods.

Now, let's imagine that hydration for <Comments /> hasn't occurred yet, while the <PostFeed /> component is currently undergoing hydration. Both their code has being downloaded also.

Now, if we were to click on <Comments /> rendered HTML.

In the same capture phase of the click, React will stop whatever it's doing and urgently hydrate <Comments /> just in time to respond to the click event.

To quote Dan Abramov again:

This creates an illusion that hydration is instant because components on the interaction path get hydrated first.

Following that, React will proceed to hydrate the remainder of the application.

And that's how our pages appear to be more responsive more quickly. By utilizing Suspense, we automatically opt into all these features. For more details, you can explore the documentation.

So far, we've discussed what Server-Side Rendering (SSR) is and how well it integrates with Suspense. However, there's one more ingredient we could add to the mix to make our dish complete.

In all our previous examples, our React code has consistently run on the server to generate an initial shell and then is sent down to the client, to enhance the loading experience to feel somewhat faster. We've even explored the possibility of streaming the chunks of HTML. However, what if we wanted to execute code exclusively on the server and send down only the outputs (without the source code)?

For instance, imagine we want to query our remote database. This hasn't been feasible so far with React, even with Server-Side Rendering. Our components still get rendered on both the server and the client.

Meta frameworks like Next.js and Remix each introduced their own solutions. Next.js implemented getServerSideProps, Remix introduced loader functions etc. These solutions enabled us to run some code ahead of rendering our components. However, they each had their drawbacks, including inconsistent implementations (no official standard) and limitations such as only functioning at the route level (components at the top of the tree).

Fortunately, the React team came up with an official standard to address this problem: React Server Components.

New Paradigm: React Server Components

React Server Components (RSCs) represent a fundamental shift by executing code on the server rather than the client. This also grants us access to server infrastructure such as file systems and data stores. Essentially, anything runnable in a Node environment can be executed within RSCs. But this also comes with a trade-off; a significant portion of React and Web APIs become incompatible.

Here is a simple example of a server component:

import { PrismaClient } from "@prisma/client";

export const Page = async () => {
  // Connect to the database
  const db = new PrismaClient();

  // Fetch all blog posts that contains keyword "Next"
  const results = await db.post.findMany({
    where: {
      title: {
        contains: "Next",
      },
    },
  });

  return (
    <>
      <h1>Blog posts</h1>
      {results.map((item) => (
        <article key={item.id}>
          <h2>{item.title}</h2>
          <p>{item.content}</p>
        </article>
      ))}
    </>
  );
};

export default Page;

There's a lot to address here. Initially, one might wonder how our component is capable of being asynchronous. You might argue our async call is going to trigger on every render. While this skepticism would be valid for a "Client component" (more on this later), it doesn't apply in this case.

The thing is, Server Components do not actually re-render. They're rendered only once on the server to the generate UI, and the result is sent down. Hence, why certain React APIs become incompatible as interactivity isn't needed.

If a state change occurs and we wish to display the fresh update, we can call router.refresh. This action will trigger a new request to the server, prompting the re-rendering of Server Components, and then merge the updated RSC payload without losing the client-side state.

In the code example, we're also establishing a connection to our database using our preferred ORM. Due to the environment isolation of RSCs, we avoid exposing confidential secrets (e.g., DATABASE_URL) while eliminating unnecessary round trips (zero waterfalls).

Considering that our servers are also consistently provisioned closer to our data sources (e.g., database, message broker), RSCs will always resolve quicker (in terms of latency).

It's good to know in this shifting landscape, what we commonly refer to as "Client components" are traditional React components imbued with interactivity. Even though the name implies they're only rendered on the client, this isn't the fact as they're pre-rendered on the server too due to SSR. Honestly, the naming convention can be a bit misleading—a misnomer, if you will—but it's what everyone calls it.

Component Boundaries and Directive

By default, all components are opted-in as "Server Components". To make a component or module client-side, we have to explicitly opt-in using the "use client" directive. This is usually carried out by specifying it at the top of the file:

"use client";

import React, { useState } from "react";

const Counter = () => {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
};

export default Counter;

This directive signals React to execute the module on the client side. Additionally, it's important to note that by adding a directive, the same effect is applied to transitive dependencies—modules that are directly imported.

NOTE: There's also an additional directive called "use server". It is currently used for Server Actions and has a totally different behaviour.

When a file is marked with 'use client' and is imported from a Server Component, it serves as a boundary in the module dependency tree between code intended for server-side execution and that meant for client-side execution.

It's important to differentiate between a module dependency tree and a render tree because they each capture a different hierarchical structure of an app. What leads to this distinction?

The module dependency tree outlines the relationships between modules in terms of their dependencies and imports. This tree helps bundlers determine the dependencies of each module and how they should be packaged for deployment.

On the other hand, the render tree focuses solely on component modules, excluding non-component modules. It represents the flow of components as they render in the application.

In my personal opinion, I find it much simpler to visualize boundaries within a dependency tree compared to a render tree. The mental model becomes increasingly complex when JSX is passed as props between components. This is because directives become automatically applied to modules directly imported into the component.

Consequently, in a render tree, we might encounter a scenario where a server component acts as a child to a client component. Yes, this scenario is indeed possible, which can lead to confusion in understanding the execution environment of each component.

To better illustrate this, take for example the following component structure:

codesandbox.io

In our render tree, we have three components: Comp A, which is a conditionally rendered server component that accepts Comp C as children; Comp B, a client component; and Comp C, which serves as both a client and server component.

Comp C is a client and server component? How is that even possible?

Well, when a component is defined in a module with a 'use client' directive, or the component is imported and called in a Client Component, then the component is a Client Component. Otherwise, the component is a Server Component.

In this scenario, Comp A receives Comp C as a child component, but it neither directly imports the module nor calls the component itself. As a result, Comp C doesn't appear as a node under Comp A. According to the definition provided earlier, Comp C becomes a server component by usage, as it's the parent App component that executes it.

On the other hand, under Comp B, Comp C is directly imported and rendered, making it a dependency of Comp B. Therefore, Comp C becomes a client component in this context.

It's important to note that if Comp C had interactivity or utilized unsupported Web APIs, React would raise an error because a server component can only be a child node to a client component in the module dependency tree if passed as children.

When Components Should be Rendered as Client Components?

In general, if a component can be rendered on the server without any issues, it's best to keep it as a server component. This is beneficial due to the performance boosts provided by RSCs. However, since most applications require some level of interactivity in reality, not every component can be a server component.

My advice would be to thrive on making Client Components primarily as leaves within the component tree. Ideally, they should be positioned as far down a branch as possible, ensuring that their children do not inherit the "use client" directive.

RSC Under the Hood

Have you taken a moment to inspect your network tab to view the response of a Server Component? It's noteworthy that RSCs aren't sent down as a JS script file.

On the server, React renders your Server Components into a special data format known as an RSC Payload. Then on the client, React downloads and parses the payload to resolve where to render the elements. The output structure resembles JSON a lot, that's because it mostly is.

Before inspecting the payload, there are a few things we need to first glance at.

React serializes components rendered on the server, along with any props passed from a Server Component to a Client Component. If you're familiar with JSON.stringify, then you're likely aware that not all types are serializable.

let map = new Map([[1, 'one'], [2, 'two'], [3, 'three']]); ❌
let set = new Set([1, 2, 3]); ❌
let arr = [1, 2, 3]; ✅
let json = JSON.stringify({ map, set, arr });


console.log(json);
// Output: "{"map":{},"set":{},"arr":[1,2,3]}"

To combat this, React uses a custom mapper. This custom mapper under the hood uses JSON.stringify but with a replacer function to support non-serializable types. Depending on the type of the value, it performs a specific serialization operation. For example, if the value is a promise, it waits for its resolution and serializes the resolved value by calling serializePromiseID.

The serialize functions execute two purposes:

They take in the id of the serialized type and converts it into a string representation.
They prefix this resulting string with a dollar symbol and an identifier character to signify the unique type. For instance, 'W' for sets, 'Q' for maps, etc.

Thereafter, on the client side, React utilizes these unique prefixes to reference and deserialize the JSON string back to its original form.

That's enough talk. Let's add a new route with some non-default serializable types to see what the payload actually looks like. We'll still be using the code from our previous CodeSandbox.

/app/new/page.js

import Link from "next/link";

export default function Page() {
  return <Link href="/">Prefetch</Link>;
}

"use client";
// Converted CompA from server component to client
const CompA = ({ json }) => {
  return (
    <>
      <div>
        {json.map.constructor.name} {json.map}
      </div>
      <div>
        {json.set.constructor.name} {json.set}
      </div>
    </>
  );
};
export default CompA;

If we visit the route /new and renavigate back to the root page using the Link component, we should get this response in our network tab. Due to SSR, the RSC payload can only be seen on subsequent navigations. If you were to load /new as your initial load, you'd only get an HTML response.

2:I["(app-pages-browser)/./app/CompA.js",["app/page","static/chunks/app/page.js"],""]
5:"$Sreact.suspense"
6:I["(app-pages-browser)/./node_modules/next/dist/shared/lib/lazy-dynamic/dynamic-bailout-to-csr.js",["app/page","static/chunks/app/page.js"],"BailoutToCSR"]
3:[[1,"one"],[2,"two"],[3,"three"]]
4:[1,2,3]
0:["development",[["children","__PAGE__",["__PAGE__",{}],["__PAGE__",{},["$L1",[["$","$L2",null,{"json":{"map":"$Q3","set":"$W4","arr":[1,2,3]},"children":["$","h2",null,{"children":"Above 12:00 PM"}]}],["$","$5",null,{"fallback":null,"children":["$","$L6",null,{"reason":"next/dynamic","children":"$L7"}]}]],null]],[null,"$L8"]]]]
9:I["(app-pages-browser)/./app/CompB.js",["app/page","static/chunks/app/page.js"],""]
7:["$","$L9",null,{}]
8:[["$","meta","0",{"name":"viewport","content":"width=device-width, initial-scale=1"}],["$","meta","1",{"charSet":"utf-8"}],["$","title","2",{"children":"Create Next App"}],["$","meta","3",{"name":"description","content":"Generated by create next app"}],["$","link","4",{"rel":"icon","href":"/favicon.ico","type":"image/x-icon","sizes":"16x16"}],["$","meta","5",{"name":"next-size-adjust"}]]
1:null

Right out of the gate, the first notable observation is each line begins with a number, followed by a colon, and sometimes proceeded by the character "I". After that, the remaining data appears to be JSON.

3:[[1,"one"],[2,"two"],[3,"three"]]
4:[1,2,3]
...,
    ...,
        [
          "$",
          "$L2",
          null,
          {
            "json": {
              "map": "$Q3",
              "set": "$W4",
              "arr": [1, 2, 3]
            },
            "children": [
              "$",
              "h2",
              null,
              {
                "children": "Above 12:00 PM"
              }
            ]
          }
        ]
    ...
...

I went ahead and removed some lines of the payload to analyze the essential parts.

There are a few key elements to decipher here. Notably, we can see our serialized set and map appear as the third element in the node array, each accompanied by their respective IDs. If further look down, you see where they are referenced by the id with theirs respective identifier prefix. The identifier prefix informs React about the data type for proper parsing.

What about the second element in the node? It represents the current level node, which could be either an HTML tag or a component. In cases where the node is a client component, it points to the payload line referencing the JavaScript file. This explains why some lines have an "I" prefix, as they reference a JavaScript file on the client.

Everything beyond "$L1" which represents the route segment component, constitutes a proper node with an expression resembling this:

["$", "p", "0", { "children": "I'm a child node" }]

Which gets interpreted to the below in the DOM:

If you're curious to play around with parsing of RSC payload, check out this dev tool by Alvar Lagerlöf. It provides a visual representation of the payload with intuitive UI components.

Additionally, there's a minimal RSC demo without SSR built by the React team. It saves you the hassle of setting up a project to explore RSCs. Also, since it lacks SSR, you can access the RSC payload upon the initial page load without navigating.

Conclusion

The advent of React Server Components marks a milestone in the way we code in React today. By shifting the heavy lifting of rendering to the server, we can achieve faster load times and ship less JavaScript bundles to the browser. Consider the image below, depicting legacy SSR:

However, by integrating Suspense and React Server Components, we can achieve results like the following:

And if we want to take things to the next level, there's a new feature released in Next.js 14 (albeit currently experimental) called Partial Prerendering. If we utilize it, we can essentially eliminate the initial pre-render block, ensuring that content is delivered instantly upon user request.

These are exciting times to be a web developer as the ecosystem continues to push out new technologies each day. I'm filled with optimism for the future and hope that this blog post has successfully revealed the capabilities of React as it stands today.

What's New in TypeScript 5.4 Beta

Emmanuel Isenah — Thu, 08 Feb 2024 08:28:06 +0000

Greetings! TypeScript 5.4 Beta just dropped and it presents new exciting features with some bug fixes and QoL changes. Without further delay, let's quickly explore some of these game-changing improvements.

`Object.groupBy` and `Map.groupBy`

One of the new API changes added in TypeScript 5.4 Beta is the declarations for upcoming JavaScript methods: Object.groupBy and Map.groupBy . These static methods simplify the grouping of items in an array (and iterables such as objects or maps) far easier.

It works by accepting an iterable and a function that classifies which group each element should be placed in. The result of this function is then used to create an object key for each distinct group and adds the original element to an array for every key. Here's an example:

const people = [
  { name: "Alice", age: 25 },
  { name: "Bob", age: 42 },
  { name: "Charlie", age: 60 },
  { name: "David", age: 30 },
  // ... more people
];

// Group people by age range
const ageGroups = Object.groupBy(people, (person) => {
  if (person.age < 30) return "young";
  else if (person.age >= 30 && person.age < 60) return "adult";
  else return "senior";
});

The result of the above is well equivalent to this:

const people = {
  young: [{ name: 'Alice', age: 25 }, { name: 'David', age: 30 }],
  adult: [{ name: 'Bob', age: 42 }],
  senior: [{ name: 'Charlie', age: 60 }]
};

And this can be done with other iterables such as arrays or maps.

For Map.groupBy, it performs equivalently to Object.groupBy, but instead produces a map as output rather than a plain object.

const fruits = ['apple', 'banana', 'orange', 'kiwi'];

// Group fruits by their first letter
const letterGroups = Map.groupBy(fruits, (fruit) => fruit.charAt(0));

// Resulting map:
// Map {
//   'a' => ['apple'],
//   'b' => ['banana'],
//   'o' => ['orange'],
//   'k' => ['kiwi']
// }

A good thing to note is the objects produced end up as a Parital record as there's no concrete way for the compiler to ensure all keys were created. To access variables, you'll have to use an optional chaining operator or check for undefined.

type AgeGroup = Partial<
  Record<"young" | "adult" | "senior", { name: string; age: number }[]>
>;

ageGroups?.young // OK
ageGroups.young && ageGroups.young[0].age; // OK
ageGroups.young[0].age; // Error: Object is possibly 'undefined'

This static method is yet to be included in the standard as it's a pending TC39 proposal. However, it's in stage 4, indicating that it will be included in the next stable release, ES2024. To use these methods currently, you have to change your target and lib to ESNext in your tsconfig settings.

`NoInfer` Utility Type

For a long time, there have been situations where you have a generic function with multiple arguments or properties of the same type parameter, but don't want to infer all the types to the generic value. This utility type precisely addresses this issue, providing more control over which types get inferred.

Let's consider a function that receives a list of values, such as fruits in this example, along with a default value.

declare function getValue<T>(values: T[], defaultValue: T): T;

// Example: Without NoInfer<T>
const result = getValue(["apple", "lemon"], "apple"); // OK

For this example, TypeScript infers the type of result as "apple" | "lemon" as it should be. But what if we changed our default value to something very different?

const result = getValue(["apple", "lemon"], "bomb"); // Also OK

Currently, the inferred result is "apple" | "lemon" | "bomb." But you may wonder, why is that the case? Isn't our "values" parameter intended to be our source of truth, allowing us to choose an initial value exclusively from there? Indeed, it should be, but a subtle nuance exists. As both share the same generic type, "bomb" is regarded as a valid inference candidate, akin to the list of values. In simpler terms, TypeScript will infer the values of defaultValue into the union of fruits T.

One common approach that comes to mind to address this is to add a distinct type parameter that extends our intended type parameter.

declare function getValue<const T, U extends T>(values: T[], defaultValue: U): T;

const result = getValue(["apple", "lemon"], "bomb");
// Error: Argument of type "bomb" is not assignable to parameter of type ("apple" | "lemon")

This also works but it's a bit more verbose and generic D most likely won't be used anywhere else in the signature.

This is where the new utility type NoInfer comes in. By surrounding our type in NoInfer<...> , TypeScript will skip to adding the type parameter as a candidate for type inference.

declare function getValue<const T>(values: T[], defaultValue: NoInfer<T>): T;

// Example: With NoInfer<T>
const result = getValue(["apple", "lemon"], "bomb");
// Error: Argument of type "bomb" is not assignable to parameter of type ("apple" | "lemon")

By excluding the defaultValue type, we ensure that whatever is inputted isn't included in the union of values returned or inferred by our function.

Now previously before this utility type was officially introduced, the community had created a workaround type to combat this issue.

type NoInfer<T> = T & {[K in keyof T]: T[K]};

Albeit it is less efficient in terms of performance compared to the built-in utility type we have today, mainly because of complex types that require deep exploration by TypeScript to find inference candidates. Here is a reference to the GitHub issue that prompted this change.

Wrap up

To conclude, TypeScript 5.4 Beta introduces substantial improvements, one of which I forgot to mention; preserved narrowing in closures. This allows for a more accurate narrowing of types within functions, addressing a common pain point in type-checking. This is just one among several noteworthy changes introduced. For a more comprehensive overview, refer to the official release notes.

I hope you found this post useful. If you did, please give it a like. 🙂

Setting up a Monorepo using PNPM workspaces with TypeScript and Tailwind

Emmanuel Isenah — Fri, 02 Feb 2024 08:57:56 +0000

In this article, We're going learn how to set up a monorepo and share multiple configs and dependencies between each package inside one repository. Before, we proceed, we have to understand what a monorepo is and what benefits it brings to the table.

What is a Monorepo?

A monorepo is a single repository containing multiple distinct projects, with well-defined relationships. It contains different applications or libraries which are somewhat dependent on each other but are logically independent

At this moment in time, the de facto way of developing applications is having a separate repo for each distinct project, library, or team. It is customary for each repository to have a single build artifact and its dedicated build pipeline. Nevertheless, the industry has gradually gravitated away from this practice, primarily for two significant reasons: ease of code reuse and desire for team autonomy.

Typically, the common process we reuse code is we publish it as a package to a remote registry like npm. Then, the app dependent on it installs it from the registry as an external dependency and uses the package as it sees fit. However, this approach poses multiple problems.

First, we have to set up package publishing and tooling with CI environment for the package being shared. But then, we introduce another problem: inconsistent tooling. The shared package will now require its own set of commands for running tests, building, serving, linting, deploying, and so forth. I could go on to provide numerous examples to illustrate how much maintenance overhead and work this will lead to in the long run.

But this is where monorepo's shine. They can drastically enhance this workflow by eliminating the overhead of publishing versioned packages just so it can be used by other internal projects and eliminating the concept of a breaking change when everything is fixed in the same commit. Let's take a quick dive into how to set one up using PNPM workspaces.

Setup Root Level Project

The first thing that we need to do is set up our root project which will encapsulate and manage all our applications. We can do so by initializing a pnpm project in our desired folder.

mkdir 'pnpm-monorepo' && cd pnpm-monorepo && pnpm init

Now our root project has been initialized, we should be able to add necessary root-level dependencies and dotfile configs that we’ll use across our projects.

TypeScript

pnpm add -D typescript

We'll start by setting up TypeScript as our initial root-level dependency. Installing it at this level ensures consistency in versioning across all projects. Let's populate our base configuration with the following code:

tsconfig.json

{
  "compilerOptions": {
    "target": "ESNext",
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "module": "ESNext",
    "skipLibCheck": true,
    "noImplicitAny": false,
    "allowJs": true,
    "noErrorTruncation": true,

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",

    /* Linting */
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true,

    "declaration": true,
    "composite": true,
    "sourceMap": true,
    "declarationMap": true
  },
}

This will serve as the default tsc compiler config shared throughout our project. While it might seem daunting due to the multitude of configurable options, Matt Pocock has written a comprehensive piece explaining the purpose of each property if you're interested.

Following that, we'll create our tsconfig.node.json file which will be extended by our base config. This file serves a unique purpose, acting as a workaround for Vite to omit bundling node types to the browser. If you're utilizing a different framework, you could skip creating this file.

{
  "compilerOptions": {
    "composite": true,
    "skipLibCheck": true,
    "module": "ESNext",
    "moduleResolution": "bundler",
    "allowSyntheticDefaultImports": true
  }
}

Now let's look to set up linting and formatting. For these, we'll be using ESLint and Prettier.

Prettier

pnpm add -D prettier prettier-plugin-tailwindcss
echo '{"printWidth": 80, "singleQuote": false}' > .prettierrc.json
echo 'dist
node_modules
*/*.yml' > .prettierignore

For quality-of-life purposes, let's add a package script to format every project in our codebase.

pnpm pkg set scripts.format="prettier --write \"./**/*.{js,jsx,ts,tsx,json}\""

ESLint

pnpm create @eslint/config

The ESLint wizard will ask you a set of questions to set up the linter as per your needs. This is the configuration I've chosen for this project.

.eslint.cjs

module.exports = {
  env: { browser: true, es2021: true, },
  extends: [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:react/recommended",
  ],
  overrides: [
    {
      env: { node: true, },
      files: [".eslintrc.{js,cjs}"],
      parserOptions: { sourceType: "script", },
    },
  ],
  parser: "@typescript-eslint/parser",
  parserOptions: { ecmaVersion: "latest", sourceType: "module", },
  plugins: ["@typescript-eslint", "react"],
  rules: {},
};

By default, ESLint will look for configuration files in all parent folders up to the root directory. We don't want such behavior so we'll set the root property to true.

module.exports = {
  root: true,
  ...
}

Now, let's configure PNPM to use workspaces by adding a pnpm-workspace.yaml file. It serves the purpose of including/excluding directories to be added to our workspace using glob patterns.

pnpm-workspace.yaml

packages:
  - "apps/*"
  - "packages/*"

The glob pattern here adds all direct subdirs of our specified folders. To add extra projects, we can do so by simply adding the absolute path of the project to our workspace file.

At this point, our repository has been set up to use workspaces. Now, let's proceed to create our individual projects.. Our applications will be housed under the apps/ folder and the shared projects will created under packages/.

Create a Project

For our applications, I'll be using Vite to initialize the projects. Now this can be done using any other JS framework like Next.js, Vue.js, Svelte, etc., and will remain still applicable.

First, let's create our apps and packages directory at the root.

mkdir apps packages

Now, let's init (for this article) our main application by changing our current directory and calling the bash script:

cd apps
pnpm create vite frontend --template react-ts
cd ../
pnpm install

PNPM has a filtering feature that allows you to restrict commands to specific subsets of packages using a filter tag (--filter). This will come in handy later on, so let's create one now.

pnpm -w exec -- pnpm pkg set scripts.frontend="pnpm --filter @monorepo/frontend"

PNPM follows a workspace naming convention, assigning child projects the format "@root-project-name/project-name". In our case, our root project name is "monorepo" so our child project package.json name would be "@monorepo/frontend". Let's proceed to make this adjustment in our package.json.

/packages/apps/frontend/package.json

{
"name": "@monorepo/frontend"
...
}

Let's extend our base tsconfig.json and tsconfig.node.json from our root folder.

/apps/frontend/tsconfig.json

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    // "noEmit": true,
    "baseUrl": ".",
  },
  "include": ["src"],
  "references": [{ "path": "./tsconfig.node.json" }]
}

Typically, we would enable "noEmit" in our config to prevent TypeScript compiler from generating transpiled code, as this task is managed by our bundler, Vite. However, this is not a concern thanks to our base config.

/apps/frontend/tsconfig.node.json

{
  "extends": "../../tsconfig.node.json",
  "include": ["vite.config.ts"]
}

We're done setting up our main application at this point. If you have any extra dotfile configurations, feel free to extend them too.

Create Shared Package

Let's create an extra project to share some code across our applications or even other shared packages. The project is going to be built as an external library with declaration files bundled together.

Let's create the project by running these commands from our root directory.

cd packages
pnpm create vite ui --template react-ts
cd ui/src
rm -rf assets App.tsx App.css ../.eslintrc.*
pnpm -w install
pnpm -w exec -- pnpm pkg set scripts.ui="pnpm --filter @monorepo/ui"

TIP: When executing commands for the root project while working within a child project, you can use the '--workspace-root' flag or its shorthand '-w' to prevent changing directories. For example, 'pnpm -w run frontend dev' will spin up the dev server for our frontend app while within the 'ui' working directory.

Let's change the name of our project to match naming previous naming convention and also extend our tsconfig.json and tsconfig.node.json.

/packages/apps/ui/package.json

{
"name": "@monorepo/ui"
...
}

/packages/apps/ui/tsconfig.json

{
  "extends": "../../tsconfig.json",
  "include": ["src"],
  "references": [{ "path": "./tsconfig.node.json" }]
}

/packages/apps/ui/tsconfig.node.json

{
  "extends": "../../tsconfig.node.json",
  "include": ["vite.config.ts"]
}

By default, Vite builds our assets in app mode using index.html as the entry file. However, we intend to build our app in library mode and expose the main.ts file as the entry point for our package. Let's proceed to modify the Vite configuration to accommodate this. Also while we're at it, we'll install a Vite plugin to auto-generate declaration files for our library.

pnpm ui add -D vite-plugin-dts @types/node

/packages/ui/vite.config.ts

import { defineConfig } from "vite";
import { resolve } from "path";
import dts from "vite-plugin-dts";

// https://vitejs.dev/config/
export default defineConfig({
  build: {
    lib: { entry: resolve(__dirname, "src/main.ts"), formats: ["es"] },
  },
  plugins: [dts()],
});

With all this finally out of the way, let's create an example component.

/packages/ui/src/components/Button.tsx

import * as React from "react";

type ButtonProps = React.ComponentProps<"button"> & {
  children: React.ReactNode;
};

export const Button = ({ children, ...props }: ButtonProps) => {
  return <button {...props}>{children}</button>;
};

Let's now export it out of our main entry file.

/packages/ui/main.ts

export { Button } from "./components/Button";

We'll be finished creating our library once we update the package.json file with the entry file and type declarations.

{
 ...,
 "main": "dist/ui.js",
 "types": "dist/src/main.d.ts",
}

NOTE: The output name for 'main' property is based on your application, whereas the type declaration output name is derived from your entry filename.

We now have a basic functional component named Button that accepts all possible props a button could have, in addition to a children prop for displaying content.

Let's head back to our main application and import our ui package. First, we have to install the library under monorepo/@frontend using the workspace filter command:

pnpm frontend add @monorepo/ui

NOTE: By default, when we try to install a package, pnpm will always try to link the package from our workspace based on the declared range. This wasn't always the case before; if the range wasn't matched, it would install the package from the npm registry. With the "workspace:" protocol, pnpm will refuse to resolve to anything other than a local workspace package.

Inside the @frontend application, our package.json should look similar to this:

{
...
"dependencies": {
    "@monorepo/ui": "workspace:^",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
...
}

Lastly, let's build our @ui library. We can't import anything if there's no output artifact to begin with.

pnpm ui build

That's it, now we should be able to import our components or whatever is exported from the ui package.

If you remember, we created a button component in the ui package. Let's render that button inside our frontend application:

/apps/frontend/src/App.tsx

import { Button } from "@monorepo/ui";

const App = () => {
  return (
    <Button
      style={{
        backgroundColor: "blue",
        padding: "10px",
      }}
    >
      Hello World
    </Button>
  );
};
export default App;

If we spin up our dev server and visit our localhost in our browser, we'll see a blue button rendered, saying 'Hello World'."

Dev Mode

Everything works with the current setup but it's highly inefficient. There are currently two problems:

We have to manually rebuild our dependency packages each time a change is made to them.
We have to restart our server each time when the former is performed.

To address the initial problem, we'll establish a development script to build our ui package in watch mode.

/packages/ui/package.json

  "scripts": {
    "dev": "vite build --watch",
    ...
  },

Additionally, we'll create a root-level script to execute the "dev" script across all packages in our workspace recursively, as specified in their package.json.

/package.json

  "scripts": {
    "dev": "pnpm --recursive --parallel --stream run dev",
    ...
  },

TIP: To selectively run a script for a package and its dependencies only, suffix an ellipsis to the package name (<package_name>...) with the --filter flag. For instance, if building for production, use: pnpm --filter @monorepo/frontend... build. This will build the specified package (@monorepo/frontend) and also its dependencies in the workspace.

To fix the second issue, we're going to have to configure an alias in the vite.config.ts of the @frontend app.

export default defineConfig({
  ...,
  resolve: {
    alias: {
      "@monorepo/ui": path.resolve(__dirname, "../../packages/ui/src/main.ts"),
    },
  },
});

By adding our ui package as an alias, it forces Vite to hot reload whenever the build artifact changes.

Bonus: Add Tailwind Support

To establish a single source of truth for all Tailwind configurations, we'll create an additional project for this purpose under the "/packages" directory.

cd packages
mkdir tailwind && cd tailwind && pnpm init
touch tailwind.config.js postcss.config.js
pnpm -D install tailwindcss postcss autoprefixer

Update the project name to match previously used naming convention.

/packages/tailwind/package.json

{
"name": "@monorepo/tailwind"
...
}

Add the paths to all of our HTML templates, JS components, and any other files that contains Tailwind class names in the tailwind.config.js file. In order for Tailwind to generate all of the CSS we need, it needs to know about every single file in our project that contains any Tailwind class names.

/packages/tailwind/tailwind.config.js

/** @type {import('tailwindcss').Config} */
export default = {
   content: [
    "./index.html",
    "../../packages/**/src/**/*.{html,js,ts,jsx,tsx}",
    "./src/**/*.{html,js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Add tailwindcss and autoprefixer property to our postcss.config.js file.

/packages/tailwind/postcss.config.js

export default {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

Add @monorepo/tailwind package to the frontend application

pnpm -w frontend add -D @monorepo/tailwind

Re-export default Tailwind config from tailwind package

/apps/frontend/tailwind.config.js

export * from "@monorepo/tailwind/tailwind.config.js";

Re-export default PostCSS config from tailwind package

/apps/frontend/postcss.config.js

export * from "@monorepo/tailwind/postcss.config.js";

Add the Tailwind directives to our CSS

/apps/frontend/src/index.css

@tailwind base;
@tailwind components;
@tailwind utilities;

Let's update our button component to use Tailwind class

/apps/frontend/src/App.tsx

const App = () => {
  return <Button className="bg-yellow-500">Hello World</Button>;
};

Without restarting our server, we should see our button background should now be yellow.

Conclusion

And there you have it! We've covered the basics of setting up a monorepo using PNPM workspaces. Additionally, we've explored configuring a project in library mode using Vite and adding Tailwind support. Embracing a monorepo approach changes our perspective on how we organize code, reducing barriers to creating new projects and promoting efficient code sharing.

If you're interested in exploring the finalized code from the blog, here is the GitHub repo.

Thank you for reading! If you got up to this point, please consider following for more upcoming blogs.

DEV Community: Emmanuel Isenah

Password Composition Policies Are Bad and Here's Why

Composition Policies and Entropy

A Better Approach

Check Passwords Against a Blacklist

Evaluate Password Strength, not Complexity

Live Demo 🔴

Conclusion

Unveiling React Server Components

What is Server Side Rendering?

Flaws of Legacy SSR

Streaming with React Suspense

Quick Memo on Selective Hydration

New Paradigm: React Server Components

Component Boundaries and Directive

When Components Should be Rendered as Client Components?

RSC Under the Hood

Conclusion

What's New in TypeScript 5.4 Beta

Object.groupBy and Map.groupBy

NoInfer Utility Type

Wrap up

Setting up a Monorepo using PNPM workspaces with TypeScript and Tailwind

What is a Monorepo?

Setup Root Level Project

TypeScript

Prettier

ESLint

Create a Project

Create Shared Package

Dev Mode

Bonus: Add Tailwind Support

Conclusion

`Object.groupBy` and `Map.groupBy`

`NoInfer` Utility Type