Ever needed to convert a string to camelCase? I found an interesting code snippet while exploring the open-source Supabase repository. Here’s the method they use:

function featureToCamelCase(feature: Feature) {
  return feature
    .replace(/:/g, '\_')
    .split('\_')
    .map((word, index) => (index === 0 ? word : word\[0\].toUpperCase()   word.slice(1)))
    .join('') as FeatureToCamelCase
}

This function is pretty neat. It replaces colons with underscores, splits the string into words, and then maps through each word to convert it to camelCase. The first word is kept in lowercase, and the subsequent words have their first character capitalized before being joined back together. Simple yet effective!

I came across another approach on Stack Overflow that doesn’t use regular expressions. Here’s the alternative:

function toCamelCase(str) {
  return str.split(' ').map(function(word, index) {
    // If it is the first word make sure to lowercase all the chars.
    if (index == 0) {
      return word.toLowerCase();
    }
    // If it is not the first word only upper case the first char and lowercase the rest.
    return word.charAt(0).toUpperCase()   word.slice(1).toLowerCase();
  }).join('');
}

This code snippet from SO has comments explaining what this code does except it does not use any sort of regex. The code found in Supabase’s way of converting a string to camelCase is very similar to this SO answer, except for the comments and the regex used.

.replace(/:/g, '\_')

This method splits the string by spaces and then maps over each word. The first word is entirely lowercased, while the subsequent words are capitalized at the first character and lowercased for the rest. Finally, the words are joined back together to form a camelCase string.

One interesting comment from a Stack Overflow user mentioned the performance advantage of this approach:

“ 1 for not using regular expressions, even if the question asked for a solution using them. This is a much clearer solution, and also a clear win for performance (because processing complex regular expressions is a much harder task than just iterating over a bunch of strings and joining bits of them together). See jsperf.com/camel-casing-regexp-or-character-manipulation/1 where I’ve taken some of the examples here along with this one (and also my own modest improvement of it for performance, although I would probably prefer this version for clarity’s sake in most cases).”

Both methods have their merits. The regex approach in the Supabase code is concise and leverages powerful string manipulation techniques. On the other hand, the non-regex approach is praised for its clarity and performance, as it avoids the computational overhead associated with regular expressions.

Here’s how you can choose between them:

• Use the regex approach if you need a compact, one-liner solution that leverages JavaScript’s powerful regex capabilities. Also be sure to add comments explaining what your regex does, so that your future self or next dev working with your code can understand.
• Opt for the non-regex method if you prioritize readability and performance, especially when dealing with longer strings or running this conversion multiple times.

Want to learn how to build shadcn-ui/ui from scratch? Check out build-from-scratch

About me:

Website: https://ramunarasinga.com/

Linkedin: https://www.linkedin.com/in/ramu-narasinga-189361128/

Github: https://github.com/Ramu-Narasinga

Email: [email protected]

Build shadcn-ui/ui from scratch

References:

1. https://github.com/supabase/supabase/blob/master/apps/studio/hooks/misc/useIsFeatureEnabled.ts#L16
2. https://stackoverflow.com/a/35976812