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 is not Code

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:

• Prone to errors
• Increase in the back-and-forth between developers and content owners
• Difficulty managing pluralizations and variants of text

What Does Unsafe Text Look Like?

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.

1. With code and interpolated variables throughout, it’s difficult to assure that the text is free of spelling and grammatical errors.
2. Pluralization is handled manually, which can be hard to update and maintain.
3. In a similar vein, variants are handled manually (e.g. whether to show “Claim” or “Purchase” based on if the customer has a voucher or not).
4. If text in designs change, a developer will have to retrieve the latest version from the designs or designer/writer, carefully update the text, making sure not to miss any repeated occurrences.
5. All of the above becomes exponentially more problematic if localization is needed.

Safe Text with Ditto

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:

{
  "cart.message": {
    "name": "Cart Message",
    "text": "You have 1 item in your cart.",
    "status": "FINAL",
    "folder": null,
    "variables": {
      "itemCnt": {
        "example": "3",
        "fallback": "0",
        "__type": "number"
      }
    },
    "plurals": {
      "one": "You have 1 item in your cart.",
      "other": "You have {{itemCnt}} items in your cart."
    },
    "tags": [
      "CART",
      "MESSAGE"
    ],
    "notes": "Located under the cart CTA button."
  }
}

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!

Starting Your Safe Text Journey

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:

1. Create the component (text) in Ditto, adding relevant plural, variant, and variable information. Typically this is done by designers/writers but it may make sense for you as a developer to get the process started.
2. As each piece of text in Ditto is automatically assigned a Developer ID, all we need to do is pull text data from Ditto and use the IDs in code. There are a couple options on how to do this:
3. If you’re using React,  the Ditto React SDK is a convenient way to import Ditto text directly into your React code. Pair this with Ditto’s VSCode extension to make the unsafe → safe text conversion process even easier.
4. Otherwise, the Ditto CLI allows you to pull and save strings files into your codebase that you can then import into your code.

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!