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

```json
{
  "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`:

```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:

```tsx
#! /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:

```tsx
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:

```tsx
#! /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:

```jsx
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`:

```json
[
  "prepublishOnly": "node prepublish.js",
  "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:

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

## Links

- [Yargs documentation on command modules](https://github.com/yargs/yargs/blob/main/docs/advanced.md#providing-a-command-module)
- [np documentation](https://github.com/sindresorhus/np)
- [Documentation on NPM bin option](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#bin)

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

Publishing a NodeJS CLI tool to NPM

## The concept

Managing food orders and storage for animals at a petting zoo can be challenging. The existing paper lists used for ordering and tracking feed at a petting zoo were becoming hard to read and prone to errors. To address these issues, the goal was to create an app that could replace the paper lists, provide an easy-to-use interface, and prioritize user friendliness and accessibility.

## Choosing the Right Tools

To make the app user-friendly and accessible, QR codes and colors were chosen for easy identification of different storage containers. The IBM design system color palette was selected to ensure accessibility for users with colorblindness. For data storage, a serverless approach using [Firestore](/firestore) was chosen as it offered minimal storage needs. [React](/react) and [MUI](/mui) were chosen for the frontend to expedite development and create an accessible app without extensive custom component creation.

## Building the Prototype

The first prototype focused on displaying the list of storage containers and allowing users to view and modify the items in storage. Mutation logs were used to track changes, making it easier to generate future analytics. The prototype also included a QR code scanner for container identification. After one week, the first prototype was completed and deemed acceptable, but additional needs were identified. Users requested a list per feed item for the ordering process, the ability to add multiple feed items with one click, and an easy way to move items between storage containers.

![](/images/bonafarm.png)

## Securing the App

Before going live, ensuring app security was essential. Firebase Auth was implemented to offer a secure login option without requiring users to create another account elsewhere, while also allowing the app to remain serverless.

Overall, the app was designed to replace paper lists, provide an easy-to-use interface, prioritize user friendliness and accessibility, and ensure security. Through iterative development and addressing user needs, the app was tailored to meet the unique requirements of managing food orders and storage at the petting zoo.

Managing food orders and storage for animals at a petting zoo can be challenging. The existing paper lists used for ordering and tracking feed at a petting zoo were becoming hard to read and prone to ...

Bonafarm: stock management app

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`:

```tsx
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:

```tsx
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:

```tsx
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:

```tsx
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:

```tsx
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:

```tsx
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>
}
```

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

React: Bad Habits

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:

```tsx
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:

```tsx
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.

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

Vite dev server: adding middleware

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:

```tsx
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:

```tsx
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[]
```

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

Mapping records to arrays

Full-stack Developer @ Royal FloraHolland

## What is composition

Let me demonstrate with a small example:

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

// with composition
<Dialog open={true}>
  <Title>Do 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`.

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

// with composition
<Dialog open={true}>
  <Title><SvgAlertIcon /> Do 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.

```tsx
// 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 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).

Let me demonstrate with a small example:...

What is composition, and why is it important

## What is WebRTC

WebRTC is a web standard for real time communication between two peers (p2p). It allows for streaming data, video and audio using Javascript and the browser API ([`RTCPeerConnection`](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection) and [`MediaDevices`](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices)).

This is a video (in Dutch) that demonstrates the capabilities of WebRTC for audio broadcasting:

