Forem: Rense Bakker

App translation with React-i18next

Rense Bakker — Thu, 08 Jun 2023 13:10:32 +0000

In this article I will show you how to translate your React app with React-i18next and give a few examples that you may find useful!

I am using joy ui in this example, but I won't show any configuration for it because it is out of scope. You can see the full code in this code sandbox.

I am also assuming that you already have a react project up and running.

Setup

First of we need to add the react-i18next package and its dependencies:

npm  install react-i18next i18next i18next-http-backend i18next-browser-languagedetector

You do not strictly need i18next-http-backend and i18next-browser-languagedetector, however in my experience, almost every React app with translations will want to use these tools sooner or later.

Create config and add i18next provider

Now we need to create a i18n.ts file where we will configure the i18n instance:

// /src/i18n.ts
import i18n from 'i18next'
import { initReactI18next } from 'react-i18next'
import Backend from 'i18next-http-backend'
import LanguageDetector from 'i18next-browser-languagedetector'

i18n
  .use(Backend) // default import from /public/locales/[lang]/[namespace].json
  .use(LanguageDetector) // Detect browser language
  .use(initReactI18next)
  .init({
    fallbackLng: 'en', // Our default language
    debug: true, // Only use this in dev mode
    interpolation: {
      escapeValue: false // We don't need this for React
    }
  })

export  default i18n

Next we need to provide this config to our entire React app using the I18nextProvider:

// /src/main.tsx
import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App'
import { I18nextProvider } from 'react-i18next'
import i18n from './i18n' // import i18n config

ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render(
  <React.StrictMode>
    <I18nextProvider i18n={i18n} defaultNS={'translation'}>
      <App />
    </I18nextProvider>
  </React.StrictMode>
)

Add the translations files

English translation:

// /public/locales/en/translation.json
{
  "hello": "Hello World!"
}

Dutch translation:

// /public/locales/nl/translation.json
{
  "hello": "Hallo wereld!"
}

Typescript

For extra convenience, we can add a react-i18next.d.ts file so the compiler will know which translation keys are available in our app. This way we get autocomplete for translation keys and it will let us know when we are using a translation key that doesn't exist:

// /src/react-i18next.d.ts
import  'react-i18next'
import translation from  'locales/en/translation.json'

declare module 'react-i18next' {
  interface Resources {
    translation: typeof translation
  }
}

declare module 'react-i18next' {
  interface CustomTypeOptions {
    defaultNS: 'translation'
    resources: {
      translation: typeof translation
    }
  }
}

Using translations

To translate a part of our app, we just import that useTranslation hook and let it know which translation key to use:

// /src/App.tsx
import { useTranslation } from 'react-i18next'
import { Typography } from '@mui/joy'

function App(){
  const { t } =  useTranslation()

  return <Typography>{t('hello')}</Typography>
}

More complex scenario's

Variables and pluralization

You might be thinking, what if some part of my text is a variable? Do I have to split the text out into chunks before and after the variable and translate them seperately? The answer is: nope, I18next has you covered!

// translation.json
{
  "welcome_one":  "Welcome {{name}}, you have {{count}} message.",
  "welcome_other":  "Welcome {{name}}, you have {{count}} messages.",
}

// /src/App.tsx
import { useTranslation } from 'react-i18next'
import { Typography } from '@mui/joy'

function App(){
  const { t } =  useTranslation()
  const [name, setName] =  useState('')
  const [count, setCount] =  useState(1)

  // ...

  return <Typography>{t('welcome',  { count, name })}</Typography>
}

You can do a lot of other fancy stuff with i18next as well like context aware translations.

Custom React components

Sometimes you have some text with a link for example, or you may even want to use a custom React component inside a piece of translated text. For this you have to use the Trans component.

// translations.json
{
  "custom_link": "Translate some text with a custom <1>link</1>."
}

Note the <1> placeholder that tells i18next where to expect a custom element.

// /src/App.tsx
import { Link } from '@mui/joy'
import { Trans } from 'react-i18next'

function App(){
  return <Trans  i18nKey="custom_link">
    Translate some text with a custom <Link  href="#link">link</Link>.
  </Trans>
}

