DEV Community: Hồng Phát

Redux developers, please stop doing this!

Hồng Phát — Sat, 17 Aug 2024 16:36:23 +0000

I worked on a React project in 2019, I believe it was built on top of the react-boilerplate template, and the developer experience with Redux was so bad that I became a Vue developer.

After a few years working with Vuex, Pinia, Recoil (yes, I came back), and recently Jotai (which is my go-to state management library at the moment), a friend randomly asked for my help in debugging the flow of his app, and it amazed me how Redux developers still write that boilerplate code:

const cartSlice = createSlice({
  name: "cart",
  initialState: {
    items: [],
    total: 0,
    // x, y, z,…
  },
  reducers: {
    setTotal(state, action) {
      const { total } = action.payload;
      state.total = total;
    },
    pushItem(state, action) {
      const { item } = action.payload;
      state.items.push(item);
    },
    clearItems(state) {
      state.items.length = 0;
    },
    // setX, setY, setZ…
  },
});

This was exactly the reason why I had such a bad time maintaining that Redux project. And it was even worse without Redux Toolkit (which they only introduced recently):

export const SET_TOTAL = "SET_TOTAL";

export const setTotal = (total) => ({
  type: SET_TOTAL,
  payload: total,
});

switch (action.type) {
  case SET_TOTAL: {
    return {
      ...state,
      total: action.payload,
    };
  }
  default:
    return state;
}

export const getTotal = createSelector(
  (state) => state.total,
  (total) => total
);

const mapStateToProps = (state) => ({
  total: getTotal(state),
});

const mapDispatchToProps = (dispatch) => ({
  setTotal: (total) => dispatch(setTotal(total)),
});

export default connect(mapStateToProps, mapDispatchToProps)(MyComponent);

class MyComponent extends Component {
  render() {
    const { total } = this.props;
    return <b>You must pay: {total}</b>;
  }
}

This was not a joke! In fact, cumbersome, excessive boilerplate code like the example above was often considered "best practices" and "industry standards" in my observation. It was almost as if we were writing code like this:

function isDifferent(x, y) {
  return x != y;
}

function isGreater(x, y) {
  return x > y;
}

function subtract(x, y) {
  return x - y;
}

function greatestCommonDivisor(x, y) {
  while (isDifferent(y, 0)) {
    if (isGreater(x, y)) {
      x = subtract(x, y);
    } else {
      y = subtract(y, x);
    }
  }
  return x;
}

The above code is far from being "highly scalable", providing "the best developer experience", or focusing on "performance and best practices".

Don’t get me wrong! Redux’s pattern itself is not bad; in fact, it’s so good that React introduced the useReducer hook to mimic it. The issue is that a marginal number of React developers are doing it wrong. Here’s how to do it right:

Batch relevant updates: Instead of creating data-oriented actions like PUSH_ITEM and SET_TOTAL, focus on behavior-oriented actions like ADD_TO_CART, which handle multiple updates (adding an item and updating the total) in one go.
Keep the state simple and move complex logic to selectors: For example, you can remove computable fields like total from your state entirely, then calculate them automatically from cart items using reselect. This approach not only ensures data integrity but also makes the code easier to maintain.

Please share this post with anyone you know who writes boilerplate-heavy Redux code, so we can all make state management in single-page applications less of a pain!

I used react-router but not for routing

Hồng Phát — Fri, 21 Jun 2024 16:31:57 +0000

I was working on my React project, fetching some data using fetch, and looking for a good way to do something like this Python code:

"{a} {b}!".format(a = "Hello", b = "World") # == "Hello World!"

💡 Why not use JavaScript string interpolation, you may ask? I want to put the params elsewhere, not within the string.

So I ~~spent hours doing Regex~~ went code scavenging on Stack Overflow, and I found this. It’s interesting that there is a function named formatUnicorn right on Stack Overflow’s website, which does exactly what I was looking for:

