DEV Community: Arnaud Ambroselli

Setup the easiest i18n system with NO KEYS

Arnaud Ambroselli — Sat, 17 May 2025 15:39:26 +0000

Alright, let's cut to the chase. You're building a React MVP. You need to be fast, lean, and focused on validating your core idea. So why, oh why, are you already thinking about t('user.welcome.message.short')?

Internationalization (i18n) is crucial for global reach, no doubt. But for an MVP, traditional i18n setup is often a premature optimisation, a time sink when you should be shipping and iterating. It means wrestling with JSON files, getting lost with keys everywhere in your app, and losing velocity at a time you shouldn't.

Embrace the "Keyless" Freedom with `i18n-keyless`

This is where the "keyless" philosophy, then first time embodied by i18n-keyless, becomes your MVP's best friend.

The concept is refreshingly simple: Just write your UI text directly in your components, in your main language. That's it.

import * as I18nKeyless from "i18n-keyless-react";

I18nKeyless.init({
  API_KEY: "YOUR_KEY",
  storage: window.localStorage,
  languages: {
    primary: "en",
    supported: ["en", "fr"], // any language supported
  },
});

export function HeroSection() {
  return (
    <section>
      <h1><I18nKeyless>The Next Big Thing is Here!</I18nKeyless></h1>
      <p><I18nKeyless>Seriously, it's awesome. Sign up now.</I18nKeyless></p>
      <button><I18nKeyless>Let's Go!</I18nKeyless></button>
    </section>
  );
}

You build, you write, you iterate.
No key invention, no initial translation file juggling.

Try it here below within Stackblitz

Why This is a Game-Changer for MVPs:

Blazing Speed: You're not bogged down by i18n ceremony. Code flows faster. No velocity loss.
Laser Focus: Concentrate 100% on core features and user experience.
Cleaner Code: Your JSX is just straightforward text. Much easier to read and modify during rapid prototyping.
Painless Text Changes: Need to tweak that heading? Just change it. No key lookups or file updates.

Using a tool like i18n-keyless is about getting i18n out of your mental load. For ever.

So, How Does This Sorcery Work?

No, it's not (just) magic. It's clever engineering backed by a service:

Text is the Key: When your component renders, the <I18nKeyless> component (or its equivalent hook/HOC) grabs the raw text you wrote (e.g., "The Next Big Thing is Here!").
Smart Backend: This text, along with your API key and target languages, is sent to the i18n-keyless service.
AI-Powered Translation: If this specific text hasn't been translated into your target languages before (for your API key), the service generate high-quality translations on the fly.
Caching & Delivery: These translations are then stored and served back to your app. Subsequent requests for the same text hit the cache for instant delivery.
Context Matters: You can even provide context to ensure the translations are spot on.

The beauty is, you, the developer, don't need to manage any of this complexity. You just write.

This Isn't a "Later" Problem, It's a "Solved" Problem

Forget the idea that you'll "add i18n later." With i18n-keyless, you add it now, without the traditional pain. It's not a placeholder; it's a robust, scalable solution from day one.

No "Translation Debt": You're not accumulating a mountain of untranslated strings.
Instant Multi-Language Capability: Want to support a new language? Add it to your supported array in the config. The service takes care of backfilling translations.
Developer Bliss: Your team focuses on building features in your primary language. The i18n just happens.

The Future is Keyless (and Less Painful)

For too long, i18n has been a necessary evil, a speed bump in the development process. Tools like i18n-keyless flip the script. By leveraging the text itself as the identifier and using AI for the heavy lifting, it removes the most tedious parts of internationalization.

While the client-side SDK is open source and you could build your own backend, the real power comes with the managed service at i18n-keyless.com. This gives you access to the AI translation engine, robust caching, and a handy dashboard to monitor your usage, manage languages, and even tweak translations if needed. It’s designed to be a set-it-and-forget-it solution that scales with you.

