You are currently browsing the Quick Tips archives.

Quick Tip: Resolving Chrome Dev Tools Variable Hover Issue

Thursday, January 16th, 2020

With the Chrome (~79) update, you may have noticed that the Dev Tools variable hover > value feature has been broken. This issue is covered by 1033022 in Chromium; though, a stable fix for version 79 remains elusive.

For me, this was one of those “You don’t know what you got til’ it’s gone” type of situations as, I have become rather accustomed to this feature, and so having to rely on the Scope Panel has became quite tedious.

The good news is (or at least what has worked for me) was I was able to resolve the issue by simply uninstalling, then reinstalling Chrome. While generally this should be a last resort solution, and the fact that it actually worked is rather odd in that the same exact version was installed, it has worked, and so I figured I’d share for others to give a try until a proper fix is in place in Chrome 80.

Quick Tip: React Spring & Babel Loader

Thursday, October 3rd, 2019

Recently, I had integrated React Spring within an Application, and while it is one of the best Animation Libraries for React I have come across in quite some time; unfortunately, I encountered some issues when running tests and production builds.

Essentially, the issues I experienced were related to the imported modules being written in ES6. This was an issue for me as I prefer to have webpack babel-loader configured to exclude node_modules and only transpile project sources.

Fortunately, the work around for this is quite simple: just import the CommonJS modules (i.e. .cjs extensions) rather than their ES6 counterparts (i.e. no extension).

Thus, simply changing:

To:

Resolves the issue.

And so, should you happen to come across build issues when using React Spring, a nice alternative to including the node_modules directory or specific dependencies is to simply import the CommonJS modules.

Synchronizing package.json with yarn.lock

Tuesday, November 13th, 2018

After having used Yarn almost exclusively for the past couple of years, there has been one nagging issue which seemed to continually crop up. Specifically, the inability to have a project’s package.json dependency versions kept in sync with the actual versions in yarn.lock. And so, while running yarn upgrade results in all packages being updated to the latest versions (as specified via the given semver ranges), the versions defined in package.json are not updated to reflect that which they have been upgraded to.

This can prove problematic as, one can not easily discern a project’s dependency versions by simply viewing their respective values in package.json.

In particular, as part of process, after each production release I have scripts which are executed to automate the process of updating all project dependencies to their respective latest Minor and Patch revisions prior to opening master for new development. While the scripts manage the updates and committals internally, each project’s package.json would remain unmodified, making it challenging to determine which packages have been upgraded, and which have not. Having to automate or manually inspect the yarn.lock files is less than ideal, and quite cumbersome to say the least.

Fortunately, like most things in the Javascript world, there is a package for this; syncyarnlock, which provides exactly what one would need to ensure that the dependency versions defined in package.json are kept in sync with the project’s yarn.lock.

Simply install syncyarnlock, and execute with the options applicable to your needs.

For example, to sync a project’s package.json with the project’s yarn.lock, and have the ranges remain intact while updating the versions to reflect what will actually be installed, simply run: syncyarnlock -s -k.

This will result in the dependency ranges being preserved, while also updating their versions to reflect the versions that will actually be installed.

And with that, we have proper syncing. A definite time-saver!

React PropTypes and ES6 Destructuring

Monday, April 24th, 2017

At times one may be justified in the argument that cognitive (over)load is just an expected part of the overall developer experience. Fortunately, there are numerous steps we can take to minimize the general noise which tends to distract our intended focus. One particularly simple – yet effective – example is to remove unnecessary redundancy wherever possible. In doing so, we afford both our peers and ourselves a codebase which, over time, becomes considerably easier to maintain.

For instance, when performing code reviews, more often than not I tend to see considerable redundancy when specifying React PropTypes. Typically, something along the lines of:

As can be seen, with each new prop we are redundantly referencing React PropType lookup paths. And, while the ideal components will have a limited number of props (either connected directly, or passed down), the redundancy still remains for any component which references the same prop type. Considering the number of components a given application may contain, we can rightfully assume that the above redundancy will grow proportionally.

With the above in mind, we can easily reduce the redundancy (as well as micro-optimize the lookup paths) be simply destructuring the props of interest as follows:

While I would consider the above to be simplified enough; one could also take this a step further and destructure the isRequired props, which, in some circumstances, may be useful as well:

Admittedly, this example is rather straight-forward; however, it does help to emphasize the point that only through consistent vigilance can we ensure our source will continue to evolve organically while remaining as simple as possible.

NPM & Root Permissions

Tuesday, November 1st, 2016

When dealing with NPM Permissions, often times it can be tempting to resort to installing modules as root (sudo), especially when under tight time constraints; where troubleshooting such issues will only serve to delay your progress.

Admittedly, I have been guilty of this more often than I care to admit. That said, being as I always have the Broken Windows Theory in the back of my mind, I knew this workaround needed to be resolved as soon as I had a moment to dig into it a bit more.

Previously, I had followed the instructions from docs.npmjs; however, they focus more on installations of global dependencies, rather than local dependencies. Fortunately, after a few quick searches, it became apparent that by simply changing permissions to the ~/.npm directory, this issue could easily be resolved as, all that is needed is to change the owner of the ~/.npm directory to the current user (as opposed to root).

To do so, simply run the following:

Likewise, you can use your username explicitly; e.g.:

And with that, the issue can safely be resolved, allowing you to run npm install as expected without having to fallback to using sudo.

React-Bootstrap ES6 Imports

Friday, August 12th, 2016

When leveraging React Bootstrap, one important consideration missing from the documentation (or perhaps, simply not emphasized enough) relates to module access when using ES6 imports.

Specifically, in the context of React Bootstrap’s “convenience components” <Component.SubComponent> (e.g. <Modal.Body>), such imports must be made explicit as they can not be resolved against their parent components during transformations of ES6 imports to CommonJS modules.

For instance, one can not reference sub-components as follows:

During transpilation, the above reference will result in Babel (specifically, the babel-plugin-transform-es2015-modules-commonjs module) causing an upstream exception:

Property object of JSXMemberExpression expected node to be of a type [“JSXMemberExpression”,”JSXIdentifier”] but instead got “MemberExpression

Fortunately, the solution to the issue is rather straight-forward; simply import the sub-component explicitly via react-bootstrap/lib , for example:

With the above example, the previous conversion errors will be resolved, and all will be well again.

Overall, I actually prefer the explicit imports (though it would be more convenient if they were exported via ‘react-bootstrap’).

And so, for the time being, a minor nuance worth noting should you find yourself trying to diagnose this issue at some point.