ES+ - Eric Feminella

Unique Identifiers with JavaScript Symbols

The introduction of Symbols in ES6 marked a significant milestone, offering developers a new primitive type to enhance code clarity, privacy, and interoperability.

At their core, Symbols serve as unique, immutable identifiers, making them quite valuable for many use-cases. This article delves into the benefits of JavaScript Symbols, illustrating how they can be leveraged to provide implementations which are more secure and mitigate the risk of unforeseen conflicts.

Unveiling JavaScript Symbols

Before we explore the benefits of Symbols, it’s important to first understand what the actually are. In JavaScript, a Symbol is a primitive data type, just like string, number, boolean, etc.. However, what sets Symbols apart is their guarantee of uniqueness. Every time you create a Symbol, it is distinct from all other Symbols, even if they share the same value.

Creating a Symbol is rather straightforward:

let name1 = Symbol('name');

Despite having the same value, name1 and name2 are not equal.

const name = 'name';

console.log(Symbol(name) === Symbol(name)); // false

console.log(name === 'name'); // true

Key Benefits of Using Symbols

There are numerous benefits to using Symbols, especially when using them within Objects.

Ensuring Property Uniqueness:
One of the most prominent benefits of Symbols is their role in ensuring property uniqueness within objects. This uniqueness is particularly beneficial in avoiding property name collisions, especially when working with complex implementations or when integrating third-party libraries.

const ID = Symbol('id');

const user = {

[ID]: 123,

name: 'Eric',

email: 'eric@ericfeminella.com'

};

console.log(user[ID]); // 123

Symbol Properties are Not Enumerated:
Another advantage of Symbols is that properties keyed by Symbols are not enumerated in for...in, or Object.keys(), Object.values(), or Object.entries(). This characteristic can be used to hide certain properties from the enumeration process, thus providing a form of property privacy.

// Outputs 'name' and 'email', but not the Symbol 'id'

for (const prop in user) {

console.log(prop);

}

// Outputs 'name' and 'email', but not the Symbol 'id'

Object.keys(user).forEach(key => {

console.log(key);

});

// Outputs 'Eric' and 'eric@ericfeminella.com', but not the

// Symbol value

Object.values(user).forEach(val => {

console.log(val);

});

// Outputs 'Eric' and 'eric@ericfeminella.com',

// but not the Symbol value

Object.entries(user).forEach(([k, v])=> {

console.log(v, k);

});

Facilitating Meta-Programming:
Symbols play a pivotal role in JavaScript’s meta-programming capabilities. Several well-known Symbols, are used to customize the behavior of certain language constructs. For example, Symbol.iterator allows an object to define its iteration behavior, enabling it to be compatible with both the for...of loop and spread operator.