You save time, reduce cognitive load, and can genuinely build for a global audience from the get-go, even on a shoestring MVP budget.

Ready to stop worrying about translation keys and start shipping faster?

Give i18n-keyless a spin and check out the service at i18n-keyless.com. Your development workflow will thank you.

Mastering and Taking advantage of React `key` prop

Arnaud Ambroselli — Tue, 22 Mar 2022 11:40:54 +0000

You might know that key is a reserved prop in the React ecosystem.
I also guess you've get acquainted to key while learning how to render a list, that you have to give a unique key to a list of items - maybe you don't even know why, you just do it.

Well, by understanding how this rendering thing works and why a unique key is so important, you'll learn a new and very powerful way of using this key prop, not even while rendering a list !

Why the `key` prop must be unique in a list

React always try to optimise the rendering of components, by re-rendering only what changed between the previous state and the new. To do so, key is one of the thing that tells react to recreate the element if the key changed.

If you render a list and you don't setup the key prop yourself, React will automatically set the key to be the index of the item in the array. That's fine if this array is static and never changes, but if it does change, it's gonna be a problem : your item will never re-render, because its props didn't change, neither its state.

What you should remember:

When a component's state or props changes, React re-render it
When a component's key changes, React re-create, with initial state and props
When none of those change, React keep the component as is, no re-render is happening.

That's why if the items of your list change, you need to set each of them a unique key, so that when the key changes, the component recreates itself and your list updates

How to take advantage of the `key` prop outside a list

Sometimes, a component needs to get its state reset to initial values. How to ?

-> have a sort of reset function that reset all states: that can be tedious, and sometimes mistaking
-> change the key prop of this component

I'm a big fan of the second option that I use a lot around my project : it's only a few lines of code maximum, it's 100% efficient, no mistake possible.

One of my colleague told me a few days ago: "That little hack is nice, but is it a proper way to do ?"

Well, this hack is not my own creation, I've learned it from another dev, but I never checked if there were official guidelines for it, and guess what : now with the new React docs, it has !
https://beta.reactjs.org/apis/usestate#resetting-state-with-a-key, by Dan Abramov himself.

Have fun !

Deploy a Next.js static app in Clever Cloud

Arnaud Ambroselli — Sat, 04 Dec 2021 16:58:49 +0000

Note: This post is not sponsored by Clever Cloud by any mean, but it's a service I really like : great UX, great support, and made in Europe

Clever Cloud is great, nevertheless it took me a small hour to deploy a static NextJS app the first time. But their support was really efficient and we sorted it out really fast ! Just by setting up the correct environment variables.

Context: We're working on a monorepo, meaning that in a single github repository we have many folders such as api, app, admin, dashboard, etc. So the NextJS app is located in the app folder, that's all we need to know here.

Back in Clever Cloud Console:

Create a new application
Choose "Create from a Github Repository" and select your repo
Step "What kind of application is it ?", select "Static", with a feather 🪶 as an icon
Config your instances as you wish (Autoscalability, Horizontal scaling, Vertical scaling), name it as you wish, choose your region and create it
Then go to "Environment variables" and setup the variables this way:

APP_FOLDER="app"
CC_CACHE_DEPENDENCIES="true"
CC_CGI_IMPLEMENTATION="proxy_fcgi"
CC_NODE_DEV_DEPENDENCIES="install"
CC_PRE_BUILD_HOOK="cd app && npm install --also=dev && npm run build"
CC_WEBROOT="/out"
HOST="0.0.0.0"
NEXT_PUBLIC_ANY_VARIABLES="{variables you defined for your project}"
NODE_ENV="production"
PORT="8080"

And that's it !

Clever Cloud moto is

Vous développez, nous déployons
You code, we deploy

Cannot be more true ! 🥸

9 Things You Should Do or Know Before Building Native Apps

Arnaud Ambroselli — Sat, 04 Dec 2021 14:59:09 +0000

TDLR;

