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_
`oneOf([ 'News', 'Photos' ])`	One of the given values
`oneOfType([ PropTypes.string ])`	One of the given types
`PropTypes.arrayOf( PropTypes.string )`	An array of the given types
`PropTypes.objectOf( PropTypes.number )`	An object with certain property types
`shape({ a: PropTypes.string })`	An object of a given shape
`PropTypes.exact({ a: PropTypes.string })`	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

🤔 This is a slightly older post. It deals with Vue 2 and React class components. This is probably not what you need if you’re building a new app today.

React and Vue both have fairly well defined lifecycle events which we can use to successfully navigate the mysteries of the virtual DOM.

So without further ado, let’s get down to the React vs Vue lifecycle events smackdown!

Vue and React fighting in an animated fashion. A caption reads "Bam!"

Vue lifecycle events visualised

The following demo logs out the Vue lifecycle events when a component mounts and updates.

It’s actually a fairly nice API in that everything is consistently named, even if not all of the events are strictly useful.

Vue lifecycle events on codepen

React lifecycle events visualised

React is actually the more esoteric of the two in terms of naming, but actually offers more powerful functionality (such as my particular favourite, shouldComponentUpdate).

Vue lifecycle events on codepen

Component mount compared

The basic workflow for a component is pre-mount → render → mount.

Vue has more events, whereas React is more Javascripty with an actual ES constructor.

React	Vue	Description
constructor	beforeCreate	Roughly synonymous with each other. The constructor sets up the React class, whereas Vue handles the class creation for you.
–	data	Set data. Vue recursively converts these properties into getter/setters to make them “reactive”.
–	created	Data observation, computed properties, methods, watch/event callbacks have been set up.
–	beforeMount	Right before the mounting begins: the render function is about to be called for the first time.
getDerivedStateFromProps	–	Invoked right before calling the render method. It should return an object to update the state, or null to update nothing.
render	render	The virtual DOM is rendered and inserted into the actual DOM.
componentDidMount	mounted	The component is now mounted. We can make any direct DOM manipulations at this point.

We can see from our lifecycle that the perfect time to hook into the process is once the component has been mounted (in React’s componentDidMount or Vue’s mounted event).

Component update compared

Component update generally follows a pre-update → render → updated workflow. Easy!

React	Vue
getDerivedStateFromProps	–	Same as when mounting.
shouldComponentUpdate	–	Let React know if a component’s output is not affected by the current change in state or props. We can use this to prevent React blowing away our changes.
–	beforeUpdate	Called when data changes, before the DOM is patched.
render	render	The virtual DOM is rendered and patched into the actual DOM.
getSnapshotBeforeUpdate	–	Right before the most recently rendered output is committed to the DOM. Lets you save the previous state of the DOM for use after the component has updated.
componentDidUpdate	updated	After the DOM has been updated

Component unmount compared

When your component is removed from the page, sometimes you need to remove event handlers or clean up after any manual DOM manipulation.

React	Vue	Description
–	deactivated	When using Vue keep-alive, the component is removed from the page but not destroyed so that we can load it again later without the overhead of component mount.
–	activated	The previously deactivated component is reactivated.
componentWillUnmount	beforeDestroy	When a component is being removed from the DOM
–	destroyed	The component is completely gone.

Handling errors

This is something I’ve not looked too much into, but it’s possible to catch errors from child components and change the render accordingly.

This would be most useful for a top-level component (above the routes, maybe) to show an “Aw Snap” error message into your app and stop the error bubbling up.

React	Vue	Description
componentDidCatch getDerivedStateFromError	errorCaptured	An error occurred in a child component.

Conclusion

Each has their own benefits, neither is objectively better or worse. Personally I prefer the Vue naming, but prefer the power of the React API.

After pulling this info together I’m really interested to try out Vue’s keep-alive for render-intensive jobs. It’s a cool feature I didn’t know existed.

I’m also excited to play with component-level error handling, especially for larger apps. It makes a lot of sense to catch errors in the framework rather than waiting for them to bubble up to the global error handler 😅

Anyway, hope this was helpful. I learned something.

Tag: react

Why are React PropTypes inconsistently named?