Adding a language switcher

Building a language switcher with i18next is very simple, all we have to do is make some buttons and call the i18n.changeLanguage method with the language that we want to switch to:

// /src/App.tsx
import { Typography, IconButton } from '@mui/joy'
import { useTranslation, Trans } from 'react-i18next'

function App(){
  const { t, i18n } = useTranslation()

  return <>
    <Typography>{t('hello')}</Typography>
    <IconButton onClick={() => i18n.changeLanguage('en')} size="sm" variant={i18n.language ==='en' ? 'solid' : 'soft'}>EN</IconButton>
    <IconButton onClick={() => i18n.changeLanguage('nl')} size="sm" variant={i18n.language ==='nl' ? 'solid' : 'soft'}>NL</IconButton>
  </>
}

Why it is bad to be opinionated

Rense Bakker — Fri, 02 Jun 2023 07:28:27 +0000

As we all know, everybody always has an opinion, but that is not what this article is about. I want to talk about opinionatedness in relation to software engineering!

If you're a developer for a while, I'm sure you've heard someone (or yourself) dismiss an external library or framework, because it is "too opinionated", but what does it actually mean? And why is it so important for an external library to not be opinionated?

Defining Opinionatedness

Opinionatedness is when something makes a choice for you, outside of the scope of that thing. Internet Explorer is a good example here. If you are a Windows user, up till a few years ago, you were forced to have Internet Explorer installed. I hope we can all agree at this point, that the choice for a web browser should by outside of the scope of an operating system (I'm looking at you MacOS/Safari).

The Downsides of Opinionatedness

Let's look at a simple example:

function processResponse(res: { body: Record<string, unknown> }){
  return JSON.stringify(res.body)
}

At first glance there's nothing wrong with this function, but suppose that in the future, JSON.stringify turns out to be a very slow way to serialize your object? Or other serializers offer additional features that you want? You now have to change the JSON.stringify call inside the function. In this example that is not a big problem, but you can imagine in bigger applications, where the usage of a particular solution may be spread across several different files and functions, it can become quite problematic to make such changes.

Preventing Opinionatedness

Looking back at the previous example of the processResponse function, we can make it unopinionated and future proof by making a few simple changes:

// Allow for passing in a custom serializer
function processResponse(res: { body: Record<string, unknown> }, options?: { serializer?: (Record<string, unknown>) => string }){
  const { serializer = JSON.stringify } = options || {}
  return serializer(res.body)
}

Now, I'm not suggesting that every function you write, should include an options object to customize every aspect (dependency injection). This is merely one example of how you can make your code less opinionated and more future proof, by making it open for extension (remember the open/closed principle?).

Another good way to make your code less opinionated and more future proof, is by using the middleware pattern, like ExpressJS does for example:

const app = express()
app.use((req, res, next) => {
  // Any request/response handling middleware goes here
  // Even ones that havent been invented yet
  console.log('Time:', Date.now())
  next()
})

Possible Advantages of Opinionatedness

Sometimes the choice for an opinionated technology may have actual benefits, aslong as you are aware of the risks. A good example at the moment is NextJS. This is a React framework, with batteries included. It makes some choices for you, that may or may not be out of scope. For example, it has a very particular way of doing routing. However, because of the way they do routing, it is very easy to implement things that are generally very hard, like Server Side Rendering (SSR), Static Site Generation (SSG) and Incremental Static Regeneration (ISR). So, When something has very clear benefits, it may be worth it, even though it might limit you in the future.

So, I hope the next time you have an opinion, you will remember this article and take some time to think about the long term implications of your choices! The developers who come after you, will appreciate the effort. 😉

Some additional tips:

Allow configuration and customization
Use dependency injection
Document limitations and trade-offs of solutions
Prioritize simplicity and modularity
Support extensions and plugins

Publishing a NodeJS CLI tool to NPM

Rense Bakker — Mon, 15 May 2023 13:31:00 +0000

Project setup

Create a new folder (my-cli-demo for example) and use npm init command. Answer the questions with default options, except the entry point, which should be changed to bin/index.js

package name: (cli-demo)
version: (1.0.0)
description:
entry point: (index.js) bin/index.js
test command:
keywords:
author: 
license: (ISC)

After that, we can use npm to install the project dependencies for our CLI tool:

npm i yargs chalk@~4 && npm i typescript @types/yargs @types/node --save-dev

Lastly we need to tell npm that our package has an executable file and since we are using typescript, we should also add a watch script, to recompile our code when we make changes. This will allow us to test our CLI tool locally, without having to run a compile command manually every time:

{
  "name": "my-cli-demo",
  "version": "1.0.0",
  "bin": {
    "my-cli-demo": "bin/index.js" // <- command name of our cli script and the executable file it points to
  },
  "main": "bin/index.js",
  "scripts": {
    "watch": "tsc -w" // <- watch script
  },
  "license": "ISC",
  "dependencies": {
    "chalk": "^4.1.2",
    "yargs": "^17.7.2"
  },
  "devDependencies": {
    "@types/node": "^20.1.0",
    "@types/yargs": "^17.0.24",
    "typescript": "^5.0.4"
  }
}

Typescript configuration

We should also add a minimal tsconfig.json:

{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "moduleResolution": "node",
    "declaration": true, // creates d.ts type declarations
    "declarationMap": true, // creates map files for our d.ts files
    "sourceMap": true, // creates map files for our source code
    "outDir": "bin", // compile source code into "bin" folder
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noImplicitAny": true,
    "esModuleInterop": true
  },
  "include": [
    "src/index.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}

Parsing command line arguments

It’s time to start writing our CLI script! We’re going to use yargs to parse the command line arguments, that can be passed to our CLI tool. Yargs makes it easier to define which command line arguments can be used and it can automatically add documentation for our CLI tool that can be show with the --help flag.

Start by creating src/index.ts and adding the following contents:

#! /usr/bin/env node
import yargs from 'yargs'
import { hideBin } from 'yargs/helpers'

yargs(hideBin(process.argv))
  .help()
  .argv

Let’s start by getting our watch script up and running by typing npm run watch in a terminal. Now everytime we make a change, our code will be recompiled into the bin folder, which is configured as our main entry point. If we open another terminal and run node . --help, we should see the following output from our CLI script:

Options:
  --version  Show version number                                       [boolean]
  --help     Show help                                                 [boolean]

Adding a command module

Yargs allows us to define commands for our CLI tool, for example, we could define an init command that gets executed like this:

node . init

To add a command module, let’s start by creating src/commands/init.ts and adding the following content:

import { CommandModule, Argv, ArgumentsCamelCase } from 'yargs'
import chalk from 'chalk'

// the builder function can be used to define additional
// command line arguments for our command
function builder(yargs: Argv) {
  return yargs.option('name', {
    alias: 'n',
    string: true
  })
}

// the handler function will be called when our command is executed
// it will receive the command line arguments parsed by yargs
function handler(args: ArgumentsCamelCase) {
  console.log(chalk.green('Hello world!'), args)
}

// name and description for our command module
const init: CommandModule = {
  command: 'init',
  describe: 'Init command',
  builder,
  handler
}

export default init

We should also change our src/index.ts to let yargs know about our new command module:

#! /usr/bin/env node
import yargs from 'yargs'
import { hideBin } from 'yargs/helpers'
import init from './commands/init'

yargs(hideBin(process.argv))
  .command(init) // registers the init command module
  // or to register everything in the commands dir: .commandDir('./commands')
  .demandCommand()
  .help()
  .argv

Now if we run node . init --name Rense in our terminal, we will see the following output:

Hello world! Rense

Publishing to NPM

To publish our new CLI tool to NPM, we first need to add a git repository. Run the git init command in our project root directory and then create a repository on github or any other git host and add the remote url to our project with: git remote add origin git@github.com:[username]/[repository_name].git now add our files to the registry with git add . and push our initial commit: git commit -m "init" && git push.

We will use np for publishing, let’s install some additional dependencies to make this happen:

npm i np cross-env --save-dev

We’re going to add a release script to our package.json, but we need a way to prevent someone from accidentally running npm publish in the root of our project. To achieve this we can create this prepublish.js file with the following content:

const RELEASE_MODE = !!(process.env.RELEASE_MODE)

if (!RELEASE_MODE) {
  console.log('Run `npm run release` to publish the package')
  process.exit(1)
}

Now we can add the following scripts to our package.json:

[
  "prepublishOnly": "node prepublish.js && tsc",
  "release": "cross-env RELEASE_MODE=true np --no-tests"
]

And then run npm run release and answer the questions that np asks us. The prePublishOnly script will prevent anyone from manually running npm publish.

Using our CLI tool

After the CLI tool is published to NPM, we can install it anywhere we want to use it:

npm i my-cli-demo
my-cli-demo init --name Rense

I tried to fish for compliments from Code GPT

Rense Bakker — Sat, 25 Mar 2023 15:58:59 +0000

Here's what Code GPT thinks about the quality of my React code:

Your code is quite well written and structured. However, there are a couple of things that you could consider to improve it:

1. Use meaningful variable names: Try to use descriptive variable names that reflect the purpose of the data that they hold. For example, instead of `exp`, you could name it `workExp` and instead of `k` and `n`, you could name it `index` or `keyIndex`.
2. Use arrow functions in JSX: You can use arrow functions to make the code more readable and easier to understand. For example, instead of using a regular function like `(exp, k) => {...}`, you can use an arrow function (`(workExp, index) => {...}`).
3. Apply consistent whitespace and formatting: Some parts of your code have inconsistent whitespace and formatting. For example, some tags have spaces between the tag name and the attributes, while others don't. To make your code more consistent and easier to read, apply the same formatting rules throughout the file.

Ruthlessly punishing me for my lazyness with meaningful variable names inside array methods! 😅

PS. It got a little confused by my arrow functions for some reason? Not sure what is going on there. The whitespace and formatting comment is also strange, since I use a default formatter for react/tsx...

React: bad habits

Rense Bakker — Tue, 21 Mar 2023 08:15:31 +0000

Bad habits, we all have them! In this article, I will confess some of my own coding bad habits and bad habits I have encountered in React code over the past years, working as a React dev.

1. Create derived state using a side effect

This is something that happens a lot. Usually because initially some values were fetched from an api and it seemed logical to add up the values from the api call in the same useEffect:

function ShoppingCart({ items }: { items: Array<{ name:string, price: number }> }){
  const [totalPrice, setTotalPrice] = useState(0)

  useEffect(() => {
    // suppose there was initially an API call here, which fetched the items
    const sum = items.reduce((current, item) => current += item.price, 0)
    setTotalPrice(sum)
  }, [items])

  return <ul>
    {items.map((item, index) => <li key={index}>{name} - {price}</li>
    <li>Total: {totalPrice}</li>
  </ul>
}

However, setting derived state inside a useEffect hook should be avoided at all times! Instead, what we want is the useMemo hook:

function ShoppingCart({ items }: { items: Array<{ name:string, price: number }> }){
  const totalPrice = useMemo(() => items.reduce((current, item) => current += item.price, 0), [items])

  return <ul>
    {items.map((item, index) => <li key={index}>{name} - {price}</li>
    <li>Total: {totalPrice}</li>
  </ul>
}

This saves us an extra rerender that would be triggered if we change the state inside a side-effect that is based on some other state. Saving one rerender does not seem like a big deal, but it adds up quickly if the component gets nested inside another component that also sets derived state in a useEffect etc...

2. Managing multiple state properties

Creating forms is something we do a lot and it usually looks something like this:

function ContactForm(){
  const [email, setEmail] = useState('')
  const [name, setName] = useState('')

  const handleSubmit = useCallback(() => {
    // submit data...
  }, [])

  return <form onSubmit={handleSubmit}>
    <input value={email} onChange={e => setEmail(e.target.value)} />
    <input value={name} onChange={e => setName(e.target.value)} />
    <button type="submit">submit</button>
  </form>
}

And we all know what happens when someone asks us if we can add another field to the form... we add another useState and another input and call it a day. I've done this myself, but the question becomes, when do we stop? Because obviously, it is really dirty to have 20 lines of useState hooks in one component. If a component has more than one state property, use a reducer instead! I know reducers have this bad reputation of being complicated and redux-y, but it is actually one of the simplest ways to manage several state properties in a single component:

const initialState = {
  email: '',
  name: ''
}

function formReducer(prevState: typeof initialState, nextState: Partial<typeof initialState>){
  // no need for redux-like switch statements here!
  // just spread the next state onto the previous one, and we're done.
  return { ...prevState, ...nextState }
}

function ContactForm(){
  const [{ email, name }, setValue] = useReducer(formReducer, initialState)

  const handleSubmit = useCallback(() => {
    // submit data...
  }, [])

  return <form onSubmit={handleSubmit}>
    <input value={email} onChange={e => setValue({ email: e.target.value })} />
    <input value={name} onChange={e => setValue({ name: e.target.value })} />
    <button type="submit">submit</button>
  </form>
}

3. Creating black box context providers

Suppose we have some app context that we use to share some settings with the components in our app. This is a pretty common pattern and normally there's nothing wrong with it. However, there are some dangerous pitfalls here! Take this provider for example:

const initialState = {
  darkMode: true
}

function settingsReducer(prevState: typeof initialState, nextState: Partial<typeof initialState>){
  return { ...prevState, ...nextState }
}

const AppSettings = React.createContext({
  settings: initialState,
  changeSettings: (() => {}) as (settings: Partial<typeof initialState>) => void
})

function useAppSettings(){
  return useContext(AppSettings)
}

function AppSettingsProvider({ children }: React.PropsWithChildren<unknown>) {
  const [settings, changeSettings] = useReducer(settingsReducer, initialState)

  useEffect(() => {
    // some side effect, for example:
    settings.darkMode && import ('../styles/darkMode.css')
  }, [settings.darkMode])

  return <AppSettings.Provider value={{ settings, changeSettings }}>
    {children}
  </AppSettings.Provider>
}

It might seem logical, but when we do this, we need to realize that other developers working on our application are not going to realize this side effect exists there. In general, side effects in providers should be avoided. A provider is a blackbox except for the values that we expose from it (the context value). What we can do instead (in this case), is create a new component with an explicit name like DarkModeThemeLoader which only handles the loading of the darkMode styles, so other developers working on our app do not have to guess where this logic lives:

function DarkModeThemeLoader(){
  const { settings } = useAppSettings()

  useEffect(() => {
    settings.darkMode && import ('../styles/darkMode.css')
  }, [settings.darkMode])

  return null
}

// usage example:
function App(){
  return <AppSettingsProvider>
    <DarkModeThemeLoader />
    ... other content ...
  </AppSettingsProvider>
}

Vite dev server: adding middleware

Rense Bakker — Mon, 20 Mar 2023 06:24:14 +0000

While working on apps that will be deployed to Vercel, I have run into this situation several times, where I wanted to be able to start my api middleware together with the Vite dev server for local development. Normally you would run the api middleware separately using an express server for example and proxy requests from your Vite app to that server. However, since the Vite dev server can use express middleware, I wondered if it would be possible to eliminate the need to run a separate express server:

import express from 'express'
import { defineConfig, ViteDevServer } from 'vite'

const app = express()

app.get('/api', (req, res) => {
  res.send('Hello world!').end()
})

function expressPlugin() {
  return {
    name: 'express-plugin',
    configureServer(server: ViteDevServer) {
      server.middlewares.use(app)
    }
  }
}

export default defineConfig({
  plugins: [expressPlugin()]
})

By default, the Vite dev server won't pass on any requests to our middleware, so the code above will not work. However, with a little trick using the proxy config, we can tell the dev server to let a certain request be handled elsewhere, or in this case, by our middleware:

import { ProxyOptions, ViteDevServer } from 'vite'

const proxy: Record<string, string | ProxyOptions> = {
  '/api': {} // proxy our /api route to nowhere
}

function expressPlugin() {
  return {
    name: 'express-plugin',
    config() {
      return {
        server: { proxy },
        preview: { proxy }
      }
    },
    configureServer(server: ViteDevServer) {
      server.middlewares.use(app)
    }
  }
}

Now if we run our dev server and go to the /api route, it will display our Hello world! response.

10x developer myth in 2023

Rense Bakker — Mon, 02 Jan 2023 09:52:40 +0000

My hope for 2023 is that this 10x developer myth will change from how many commits are made, to how well-put-together our code is!

We are not bakers who are paid for the amount of loafs they can bake. We are engineers who get paid for how sturdy our constructions are.

ps.: nothing wrong with bakers. 🍞

pss.: if you want to bake code, ask ChatGPT 😝

Happy new year everyone!

Mapping Records to arrays

Rense Bakker — Thu, 06 Oct 2022 08:14:05 +0000

I needed this functionality to parse a configuration regardless of whether it was supplied as an array or a Record. This function converts the Record into an array of the same type:

function mapRecordToArray<T, R extends Omit<T, K>, K extends keyof T>(record: Record<string, R>, recordKeyName: K) {
  return Object.keys(record).map(key => ({ ...record[key as keyof typeof record], [recordKeyName]: key })) as T[]
}

It can be used like this:

type Field = {
  name: string,
  label: string,
}

type Collection = {
  name: string,
  label: string,
  fields: Record<string, Omit<Field, 'name'>> | Field[]
}

const collections:Collections[] = [] // ...

collections.forEach(collection => {
  const fields = Array.isArray(collection.fields)
    ? collection.fields
    : mapRecordToArray(collection.fields, 'name')
})
// Function typings will look like this:
// function mapRecordToArray<Field, Omit<Field, "name">, "name">(record: Record<string, Omit<Field, "name">>, recordKeyName: "name"): Field[]

// Notice the return type: Field[]

React: What is composition, and why is it important

Rense Bakker — Tue, 30 Aug 2022 06:03:06 +0000

What is composition

Let me demonstrate with a small example:

// no composition
<AlertDialog
  open={true}
  title="Don't use composition!"
/>

// with composition
<Dialog open={true}>
  <Title>Don't use composition!</Title>
  <Button>Close</Button>
</Dialog>

At first glance the first example seems like a good idea right? It's shorter and you've completely hidden that button component inside the AlertDialog, so you dont have to worry about it anymore!

But now, we need another special alert dialog that can have an svg icon in the title! This means we have to change the interface of AlertDialog so the title can take either a string or a ReactNode.

// no composition
<AlertDialog
  open={true}
  title={<><SvgAlertIcon /> Don't use composition!</>}
/>

// with composition
<Dialog open={true}>
  <Title><SvgAlertIcon /> Don't use composition!</Title>
  <Button>Close</Button>
</Dialog>

Or even worse, now the client also wants a special alert dialog (a confirmation dialog) that has a "cancel" and an "ok" button. This means we have to extensively modify the code inside AlertDialog and we need to put conditional logic there, so it can either render a "close" button or a "cancel" and "ok" button.

// no composition
<AlertDialog
  open={true}
  title="Are you sure you don't want to use composition?"
  asConfirmationDialog
/>

// with composition
<Dialog open={true}>
  <Title>Are you sure you don't want to use composition?</Title>
  <Button>Cancel</Button>
  <Button>Ok</Button>
</Dialog>

You can imagine, the code inside AlertDialog will get more complicated over time as requests for more features are made, meanwhile in the composition, NONE of the components have changed internally.

Why is composition important

From the above example, you can already see that composition is important because without it, the complexity of our components will grow exponentially over-time until they're no longer maintenable. But not using composition in React also violates some well known principles that you may remember from object oriented programming (the SOLID principles).

Single responsiblity

Sticking with the example of the alert dialog. We can see that the single responsibility principle is being violated. You expect the component to only be responsible for showing an alert dialog, but now it also contains logic to render a title and logic to show different buttons based on the asConfirmationDialog flag.

Open/closed principle

The violation of the open/closed principle can also be applied to React components. We need to make modifications to the internal logic of AlertDialog component if we want to extend it (it should be closed for modification and open for extension).

PS: When you are making a library of reusable components, not using composition means you just decided that developers using your library cannot (easily) make confirmation dialogs with your library. In practice that will mean you get a lot of feature requests or requests to change the interface of the components in your library. Or worse, developers will decide to use another library that uses composition.