Header appversion for each request
Header appdevice
Header currentroute
Setup a pattern to display a message to your app on response to a backend request
Allow a user interaction/redirection from the backend
Send a request to your backend on each page change
Setup a Check Version and/or Force Update pattern
Keep things in the backend if you can
Beware of the version naming : a mistake is for life

Building a iOS/Android/macOS/whatever native app is not the same as building a web app.

With a web app running on browsers, if you want to deploy another version of the app, you just do it and instantly all users get the latest release.

But native app are packages installed on your device with a few consequences

Before a new version is available on the stores, it can take a few hours or even days because native apps are checked by the store maintainers.
It might even be rejected because of whatever check done by the store managers didn't pass.
You can't remove or cancel a release of your app. Once it's deployed on the stores, it's for ever.

That's why before sending the first release of your app, you should setup a few safety measures in case something goes wrong with one of the available apps on the store. And believe me, chances are big that someday something will go wrong. At least once.

Things you should setup or know before sending a native app

Let's consider you build an app with a backend and a database.

1. Header `appversion`

For each and every request to the backend, find a way for the backend to know the app version in case you need to hotfix for specific versions of your app. Usually, I set a appversion: {my-app-version} in the Headers.

2. Header `appdevice`

Find also a way for the backend to know the device and/or OS it's running on (android/ios), just in case.
That's where I setup appdevice: {my-app-device} in the Headers too.

3. Header `currentroute`

Less important, but still useful in some cases, send the current page / current route to your backend. You might not see how it could be useful now, but remember, once you find it useful and your app is already deployed in production, it's too late.
I like headers, so I add a currentroute: {the-current-route} in the headers too.

4. Setup a pattern to display a message to your app on response to a backend request

Setup a way to be able to communicate to your app from the backend. For instance, I'm a JavaScript guy working with ExpressJS and React Native, and what I do in the front-end is, while I'm reading the response from the backend:

if (response.showAlert) {
  Alert.alert(response.showAlert.title, subtitle)
}

showAlert being an object of an alert in react native.

5. Allow a user interaction/redirection from the backend

Even more, within the showAlert object, you can (and should) be able to redirect the user to anything you want if he presses OK or Cancel or whatever action you defined.
For instance, I use React Navigation for navigating through the screens, therefore I usually add a onOkRedirect field on the showAlert object so that if this field exists, pressing on OK will trigger navigation.navigate(... onOkRedirect). But you can add onOkRedirectToUrl or anything in your mind.

6. Send a request to your backend on each page change

I also like to send a request on each page change, so that if I have a bug in one of the page, or if I want to send specific in-app message for a particular screen, I can.
In React Native and React Navigation, I listen to state change and send a request to the backend on each of the route changes.

7. Setup a Check Version and/or Force Update pattern

Because you don't want the user to have to download a new version every other day - it would be a cruel user experience - you might have to handle backward compatibility of your app in your backend. That's why appversion is so useful. But sometimes, you want to get rid of technical debt linked to this extra code, or you also might have a breaking change, or whatever : you need to force the user to update to the last version.

If you didn't plan it, it won't happen ! I see two options there

