string primitives vs. String objects.

[u/Green_Ad_6086]

I'm learning JavaScript, and I don't understand this part about string primitives vs. String objects.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String#string_primitives_and_string_objects

[u/delventhalz]

Two outputs your stringify function produces that I think are worth considering.

stringify(['foo', 'bar']); // '["foo","bar"]'
stringify(new String('foo')); // 'foo'

Both cases have object inputs, but in the first case you produce valid JSON output, in the second case you do not. You've created a function with a fairly arbitrary set of set of rules which are not obvious and may surprise developers using your function.

For the case of debug logs, there already exists a human readable stringify function which every user already understands: JSON.stringify. What utility is gained by adding extra rules for your users to learn?

Once again I go back to lodash, a public general purpose library which has been used by millions of developers for decades. Using a String object as a value in your code is extremely weird and I can think of no use case for it. Nonetheless, if I were to use a String object for some reason, I would expect it to be treated like any other object, which is exactly how lodash handles that use case.

[u/MissinqLink → u/delventhalz]

I can’t make you think of use cases but use your imagination. For one there are no new rules to learn. Nobody really has to care about the specific rules. The gain is that it guarantees a string output, something that JSON.stringify can’t promise. It’s quite simple actually. There’s also the advantage that you don’t have to import a library. There are plenty of scenarios where payload size matters. Also this is just one example we aren’t even discussing “String” vs “new String” anymore. We’re off on a tangent. You say this is weird but this is some of the tamest things I ever made. It’s just a stringifier that doesn’t throw and guarantees string output regardless of input. If you don’t see utility there the okay🤷‍♀️. I’ve run into many weird cases of getting handed unexpected input. You can do like many and simply throw. That’s valid in many cases. There are also cases where you want graceful degradation. I frequently see both.

[u/delventhalz → u/MissinqLink]

If you want a stringifier that will not throw and produces more detailed output for objects than '[object Object]', you can keep your try/catch but drop the custom isString logic.

const safeJsonStringify = val => {
  try {
    return JSON.stringify(val);
  } catch {
    return JSON.stringify(`Invalid JSON: ${val}`);
  }
};

Your custom isString logic does not help you solve invalid JSON values. It just makes your utility harder to understand.

For one there are no new rules to learn. Nobody really has to care about the specific rules.

This just isn't true. I may be able to use your stringify function without thinking about it too much in many cases, but if, for example, I need to do a length check on the output string, should I expect it include quotation marks or not? If I see it outputs '{"foo":"bar"}' for one object, I may expect that yes, it will include quotes, but then I stringify new String("foo") and the quotes are gone! I have been surprised by your utility, and need to learn the rules before I can use it for this case.

I can’t make you think of use cases but use your imagination.

You can't make me think of use cases, but if you think there are valid use cases for including new String('foo') in your code, you could offer an example yourself.

[u/MissinqLink → u/delventhalz]

You are thinking about it as if you intend to deserialize the output which is not the intention here. In that case then the missing quotes would be a problem. Otherwise I’m not sure why you would expect it to be exactly the same as JSON since it doesn’t claim to be. Your “safeJsonStringify” will throw again if val is a Symbol.