I'm reasonably new to PropTypes in my React code and I'm always messing up the naming.
Sure "number" and "string" are easy enough, but why are "function" and "boolean" in a different format to all the others?
PropTypes cheat sheet
According to the Typechecking with PropTypes article the following types are available:
array | primitive type |
---|---|
bool |
primitive type |
func |
primitive type |
number |
primitive type |
object |
primitive type |
string |
primitive type |
symbol |
primitive type |
node |
Anything that can be rendered: numbers, strings, elements, etc. |
element |
An instance of a React component |
elementType |
An element constructor (I think) |
instanceOf(x) |
An instance of class _x_ |
|
One of the given values |
|
One of the given types |
|
An array of the given types |
|
An object with certain property types |
|
An object of a given shape |
|
An object that exact matches the given shape |
Why "func" and "bool", not "function" and "boolean"?
I'm always tripped up on the spelling of "func" and "bool". Mainly because the rest of the PropTypes use full names whereas these two don't.
After asking on Twitter, a few folks suggested it might be to avoid Javascript symbol names
Reserved words caused issues in its initial implementation?
— Kevin Vanderbeken (@kevdesign) July 11, 2019
Honestly though the bool/func API gets me everytime. I've chalked it up, maybe, to avoiding native symbol names?
— mr lochlan (@loklaan) July 11, 2019
But that still didn't answer the question because while "function" is a reserved token in Javsascript, "boolean" definitely isn't.
Eg. assigning to function
throws:
> const function = 'error';
Thrown:
const function = 'error';
^^^^^^^^
SyntaxError: Unexpected token function
But assigning to Boolean is totally fine:
> const boolean = 'truly an allowed keyword';
undefined
> boolean
'truly an allowed keyword'
> Boolean(boolean)
true
Further, these tokens are both allowed in an object definition:
> const ParpToots = { function: 1, boolean: 2 }
undefined
> ParpToots.function
1
The plot thickens
I wasn't really happy with the answers I was getting, so I did some Googling.
The search came up empty until I stumbled on this question on the PropTypes Github issue tracker from 2017:
Hi, I've searched a bit in the Readme and in the issues here, I did not find why we do not use Proptypes.function and Proptypes.boolean like we do for object (vs. obj), etc.
Why the shortnames? Are they reserved words? If not, it would be nice to create aliases maybe for these two ones no?
Which was followed up a few hours later with the answer:
Yes, you can't do
const { function, bool } = PropTypes
in JS because they're reserved words.
Which… is a little more satisfying.
Except we've already shown boolean
isn't a reserved word. So what's going on? 🤔
boolean: a reserved word in ES3
Having found the reason why PropTypes doesn't use boolean
, I needed to connect the dots. Why is it considered a reserved word?
I eventually landed on the MDN Docs on Javascript lexical grammar which lists the full set of reserved words for Javascript, as well as some previously reserved words from older specs.
And wouldn't you know; there's boolean
sitting in a list of "future reserved words" from the ECMAScript Language Specification edition 3, direct from the year 2000.
7.5.3 Future Reserved Words
The following words are used as keywords in proposed extensions and are therefore reserved to allow for the possibility of future adoption of those extensions.
abstract enum int short
boolean export interface static
byte extends long super
char final native synchronized
class float package throws
const goto private transient
debugger implements protected volatile
double import public
The bingo card of Javascript features
Looking at the list there's a good mix of keywords that eventually made it into the spec. const, class, import, all big ticket items.
"boolean", however, was eventually removed from the list and is no longer reserved.
I'm not sure what it would have been for, but alongside "int" and "short" you could wager it was intended to be part of a fully typed Javascript spec.
In fact, peering through history I found a bunch of resources around typed Javascript as early as 2000 (Microsoft had an optionally typed implementation of JScript for .NET 🤯), and there's some fascinating papers from around 2005 that talk about what sounds a lot like modern day Typescript.
Whatever alternate history we avoided, "boolean" is no longer a reserved word. Regardless, it left its legacy on the PropTypes package and many a Failed prop type: prop type is invalid error in our consoles.
Lol speaking of annoying to spell, import PropTypes from "prop-types" and set it on "propTypes" 🥴
— Ash Kyd (@AshKyd) July 12, 2019