But I was hesitant to loot the code. I want to keep my code base as strongly typed as possible, and modifying the String prototype makes me feel insecure. What’s more, I would like to have at least some validation in case someone else forgot to pass in a and/or b. Implementing that seems beyond my scope of work, and installing another library is overkill. I was staring at the import section (just to make sure that I don’t import so much 3rd party stuff to keep our SPA app startup fast since FCP is crucial to our business), and that’s when I saw react-router import…

React Router lets you register routes with params like this:

path: "teams/:teamId",

So they must have implemented that “unicorn format” somewhere. I skimmed over their exports hoping that they would expose that unicorn function so I could use it, and thankfully they did:

And the function is unicornly strong typed:

💡 Did you expect that TypeScript can infer substrings as types like above? I didn’t!

The moral of the story

Sometimes, installing one more library may not be necessary because what you need is already (unexpectedly) available elsewhere within your project. Bundling too many libraries can greatly affect performance if it is crucial to your business.

I hope my story was inspiring!

Generate API Clients: A new way to consume REST APIs and GraphQL

Hồng Phát — Tue, 30 Apr 2024 15:21:01 +0000

Integrating HTTP APIs often involves tedious double-checking:

Was the endpoint GET /sheep or GET /sheeps?
Should the parameters be put in the URL query string, request body, or even headers?
Is the API server expecting to receive parameters in the Content-Type application/json or x-www-form-url-encoded?

By generating HTTP API clients from existing API endpoints using the approaches below, we can make the development more enjoyable while improving the UX by reducing bundle size and startup time.

Why generate API clients?

Absolute accuracy: Generated clients follow specifications such as GraphQL SDL or Swagger OpenAPI to ensure your server receives what it demands. Things can’t go wrong unless you choose to disregard TypeScript declarations by unleashing the power of the any keyword.
Long-term productivity: It takes only a few minutes to generate your API client, which then saves you hours and hours writing functions for each endpoint, manually defining their request params and response payloads. What's more, it saves you the effort of fixing any potential errors by doing so manually. I've been there!
Outstanding IDE support: Witness yourself in the GraphQL section below!

How to generate API Clients?

RESTful APIs via swagger-typescript-api

As the library name suggests, using this approach requires your RESTful APIs documented using the OpenAPI Specification (formerly Swagger). Server-side frameworks like Java Spring can often generate this documentation for you effortlessly.

If you use other specifications, there might be an equivalent library available.

Steps:

Install swagger-typescript-api:
```
npm install -D swagger-typescript-api
```
Generate your client:
You can either execute the command directly or add a script entry to your package.json file for easy regeneration when your backend APIs change:
```
"scripts": {
  "gen:rest": "swagger-typescript-api -p https://your-server.com/rest-api-endpoint/docs -o ./src/services -n rest.ts"
}
```
Make sure the -p parameter points to your Swagger schema, usually a JSON/YML endpoint (not the Web UI endpoint). Run npm run gen:rest to generate your client into src/services/rest.ts.

Use generated client in your code:

import { Api } from "services/rest";

const client = new Api({
  baseUrl,
  securityWorker, // Use this to set up Bearer tokens in request headers
});

const { data } = await client.api.getProducts({
  page: 1,
  limit: 10,
  ... // TypeScript will let you know which params can be passed in
});

The best part is that your response data is always strongly typed. This means that whenever you type data. and press Ctrl+Space or ⌥ + Esc, your IDE will let you know precisely what lives inside your data, fields that you didn't even know existed and fields that you think you could use but, in fact, could not. No verbose code is required!

GraphQL via genql

I actually discovered this mechanism and decided to write a blog about it while working with GraphQL. As someone who embraces the KISS principle, I found working with Apollo clients to be quite daunting: writing GraphQL queries within large JavaScript strings with limited extension support, intricate approach to customizing outgoing requests (such as placing tokens in headers and retrying after token refreshes), or caching behaviour that often differed from expectations.

On the other hand, generating clients for GraphQL is much simpler because all endpoints already adhere to a single specification. Honestly, I believe genql should be the official solution for web GraphQL clients.

Steps:

Install @genql/cli:
```
npm install -D @genql/cli
```

Generate your client:

"scripts": {
  "gen:gql": "genql --endpoint https://your-server.com/graphql/ --output ./src/services/graphql"
}