const collection = {

items: [1, 2, 3],

[Symbol.iterator]: function* () {

for (let item of this.items) {

yield item;

}

};

for (const item of collection) {

console.log(item); // Outputs 1, 2, 3

}

Enhanced Debugging:
Symbols can also aid in debugging by providing a descriptive identifier for otherwise anonymous properties. When you create a Symbol with a Symbol description, this description is shown in debugging tools, making it easier to identify and differentiate between various Symbols.

Concluding Thoughts

JavaScript Symbols present a robust mechanism for ensuring uniqueness, enhancing privacy, and empowering meta-programming within applications. By leveraging Symbols, developers can avoid common pitfalls such as property name collisions and inadvertently exposing internal properties, leading to more secure, maintainable, and sophisticated deigns. As JavaScript continues to evolve, understanding and utilizing Symbols will undoubtedly become an essential skill for modern web developers.

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

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

Simplified Partial Application with ES6

When implementing Partial Application in ES6, implementations naturally become quite easier to reason about as default parameters, rest parameters and arrow functions can be leveraged to provide a much more comprehensive implementation.

While on the surface this may appear insignificant, when compared to having relied almost exclusively on the arguments object and Array.prototype to provide the same functionality in ES5, the benefits become rather apparent.

For instance, consider a simple multiply function which, depending on the arity of the invocation, either computes basic multiplication against the provided parameters, or returns a partial application. That is to say, if invoked as a unary function (single argument), the function returns a partial application (a new function which multiplies by the given argument). If invoked as a variadic function (variable amount of arguments), the function returns the product of the arguments.

In ES5, we could implement such a function as follows:

// basic partial application implementation in ES5 ...

var multiply = function() {

var args = Array.prototype.slice.call(arguments, 0)

, product;

if (args.length > 1) {

return args.reduce(function(acc, curr){

return typeof curr === 'number' && (curr *= acc);

});

}

product = typeof args[0] === 'number' ? args[0] : 0;

return function(n) {return product * n;};

};

View Pen

Given the above example, in order to inspect and iterate over the provided arguments, we need to rely on the Array.prototype, specifically, we need to invoke Function.prototype.call on Array prototype in order to apply the slice method so as to convert the arguments object to an Array. Additionally, we also have to account for a default value of arguments[0] should it be omitted or NaN.

Not only does this require a superfluous amount of code, but it also results in a more complicated implementation that becomes considerably more verbose, and as a result, more difficult to reason about; especially for developers who may not be familiar with the specific mechanisms employed within the implementation.

ES6 to the rescue …

With the introduction of default parameters, …rest parameters, and Arrow Functions (fat arrows) in ES6, the implementation of the above example can be significantly reduced, and as a result, becomes considerably easier to understand, as we can simply re-write the multiply function as:

// basic partial application implementation in ES6 ...

const multiply = (x = 0, ...y) => {

if (y.length) {

return y.reduce((acc, curr) => {

return typeof curr === 'number' && (acc *= curr);

}, x);

}

return typeof x === 'number' && (i => x * i);

};

View Pen

As can be seen, implementing the multiply function in ES6 not only reduces the SLOC by 1/2 of the previous ES5 implementation, but more importantly, by using rest parameters, it allows us to determine and work with the functions arity in a much more natural way. Moreover, both iterating over the provided arguments and returning the partial application becomes considerably more concise simply by using arrow functions, and the need to account for undefined arguments becomes moot thanks to default parameters.

In addition, variadic invocations of such functions can also be simplified considerably using the ES6 spread operator. For example, in order to pass an Array of arguments to a function in ES5, one would need to call Function.apply against the function, like so:

multiply.apply(null, [1, 10, 100]); //1000

With ES6 spread operators, however, we can simply invoke the function directly with the given array preceded by the spread operator:

multiply(...[1, 10, 100]); //1000

Simple!

Hopefully this article has shed some light on a few of the features available in ES6 which allow for writing implementations which not only read much more naturally, but can be written with considerably less mental overhead.

June 1, 2016 Code Review / ES+ / Functional Programming / JavaScript / Refactoring

1 Comment

IIFE in ES6

TL;DR: In ES6, an IIFE is implemented as follows:

(() => {...})();

…
Unlike ES5, which is syntactically less opinionated, in ES6, when using an IIFE, parenthetical order matters.

For instance, in ES5 an IIFE could be written either as:

// parentheses wrap expression and invocation ...

(function() {

}());

… or

// parentheses wrap function expression ...

(function() {

})();

As can be seen in the above examples, in ES5 one could either wrap and invoke a function expression in parentheses, or wrap the function expression in parentheses and invoke the function outside of the parentheses.

However, in ES6, the former throws an exception, thus, one can not use:

(() => {

}()); // Uncaught SyntaxError: Unexpected token

But rather, the invocation must be made outside of the parentheses as follows:

(() => {

console.log('IIFE');

})();

As an aside for those who are curious, the syntax requirements are specific to ES6 and not a by-product of any particular transpilers (i.e. Babel, Traceur, etc.).

April 6, 2016 Code Review / ES+ / Quick Tips / Refactoring

1 Comment

Polymer Behaviors in ES6

Being a typical aspect of Object Oriented Design, inheritance, and mixins, provide the means by which modular reuse patterns can be facilitated within a given system. Similarly, Polymer facilitates code reuse patterns by employing the notion of shared behaviors modules. Let’s take a quick look at how to leverage them in Polymer when using ES6 classes.

Implementing Behaviors

Implementing a Behavior is quite simple, just define an object within a block expression or an IIFE, and expose it via a namespace, or module loader of choice:

'use strict';

(() => {

// define the behavior

const SomeBehavior = {

...

};

// add the behavior to a specific namespace ...

const ns = (window.SomeNamespace = window.SomeNamespace || {});

ns.SomeBehavior = SomeBehavior;

})();

some-behaviors.js

Then, include the behavior in a corresponding .html document of the same name so as to allow the behavior to be imported by subsequent elements:

some-behavior.html

Extending Behaviors

After having defined and exposed a given Behavior, the Behavior can then be extended from element classes by defining a behaviors getter / setter as follows:

'use strict';

// define element class ...

class SomeElement {

beforeRegister(){

this.is = 'some-element';

}

// implement behaviors getter, returning an array of behaviors

// which are to be extended ...

get behaviors() {

return [window.SomeNamespace.SomeBehavior]

}

// implement corresponding setter ...

set behaviors(val) {

this._behaviors = val;

}

Once the behavior has been extended, simply import the behavior in the element’s template (or element bundle, etc.) and it is available to the template class:

<dom-module id="some-element">

...

</template>

</dom-module>

Try it

Implementing Multiple Behaviors

Similar to individual behaviors, multiple behaviors can also be defined and extended:

'use strict';

(() => {

// define first behavior ...

const FirstBehavior = {

properties: {

first: {

type: String,

value: 'First Behavior'

}

};

// add the behaviors to the given namespace ...

const ns = (window.SomeNamespace = window.SomeNamespace || {});

ns.FirstBehavior = FirstBehavior;

})();

first-behavior.js

'use strict';

(() => {

// define second behavior ...

const SecondBehavior = {

properties: {

second: {

type: String,

value: 'Second Behavior'

}

};

// add the behaviors to the given namespace ...

const ns = (window.SomeNamespace = window.SomeNamespace || {});

ns.SecondBehavior = SecondBehavior;

})();

second-behavior.js

In certain cases, I have found it helpful to group related behaviors together within a new behaviors (array) which bundles the individual behaviors together:

'use strict';

(() => {

// define first behavior ...

const FirstBehavior = {

properties: {

first: {

type: String,

value: 'First Behavior'

}

};

// define second behavior ...

const SecondBehavior = {

properties: {

second: {

type: String,

value: 'Second Behavior'

}

};

// define third behavior ...

const ThirdBehavior = {

properties: {

third: {

type: String,

value: 'Third Behavior'

}

};

// define a behavior which bundles the related behaviors ...

const FourthBehavior = [

FirstBehavior,

SecondBehavior,

ThirdBehavior

];

// add the behaviors to a specific namespace ...

const ns = (window.SomeNamespace = window.SomeNamespace || {

'FirstBehavior' : FirstBehavior,

'SecondBehavior' : SecondBehavior,

'ThirdBehavior' : ThirdBehavior,

'FourthBehavior' : FourthBehavior

});

})();

Note: As can be seen in the FourthBehavior, a behavior can also be implemented as an Array of previously defined behaviors.

Extending Multiple Behaviors

As with extending individual behaviors, multiple behaviors can also be extended using a behaviors getter / setter. However, when extending multiple behaviors in ES6, there are syntactic differences which one must take note of. Specifically, the behaviors getter must be implemented as follows:

// define element class ...

class CustomElement {

beforeRegister(){

this.is = 'custom-element';

}

// implement behaviors getter, returning an array of behaviors

// which are to be extended via this._behaviors, or, assigning

// and returning the array of behaviors to be extended should

// this._behaviors be undefined ...

get behaviors() {

const ns = window.SomeNamespace || {};

return this._behaviors || (this._behaviors = [

ns.FirstBehavior,

ns.SecondBehavior,

ns.ThirdBehavior

]);

}

// implement corresponding setter ...

set behaviors(val) {

this._behaviors = val;

}

Try it

And that’s basically all there is to it. Hopefully this article helped outline how Polymer Behaviors can easily be leveraged when implementing elements as ES6 classes. Enjoy.

March 25, 2016 Design Patterns / ES+ / JavaScript / Refactoring

1 Comment