either you have a middleware in your backend that check the version on each request and send back a showAlert to force the user to download the newest version of the app (and that's where the appdevice header is useful to redirect the user to the good store)
either you have a request with the path /check-version located properly in your app so that if the version is not good, you have a beautifully designed screen inviting your user to download the new version of the app
either both !

8. Keep things in the backend if you can

That's actually THE thing to remember while you're coding, together with the backward compatibility in mind.

You can't have the whole app in the backend, and have it downloaded at every app load : you definitely need a part of the code in the app, and another one in the backend.

But sometimes you hesitate : should I put this in the front or in the back ? When you do hesitate, opt in for the backend : you can change the backend any time, you can't change the front end anymore.

Think the native app as a displayer only, not a brain - live that part to the backend.

I also tend to put i18n in the backend too : it's too sad to have to redeploy a whole app because of a typo somewhere.

9. Beware of the version naming : a mistake is for life

Last but not least...

Android has a versionName and a versionCode, iOS has a CURRENT_PROJECT_VERSION and a MARKETING_VERSION, I don't know about the others : those need to be incremented when sending a new version to the stores.

Be careful : if you made a typo by writing 20.0.1 instead of 2.0.1, you won't be able to take it back, and from now on all the other version will have to be greater than 20.0.1.

Be also careful : one is to be only a number (CURRENT_PROJECT_VERSION and versionCode), the other one is {major}.{minor}.{patch}. If you make a mistake at the beginning, you also won't be able to take it back either. But don't worry too much about versioning here if you made a mistake : I think Facebook itself might have made a mistake as there are at version 345.0 on the store.

Conclusion

All of these tips are coming from mistakes I personally made. That's not small mistakes when you have a client to face with. Having an app in production is quite a journey : I hope I've helped you preparing it !

Simplest Drag and Drop setup in React, in 10 lines of code with SortableJS

Arnaud Ambroselli — Sat, 27 Nov 2021 14:36:37 +0000

TDLR

SortableJS make things really easy !
For those who just want the final result, here is the code and a demo just below

Code

import React, { useState, useEffect, useRef } from 'react';
import Sortable from 'sortablejs';
import './style.css';

const initData = Array.from({ length: 15 }, (_, i) => ({
  _id: (i + 1).toString(),
  content: (i + 1).toString(),
}));

const SortableGrid = () => {
  const gridRef = useRef(null);
  const sortableJsRef = useRef(null);

  const [data, setData] = useState(JSON.parse(sessionStorage.getItem('my-grid')) || initData);

  const onListChange = () => {
    const newData = [...gridRef.current.children]
      .map(i => i.dataset.id)
      .map(id => data.find(item => item._id === id));

    sessionStorage.setItem('my-grid', JSON.stringify(newData));
    setData(data);
  };

  useEffect(() => {
    sortableJsRef.current = new Sortable(gridRef.current, {
      animation: 150,
      onEnd: onListChange,
    });
  }, []);

  return (
    <div ref={gridRef} id="gridDemo">
      {data.map(({ _id, content }) => (
        <div key={_id} data-id={_id} className="grid-square">
          {content}
        </div>
      ))}
    </div>
  );
};

export default SortableGrid;

Demo

Demo available on my personal blog.

So many DragNDrop libs out int the react ecosystem...

...and yet no easy solution for any of them !

React Beautiful Dnd: build by Atlassian for Trello, it's reliable BUT

This library continues to be relied upon heavily by Atlassian products, but we are focused on other priorities right now and have no current plans for further feature development or improvements.

and also, not so easy to setup for someone who just want easy drag and drop

React Grid Layout: quite easy to setup, and quite powerful also. But I wanted to be able to move items in a grid so that it takes the position of another item in the grid and the grid keeps the same shape at the end of the drag/drop action - the defauilt behavior of this lib being to "make space" for the dragged item and break the grid layout. After spending one hour on it, I still couldn't find the way to achieve my goal, I quit.

-React DND: it seems also a powerful lib, but the API is sooooo ccomplicated ! And you have to read their tutorial to setup anything, which is also giving headaches... I tried to implement the API, but after 200 lines of coding and 1 hours spent, I was lost, I tried something else

-react-draggable: I must say I didn't see that one, and didn't try.

-react-grid-dnd: it looked like an easy setup and exactly want I was looking for, but... it's not maintained, and not working with npm7+ because it has react 16 as a dependency. So I had all the code setup before installing the lib, and I was quite fed up and tired when I discovered I would need to change my npm version to use it, or do some tricks here and there...

-react-sortablejs: I didn't try because it says as an introduction

Please note that this is not considered ready for production, as there are still a number of bugs being sent through.

Then I thought : damn, there should be out there a JavaScript library doing the simple thing I've asked for ! And I saw in this last react-sortablejs that it was a "React bindings to SortableJS".

I went to look for SortableJS, clicked on the demo, scrolled to the grid example which was doing exactly the simple stuff I was looking for.

I checked in the dev tools, there was nothing else than a div#gridDemo and some div.square-items inside. I checkd for gridDemo in the source code, and found out the code for that example:

// Grid demo
new Sortable(gridDemo, {
  animation: 150,
  ghostClass: 'blue-background-class',
});

I couldn't believe it... only those three lines of code and that's it ?
And the api looks straight forward too : the onEnd function seems doing the job I needed.

I had to try it by myself !

Start with a simple grid, and just add a few more lines

I wrote the React initial code : an array of items display in a grid layout.

import React, { useState, useEffect, useRef } from 'react';
import Sortable from 'sortablejs';
import './style.css';

const initData = Array.from({ length: 15 }, (_, i) => ({
  _id: (i + 1).toString(),
  content: (i + 1).toString(),
}));

const SortableGrid = () => {
  const [data, setData] = useState(initData);

  return (
    <div id="gridDemo">
      {data.map(({ _id, content }) => (
        <div key={_id} data-id={_id} className="grid-square">
          {content}
        </div>
      ))}
    </div>
  );
};

export default SortableGrid;

I then just added:

one ref for the grid container
one ref for the SortableJS element
one Effect to initiate SortableJs
one function to handle the drag and drop
data-id to all of the items in the grid layout
a bit of refacto to save the new layout in storage (or in your back-end most probably)

so that the code would be the one I wrote at the beginning, and as you can see, it works !

I don't like React Hooks

Arnaud Ambroselli — Thu, 19 Mar 2020 05:21:00 +0000

Let's go strait to the point : I don't like Hooks because they are not intuitive to me.

Classes are so intuitive that I love them.

class App extends React.Component {
  state = {  }
  componentDidMount() {}
  componentDidUpdate(prevProps, prevState) {}
  componentWillUnmount()
  render(){
    return()
  }
}

It's almost if there is a README to understand what's going on there.
I became a developer at 30, two and a half years ago, and I started directly by learning #JavaScript30 by Wes Bos, then React for Beginners. I knew nothing about programming : classes, whatever... but React was so straightforward to embrace that it was a pleasure.

I can't say the same with hooks.

const App = () => {
  const [someState, setSomeState] = useState(initState)
  useEffect(() => {
    return () => {}
  }, [])
}

OK, much less code I have to admit.
useState is easy to get, I also have to admit. For a simple functional component which needs a state, this is great. But for more complex component, actually I would say as soon as an equivalent of componentDidMount is needed, I much prefer classes.

After two projects and two months full time on hooks, I am still not confident how to clear a timeout, how to use an effect only on mount. I start to be confident on fetching async data in an effect, but that's it. OK, refs are quite straight forward, I also have no problem with them.
But what about the useCallback ? Sometimes, quite often, but not always, when I call a callback in my effect, I am forced by my linter to use useCallback, and I couldn't tell you why some times yes and why some other times no. Maybe I need a few more weeks to be fluent in Hooks, but as I don't like them it might be more...

I am working for the first time with a friend, on a hooks project for the last two months. My friend is chasing the code lines, to reduce them at max, and he is also chasing code readability. He is quite an experienced programmer, so I learn quite some stuff from him. He doesn't like redux, so I had to think without it, it was great. And he loves hooks, so I had to deal with them, no choice.

And I'll remember two philosophical principles out of my bad experience with Hooks :

if a piece of code with less lines is less understandable than a piece of code with more lines, use it with more lines
a good API is an API where the README is as small as possible, and the number of times the need of going back to the README is as little as possible.

Sorry Dan, but from now on, I'll keep hooks for stateful simple functional components, like forms. But whenever I can, I will use classes.