[![WebRTC audio broadcast](https://vumbnail.com/725396499_large.jpg)](https://vimeo.com/725396499 "WebRTC audio broadcast - Click to Watch!")

## Peer discovery
Although WebRTC allows for true peer-to-peer communication, to establish a connection between peers, the peers do need to find eachother and negotiate a peer connection. For this we have to create a "signalling server". For this demo we built a room-based signalling server with NodeJS and socket.io. Peers join a specific room and other peers in that room will be notified once the new peer has joined.
```ts
import { Server, Socket } from  'socket.io'
import { v4 as uuid } from  'uuid'
import express from  'express'
import http from  'http'

const app = express()
const httpServer = http.createServer(app)
const io = new Server(httpServer)

io.use((socket: Socket, next: (err?: any) => void) => {
socket.on('join', ({ roomId }: { roomId:string }, ack) => {
  socket.join(roomId)
  socket.to(roomId).emit('new peer', { remotePeerId: socket.id })
  ack && ack(roomId)
})
socket.on('leave', ({ roomId }: { roomId:string }) => {
  socket.leave(roomId)
  socket.to(roomId).emit('peer left', { remotePeerId: socket.id })
})

const { PORT = '3000' } = process.env
httpServer.listen(Number(PORT), '0.0.0.0', () => console.log(`Server ready at http://0.0.0.0:${PORT}`))
```
## Negotiation phase
Now that our peers can find eachother, they can initiate an `RTCPeerConnection` and negotiate through the signalling server. On the client, the initiation of the `RTCPeerConnection` looks something like this:
```ts
const connections: Record<string, RTCPeerConnection> = {}

socket.on('new peer', ({ remotePeerId }: { remotePeerId:string }) => {
  const connection = new RTCPeerConnection()

  // create an offer for the remote peer when the local peer adds data/audio/video
  connection.onnegotiationneeded = async () => {
    await connection.setLocalDescription(await connection.createOffer())
    socket.emit('description', { to: remotePeerId, ...connection.localDescription })
  }

  // send ice candidates to the remote peer
  connection.onicecandidate = ({ candidate }) => socket.emit('candidate', { to: remotePeerId, ...candidate })
  
  // respond to onDataChannel or onTrack
  // ...
  
  connections[remotePeerId] = connection
})

socket.on('peer left', ({ remotePeerId }: { remotePeerId:string }) => connections[remotePeerId].close())

socket.on('description', async ({ remotePeerId, ...remoteSessionDescription }: RTCSessionDescriptionInit & { remotePeerId: string }) => {
  await connections[remotePeerId].setRemoteDescription(remoteSessionDescription)
  if(remoteSessionDescription.type === 'offer'){
    const answer = connections[remotePeerId].createAnswer()
    socket.emit('description', { to: remotePeerId, ...answer })
  }
})

socket.on('candidate', ({ remotePeerId, ...candidate }: RTCIceCandidate & { remotePeerId: string }) => {
  connections[remotePeerId].addIceCandidate(candidate)
})
```
To forward the negotiation to the correct peer we just need to add the following event handlers in our signalling server:
```ts
socket.on('description', payload => forwardToPeer('description', payload))
socket.on('candidate', payload => forwardToPeer('candidate', payload))

function forwardToPeer(eventType: 'description' | 'candidate', { to, ...payload}: { to: string }) {
  io.to(to).emit(eventType, { remotePeerId: socket.id, ...payload })
}
```
Now if we add a data channel or audio/video track to the `RTCPeerConnection` with `addDataChannel` or `addTrack`. The peers in the room will negotiate peer-to-peer connections with eachother and start receiving data/audio/video from eachother.

Once the peers are connected, in theory we can turn off the signalling server, however, to find new peers that want to connect, we need to keep it running.

WebRTC is a web standard for real time communication between two peers (p2p). It allows for streaming data, video and audio using Javascript and the browser API ([`RTCPeerConnection`](https://develope...

WebRTC prototype

Full-stack Developer @ Bizcuit

Full-stack Developer @ BUX

In this article I will show you how to translate your React app with [React-i18next](https://react.i18next.com/) 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](https://codesandbox.io/p/sandbox/react-i18next-9gog87).

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:
```plain
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:
```ts
// /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`:
```tsx
// /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:
```json
// /public/locales/en/translation.json
{
  "hello": "Hello World!"
}
```
Dutch translation:
```json
// /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:
```ts
// /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:
```tsx
// /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!
```json
// translation.json
{
  "welcome_one":  "Welcome {{name}}, you have {{count}} message.",
  "welcome_other":  "Welcome {{name}}, you have {{count}} messages.",
}
```
```tsx
// /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](https://www.i18next.com/translation-function/context).

### 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.
```json
// 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.
```tsx
// /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:
```tsx
// /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>
  </>
}
```

## Links
- [Code Sandbox](https://codesandbox.io/p/sandbox/react-i18next-9gog87)
- [React-i18next Step-by-step guide](https://react.i18next.com/latest/using-with-hooks)

In this article I will show you how to translate your React app with [React-i18next](https://react.i18next.com/) and give a few examples that you may find useful!...

App translation with React-i18next

This project was a proof of concept written in Typescript, using the NS (dutch railroad company) API, to build a travel assistent app that would pro-actively help the user to find the next best connection if they miss their train, or if their selected train was cancelled or delayed.

The backend was built using [NodeJS](/nodejs)/Express and Apollo [GraphQL](/graphql) server and the frontend was made with [React](/react) and [MUI](/mui).

Some code samples and screenshots of the app are available through this gist: [https://gist.github.com/brense/bafdbcf0b656bb101be3ab5c31242ea9](https://gist.github.com/brense/bafdbcf0b656bb101be3ab5c31242ea9)

![](/images/travelassistant.png)

This project was a proof of concept written in Typescript, using the NS (dutch railroad company) API, to build a travel assistent app that would pro-actively help the user to find the next best connec...

Travel Assistant App

![Recipe details](https://media.graphassets.com/output=format:jpg/resize=height:800,fit:max/1pQ7k8wrQoyAhO0zOA5a)

![Overview recipes](https://media.graphassets.com/output=format:jpg/resize=height:800,fit:max/jS5hv2FRKGIk5KLOMmM1)

![Lab measurements report](https://media.graphassets.com/output=format:jpg/resize=height:800,fit:max/IysfE2dZSxuJgYbXGJn7)


Rense Bakker

Full-stack Developer @ Royal FloraHolland

Full-stack Developer @ Bizcuit

Full-stack Developer @ BUX

Full-stack Developer @ UMC Utrecht

Frontend Developer @ VOGSY

Backend Developer @ Part-Up

Full-stack Developer @ Twitcident