React: PropTypes: Shape within Shape causes unwanted ‘isRequired’ – looks like a bug?

PropTypes are used for setting stricter types in React than JavaScript has traditionally supported (similar to TypeScript for Babel).

One of the types is shape , which allows you to describe the properties of an object, and their proptypes too.

However, if I declare a proptype as a shape within a shape, thus:

I get an error:

As can be seen above, the .isRequired  property has not been set at all!

Solution (Workaround)

If the inner shape is defined PRIOR to referencing it within the propTypes shape, the PropTypes library doesn’t throw the error:


JS RX: Strict Mode interferes with back references

Strict mode prevents the use of back references within a regular expression defined with new RegExp() , mistaking them for octal literals. Use escaped strings instead.

This sucks.

The explanation:

I have a regex:

This little snippet is used to extract properties from objects portrayed as strings – as they aren’t JSON valid, but highly predictable, I’m parsing them myself.

This string:   htmlSelector: '.awe-display-code' will produce the following result:

This appears to be all fine and dandy, but we are matching based on this crucial chunk:  [\'\"`] which appears either side of our property value.

Lets say our value is encapsulated with single quotes:
If a double-quote or backtick is present in the value, the regex will stop matching there and then.

(Note, we aren’t concerned about handling escaped single quotes, for the sake of this explanation)

We can ensure that the second encapsulation character matches the first with a backreference. By making a group of the encapsulating chars through wrapping them in parentheses thus :  ([\'\"`])  we can refer to them later in the regex by their group index – in this case the index is 4, as we’ve added it before the group containing the property we wanted. Our regex now looks like this:

Problem solved!

Sadly, if our file declares  'use strict';  this will throw  an error.

The parser is mistaking \4  for a representation of an octal number, which is deprecated in strict mode.

The solution:

Instead of declaring the regular expression with new RegExp(string) , declare it as an escaped string:


TIL: Git and folder name changes

TIL: If you rename a folder, but only change case in the folder name, Git DOES NOT TRACK THE CHANGE.

Normally I only ever use lower case so I’ve never come across this before.

I’m building a React library at the moment so using Classname capitalisation in filenames. As my components grew to incorporate multiple files, I moved them to discreet directories, then decided the directory names should be consistent with the files. When I moved from the office machine to home and pulled my changes, the folder name failed to change.

You can change Git’s behaviour easily though:

git config core.ignorecase false

Quick experiment: Animated ‘text-decoration’ in pure CSS

There’s a whole bunch more that can be done with this technique.
Using the pseudo element innards instead of the border would allow for gradient borders, or images (Images? Why not? Perhaps curlicues for baroque fanciness! SVG of course…)

See the Pen Animated text decoration in pure CSS by David Benson (@disasterman) on CodePen.0

I must admit to having been inspired by the following CodePen, which is rather clever…

Right-click and drag not working in latest Chrome (~v60+)

When I got this urgent bugfix request I thought it was going to be hell, but fortunately, it turned out to be relatively easy.

When a mouseUp event is triggered, you can check which button has been pressed with the event.button property (in some browsers event.which, and which also has different values from button, but I’m just focused on Chrome atm).

Previously in Chrome, on a mouseMove event while a button was pressed, the event.button property showed the integer for the clicked button (2 in the case of a right-click), but this was changed recently, and it now shows 0, presumably as there is not button click, either up or down, at that moment in time. Without doing any research I’m going to take a punt that this is a better match for the spec, and it does make a certain amount of sense, if one can get over the inconvenience.

The simple answer is to set a flag when the mouseDown event is triggered:

N.B. Remember to declare the initial variable previously in a scope accessible to all of your mouse events.

Then in your mouseMove event, where previously you checked event.button == 2, you can now check isRightClick:

And finally, don’t forget to toggle the flag off at the end of the mouse operation;

This has the added advantage that if you do care about x-browser compatibility and those browsers that prefer event.which,you check for the relevant property only once, when mouseDown, fires and subsequently only have to check isRightClick during the mouseMove event  – and as mouseMove can fire thousands of times, this is a tiny but worthwhile optimisation.

Frankly you should have been doing that anyway. My excuse is I didn’t write the application I’m working on, and the person who did is most definitely NOT a front-end developer!

This change was introduced recently, somewhere around Chrome version 60/61 as far as I can tell.