In the complex world of front-end development, we often overlook one crucial component — text. Improper text handling, like managing hardcoded strings in code, can lead to problems that impact consistency, readability, user experience, and time loss for both developers and non-developers. In this blog post, we'll take a closer look at the challenges associated with raw text in front-end code and why it's essential to practice “safe text.”
Text, despite being embedded within code, isn't code and thus requires different handling. The main differences lie in ownership, review processes, and tooling: while code is the developer's domain, text is usually owned by people upstream working on design and product (designers, writers, PMs, and even compliance). Reviewing code involves checking its readability and testing its logic, whereas reviewing text content focuses on spelling, grammar, and user comprehension. Finally, with code, we have tooling like type systems to help prevent mistakes from being made, but unfortunately, they do nothing for hardcoded strings. If we don’t recognize these boundaries and treat text as code, we end up with what we might call “unsafe text.” To elaborate, unsafe text has some of the following undesired characteristics:
To illustrate unsafe text, let’s take a look at some React code for a shopping cart information component.
This would correspond to a UI that looks something like this:
There are several things that make this code error-prone and difficult to maintain.
To solve this, we can use Ditto, a text management tool, to make the text “safe”. On the developer side, Ditto functions like a headless CMS for product, making life easier by eliminating the need to manually update and manage text within code. For designers/writers, it creates an end-to-end process for creating, reusing, reviewing, and integrating text within designs.
With Ditto, we can pass in a variant to DittoProvider which will handle all conditional voucher logic for us. In addition, pluralization is also automatically handled, eliminating a lot of complex, ugly code.
Next, any edits to text in Ditto can be pulled automatically via the Ditto CLI, which prevents manual copy/paste errors and copy update tasks for developers to complete. The CLI fetches the text in whichever format fits into a developer’s existing workflow: flat JSON, structured JSON, iOS strings, XML, and others. An example in the structured JSON containing all variable and plural data:
This JSON file is where the Ditto React library sources data from and will be updated whenever the CLI is asked to pull new information.
In addition to all these developer benefits, Ditto’s web app and Figma plugin both have Grammarly support to prevent spelling and grammatical errors.
For context, the cart.message text component in Ditto looks like this:
This would be managed by the team’s content owners, so they will never be blocked by a developer having to manually make changes to text!
Like shown in the example, one option for managing product text is using Ditto to systemize text from design to development. With Ditto, the process looks something like this:
For more information on the process, check out Ditto's developer documentation.
Luckily, it’s easy to take an iterative approach as you don’t need to update everything at once. The best way to start would be to start on a high-visibility text and text that changes frequently. Once you get the ball rolling, safe text will no doubt make your life as a developer managing content a lot easier!