I mean, it's hard to tell why you're doing what you're doing there. Sometimes with JavaScript and frontend code, certain crimes are just a necessary evil.

But yes, I am calling it a crime to concatenate strings and decompose them afterwards.

For one, human errors like what you did are possible.

You could mildly improve on that by pulling out two functions:

• encode_blah_list_to_string()
• decode_blah_list_from_string()

You could then at least define those directly below each other in the code, making it easy to define them, so they work together.
If you've already looked into unit tests, this would also be an incredibly easy and useful unit test to write. In your test code, you would define a list, then call the encode-function, take the result of that and call the decode-function, and then the result of that should be identical to the original list.

Having said that, encoding things as a string with custom logic like that, has another big problem:
It could happen that e.g. stringTwo contains "Hello, World". Suddenly, you'd be splitting in the middle of stringTwo, when you're decoding.

So, ideally you can avoid it completely and pass around the array directly.

If you can't, the next best thing would be to encode it in JSON. It will handle all these edge cases, and it's a clearly defined way of encoding and decoding, so you wouldn't even need to pull it out into functions.

If it's some custom format that you display to the user (and ideally the user is aware that commas are bad), then yeah, you would have to do the custom encoding and decoding implementation, like described above.

I am aware that strings that are frequently used should be made constant, although I could use more specifics on what "frequently used" is (more than once?) and I'm wondering if you actually should not really use strings at all and always go for constants.

Alright, so if it's a string where it matters that it's spelled exactly correctly and it will be used in more than one place in your codebase, then I would always pull it out into a constant.

If it's an unchanging value that you just pass to a library in one place in your code, like a timezone name, then I wouldn't usually pull it out into a constant, unless I feel like it helps to make this constant clearly visible at the top of the file.
For example, it rarely happens that a constant is unquestionably correct and unchanging, so making your choice prominently visible can be useful. Of course, if you're not running in a browser, then these kind of arbitrarily chosen 'constants' should probably be configurable in a configuration file.

If it's a UI description text, then it might make sense to pull it out into a constant, just to unclutter your code.
Or if you're working with a localization framework, then you'd have pseudo-constants for that anyways, which would get replaced with the respective language text at runtime.

But yeah, I definitely wouldn't say you should always go for constants. They add a layer of indirection, meaning someone reading your code won't know what the actual string is without checking the constant.
But if it needs to be the same value in two places, then this layer of indirection is definitely worth it and makes it easier to reason about your code.

I will also say that if we weren't talking about JavaScript, I would be much more contrarian to strings. Partially because JS is used in frontend a lot, where you do need to deal with strings anyways. And partially, because JavaScript is dynamically typed, so it just doesn't have as many tools to deal with strings otherwise.

In our backend Rust codebase at work, I do tell our juniors, if you're typing a quotation mark and you're not doing it for logging or error messages, then do consider, if that's really what you want. Usually, they want an enum instead, or if they really do need to pass around a string, then they should use a newtype, which is basically a typed wrapper, so you can't accidentally pass the wrong kind of string into a function.