Then, you can simply run npm run gen:gql to generate your client.

Use generated client in your code:

import { createClient } from "services/graphql";

const client = createClient({
  fetch, // Customize the fetch function to add JWT tokens or implement retry logic
});

const data = await client.query({
  // IDEs with TypeScript support will assist you with typing all of the code below effortlessly
  products: {
    name: true, // Pick only the fields you want
    __scalar: true, // Or pick all the fields with primitive values
    reviews: {
      rating: true, // Nested picking allowed
    },
  },
});

What is truly impressive: you get a subtype with only the fields you requested. Your IDE will discourage you from typing .content after data.products[0].reviews[0] because it wasn't queried, even though it exists in the user schema. This would require much more verbose code in Apollo clients. Kudos to the genql and TypeScript developers!

Conclusion

Generated TypeScript API clients offer a powerful and efficient way to interact with HTTP APIs, whether you are working with GraphQL or REST. If you're looking to improve your API consumption workflow, I highly recommend giving them a try!

React State Management in 2024

Hồng Phát — Fri, 08 Dec 2023 06:34:06 +0000

In my POV, React state management libraries can be divided into three groups:

Reducer-based: requires dispatching actions to update a big centralised state, often called a “single source of truth”. In this group, we have Redux and Zustand.
Atom-based: splits states into tiny pieces of data called atoms, which can be written to and read from using React hooks. In this group, we have Recoil and Jotai.
Mutable-based: leverages proxy to create mutable data sources which can be directly written to or reactively read from. Candidates in this group are MobX and Valtio.

Now that we've covered the three main categories of React state management libraries. Let's delve deeper into each one and explore the strengths and weaknesses of each approach. This will help you understand which library best suits your project's needs:

1. Reducer-based Libraries:

Despite its common criticism about being (overly) complicated, Redux has been the most popular state management library since its creation.



+---------------------+
|        Actions      |
+----------|----------+
           |
           v
+---------------------+        +---------------------+
|        Reducers     |        |       Store         |
+----------|----------+        +----------|----------+
           |                              |
           v                              v
+---------------------+        +---------------------+
|        State        |        |     Subscriptions   |
+---------------------+        +---------------------+

Strengths:

A powerful state machine and time machine. Suppose all of your application states live inside the centralised state (which rarely happens because you might have local states in your components), this formula will exist: UI = React(state). This means a single state value will only result in one UI, so your application will look consistently the same with a specific state. If you backup the entire state somewhere, then dispatch a change like REVERT(pastState) { state = pastState }, your UI will be restored as if it was a captured screenshot.
The best DevTools support: By updating the state using explicit actions, DevTools can help you point out what, when and how the state changes. You can imagine it like having a Git commit history in your application state, how cool is it?

Weaknesses:

Boilerplate code: even a simple change to your state requires considerable changes in the code.
Steep learning curve: while it is simple at its core, it is never enough on its own. To truly master Redux, you should know how to use it with other libraries such as Saga, Thunk, Reselect, Immer, or Redux Toolkit. It feels overkill when most of the time, we use generators in Saga just to fetch some data over the network. Modern JS developers tend to use async/await on a day-by-day basis.
TypeScript: although fully support TypeScript, explicit typing is required most of the time to get typing done for actions, reducers, selectors, and state. Other approaches directly support automatic type inference.

2. Atom-based Libraries:

Instead of putting your whole application state inside a large centralised state, this approach splits it into multiple atoms, each atom preferably as tiny as primitive types or basic data structures like arrays and flat objects. Then, you can use the selector to group related states together later if you need to.



+---------------------+
|     Atoms (State)   |
+----------|----------+
           |
           v
+---------------------+        +---------------------+
|  Selectors (Derived |        |   RecoilRoot        |
|     State)          |        +----------|----------+
+----------|----------+                   |
           v                              v
+---------------------+        +---------------------+
|    State Snapshot   |        |   React Components  |
+---------------------+        +---------------------+

Strengths:

Leverage React features: this is expected since Recoil and React are both created by Facebook. Recoil works great with cutting-edge React features such as Suspense, Transition API and Hooks.
Simple and scalable: by using only atoms and selectors, you can still effectively build up a giant reactive application state while having fine-grained control over individual state changes. Lifting state up is now as simple as declaring an atom and changing your useState hook to useRecoilState.
TypeScript: as a developer who cares about DX as much as a user cares about UI and UX, I found React, Recoil, and TypeScript to be a wonderful combination. In my projects, types are automatically inferred most of the time.

Weaknesses:

DevTools: if you are looking for an equivalent of Redux DevTools, unfortunately, there isn’t.
Cannot use state outside of components: although Recoil Nexus is a workaround, this kind of state management library is designed with a (maybe true) assumption that all usage of state happens inside React components.
Not stable (yet): it has been 4 years, and the latest version of Recoil still has the leading 0 (v0.7.7). I would be glad if, by the time you read this, this information stays irrelevant.

3. Mutable-based Libraries:

Tips: "mutable" and "immutable" refer to how data can be changed after it is created:

person.age += 1 // mutable

person = { …person, age: person.age + 1 } // immutable



+---------------------+
|     Observables     |
+----------|----------+
           |
           v
+---------------------+        +---------------------+
|   Computed Values   |        |     Actions         |
+----------|----------+        +----------|----------+
           |                              |
           v                              v
+---------------------+        +---------------------+
|   Reaction (Derived |        |    MobX Store       |
|       Value)        |        +----------|----------+
+---------------------+                   |
                                          v
                               +---------------------+
                               |   React Components  |
                               +---------------------+

Strengths:

The simplest API: by allowing the state to be mutated directly, no boilerplate code is required to sit between your component and state, unless you want to do so.
Reactivity and flexibility: dependencies are updated automatically whenever the state changes. This simplifies your application logic and makes it easier to comprehend. Moreover, the proxy-based approach helps minimise unnecessary re-renders. This also translates to smooth performance and a more responsive user experience.

Weaknesses:

Too much magic: automatic reactivity is a double-edged sword. Race conditions in asynchronous updates can lead your application state to chaos, and debugging the flow of changes can be challenging in complex applications.
DevTools: again, it seems to me that no alternative has the best tooling support as the reducer-based approach.
Discrete DX: while React elaborates on the “immutable” approach, having “mutable” data mixed in my project sometimes makes me feel insecure about how I should make changes to my data.

The best choice

Again, the best React state management library for your project depends on your and your team’s specific needs and expertise. Please DON'T:

Pick a library based solely on project size and complexity. Because, you may have heard somewhere that X is more suitable for a large-scale project while Y is better for a smaller one. Library authors designed their libraries with scalability in mind, and your project’s scalability depends on how you write the code and use the library, not which libraries you choose to work with.
Apply best practices you learned from one library to another. Putting your whole application state inside a single Recoil atom to achieve a “single source of truth” will only lead to struggling with state updates and issues with performance. As well as defining actions in Redux as if they were setters and dispatching multiple of them instead of batching changes in one commit.

The author's choice

TL;DR: Jotai.

I personally prefer the atomic libraries because of the advantages listed above and my historical painless DX when dealing with asynchronous data fetching and batching loading UI with <Suspense>. What Jotai does better than Recoil is that:

No key is required. Naming things is tough, and most of the time, you won’t use Recoil’s keys. So why spend time declaring them at all when the libraries can automatically have the keys for you? Here is Recoil’s answer; however, as you can see, people are not quite convinced.
Performance. A picture is worth a thousand words, and I have 4 of them:

Library	Import cost	LCP
Recoil
Jotai

You might argue that a ~20Kb difference in size does not matter that much, but let’s take a look at a benchmark which was taken on a very old Android device, where sluggishness appears as obvious as bars filled in with a pattern of diagonal red stripes. As you can see, Jotai internal logic requires less overall calculation, which improved my application's LCP, an important Core Web Vitals metric, from ~2.6s to ~1.2s. Nonetheless, this comparison may not take into account other factors that Recoil do better than Jotai (in fact, my knowledge cutoff in this). I just want to say that the Jotai team did a wonderful job there.

I hope this helps!