It’s useful to know about even if you have no use case for it. Because this conversion happens every time you access a property on any JS primitive. For example, this:

    str.toUpperCase()

Is actually doing this:

    new String(str).toUpperCase()

...hand waving away obvious optimizations that surely occur for multiple property access.

There may be cases, for instance a series of imperative synchronous hot loops, where this has a meaningful performance impact.

Another thing that’s important to know is that you can do this:

    Object.assign(str, {
        anythingAt: ‘all’
    })

And you’ve now mutated your string into a String. This breaks a buuuuunch of expected behaviors with primitives, such as === and the default Array#sort comparator.

Edit: this last one bit me experimenting with a runtime implementation of a common pattern in TypeScript to define nominal types for primitives (e.g. to distinguish a known valid URL from a regular string) called branding[1]. The approach is useful if you’re obsessive about type safety, but flawed because it almost certainly misrepresents the runtime type. I tried to use Object.assign to get that much more type safety and... I got the opposite! I got a String claiming to be a string, which broke all sorts of stuff, including the aforementioned === and Array#sort.

1: https://medium.com/@KevinBGreene/surviving-the-typescript-ec...

Only thing useful I can come up is monkey patching without changing the function signature. E.g. smuggling additional data to a function which expects a string like thing.

But I think the whole `new String` is problematic, because it breaks the strict comparison:

  let a = "Foo";
  let b = new String("Foo");
  a === "Foo"
  true
  b === "Foo"
  false

> Only thing useful I can come up is monkey patching without changing the function signature. E.g. smuggling additional data to a function which expects a string like thing.

Yeah this sounds terrifying to me, if I were to debug something like this.

Also the fact they identify as objects:

    typeof new String("Foo") === 'object';

Case closed, I will never use it :D

Primarily for adding properties, and making objects that can be inherited from (unlike primitives). This is a great answer with even more cases:

https://stackoverflow.com/a/39113022/110241

> Primarily for adding properties

I personally would never expect a property which is treated as a string. That's what POJOs are for, but that is just opinion I guess. still weird they let you do this.

> and making objects that can be inherited from (unlike primitives).

I mean the SO gives an example of how to do it but I would still love to see some place where this is needed or even pragmatic to any degree.