Quick Tips - Eric Feminella

Quick Tip: React Spring & Babel Loader

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:

import {Trail, animated} from 'react-spring/renderprops';

To:

// ES5 import (note .cjs extension) .

import {Trail, animated} from 'react-spring/renderprops.cjs';

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.

Comments Off

Synchronizing package.json with yarn.lock

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!

November 5, 2018 Code Review / JavaScript / Quick Tips / Software Engineering

Comments Off

React PropTypes and ES6 Destructuring

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:

import React from 'react';

import PropTypes from 'prop-types';

/* import React, {PropTypes} from 'react'; // react < v.15.5 */

...

LoginForm.propTypes = {

validate : PropTypes.func.isRequired,

authenticate : PropTypes.func.isRequired,

persistCredentials : PropTypes.func.isRequired,

fetching : PropTypes.bool.isRequired,

rememberMe : PropTypes.bool.isRequired,

username : PropTypes.string,

password : PropTypes.string,

muiTheme : PropTypes.object,

errors : PropTypes.object

}

...

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:

...

const {func, object, string, bool} = PropTypes;

LoginForm.propTypes = {

validate : func.isRequired,

authenticate : func.isRequired,

persistCredentials : func.isRequired,

fetching : bool.isRequired,

rememberMe : bool.isRequired,

username : string,

password : string,

muiTheme : object,

errors : object

}

...

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:

...

const {

func: {isRequired:funcReq},

bool: {isRequired:boolReq},

object,

string

} = PropTypes;

LoginForm.propTypes = {

validate : funcReq,

authenticate : funcReq,

persistCredentials : funcReq,

fetching : boolReq,

rememberMe : boolReq,

username : string,

password : string,

muiTheme : object,

errors : object

}

...

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.

April 24, 2017 Code Review / Design Patterns / ES+ / JavaScript / Quick Tips / React / Refactoring

1 Comment

NPM & Root Permissions

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:

sudo chown -R $(whoami) ~/.npm

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

sudo chown -R efeminella ~/.npm

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

November 1, 2016 Quick Tips

Comments Off

React-Bootstrap ES6 Imports

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:

// import Navbar ...

import {Navbar} from 'react-bootstrap';

...

{/* reference Text component as a sub-component of Navbar */}

<Navbar.Text>...</Navbar.Text>

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:

// import NavbarText ...

import {Text} from 'react-bootstrap/lib/Navbar';

...

{/* reference Text component */}

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.

August 12, 2016 ES+ / Quick Tips / React

Comments Off

Quick Tip: HTML to JSX Conversion

Like many developers, at times I find the need to convert raw HTML to JSX. It was only after I found myself needing to do this a bit more frequently that I considered writing a quick tool to automate the task. However, like most things, I knew there must be something out there which handles this already, and as I suspected, there certainly is: HTMLtoJSX – a component of React-Magic which does precisely this.

So, if ever you need to quickly convert raw HTML to JSX, be sure to check out the online converter and, for more frequent needs, the converter is also available via NPM and can easily be integrated into part of an existing build pipeline.

July 19, 2016 HTML5 / News / Quick Tips / React

Comments Off