useExtracted with repeat strings

[kieranm]

Hello!

I'm really enjoying useExtracted but I'm not sure on the best way to handle mapping enum values -> strings without redefining the strings everywhere. At the moment the only approach I can think of is to define a custom hook for it...

export const useEventTypeToDescription = () => {
  const t = useExtracted("event_types")
  return useCallback(
    (eventType: DBEvent.Type) => {
      switch (eventType) {
        case DBEvent.Type.Block:
          return t("Block out time for focusing")
        case DBEvent.Type.Event:
          return t("Meet with others")
        case DBEvent.Type.Marker:
          return t("Be aware of something happening")
        case DBEvent.Type.Task:
          return t("Track something you need to do")
        default:
          throw new Error(`Unknown event type: ${eventType.name}`)
      }
    },
    [t],
  )
}

Is there a better/more idiomatic way to approach this with useExtracted? Thanks!

[kieranm]

Also, especially if the strings are very long (like paragraphs long) and need to be reused in multiple places, what's the best way to achieve that? Thanks!

[amannn]

Hey @kieranm, glad you're giving useExtracted a shot!

And yeah, good questions!

Something like the hook you've mentioned above is a pattern I've used as well, yes—so definitely an option.

Another option is to precompute all options in Server Components and pass it where necessary (potentially even with React Context):

import {getExtracted} from 'next-intl/server';

async function Component() {
  const eventDescriptions = await getEventTypeDescriptions();
  // ...
}

async function getEventTypeDescriptions() {
  const t = await getExtracted();
  return {
    [DBEvent.Type.Block]: t("Block out time for focusing"),
    [DBEvent.Type.Event]: t("Meet with others"),
    // ....
  };
}

The pattern ofc. also works via a hook, but defining it in server code might be handy to use it on that side already.

Would something like this also fit your use case of very long texts?

The other side is that I think there's a distinction to draw between app labels and labels related to (backend) data. Depending on your use case, moving some labels to the backend side, esp. if it's related to array-esque / dynamic data, is often helpful IMO. Not sure if that's really the case here though.

Btw., I'm trying to collect feedback in a centralized way over in #2036 so others can easily chime in and discuss what works and what doesn't as patterns emerge. So feel free to post future feedback over there!