I wrote a “function” for this exact reason. It’ll display the classes in a much easier to read way. It also can type check to ensure that all classes are valid. I say function in quotes because it’s actually a babel macro that’s get compiled down so there’s no runtime cost! https://github.com/fleck/class-types.macro#better-prettier-f...
Those who aren't adopting are missing out! I've been using Render for a few months now on a postgresql/next.js app and it's really good! Hopefully the new signups continue to accelerate
Agreed. Number is not only more obvious than parseInt for other coders but also defaults to base 10, whereas parseInt (at least historically) does not (edit: ...if you've got leading zeros, see post below).
> defaults to base 10, whereas parseInt (at least histortically) does not.
To clarify for others (because this probably sounds crazy): The default is implicit like the rest of JavaScript, it will change base depending on presence of the prefixes 0x (16) and 00 (8), it doesn't seem to have included 0b yet. The confusing bit was octal because as you can imagine some sources might have base 10 padded with zeros, ES5 basically removes implicit octals in parseInt to avoid this issue.
Arguably this is more of a problem with the ambiguous octal prefix than the concept of using prefixes to determine base.
parseInt will use the first few characters in the string as a heuristic to determine the radix. It’s not reliable for some types of common decimal strings(padded zeros will cause erroneous parsing)
