es6 - Eric Feminella

Native Data Categorization with Object.groupBy

The introduction of Object.groupBy allows for a streamlined, native approach to organizing collections of data based on user defined criterion; thus simplifying the task of data analysis and categorization without the need for managing third-party dependencies.

Using Object.groupBy

Using Object.groupBy is simple and straight-forward. If you have previously used Lodash groupBy, then you are already familiar with it’s API. Object.groupBy accepts an array and a callback function which defines the grouping logic, and returns an object of groupings based on the callback function’s returned key.

For example, we can group employees by department as follows:

Example 1

const employees = [

{id: 123, department: 'Engineering', name: 'John Doe', doh: '12/22/20'},

{id: 321, department: 'Product', name: 'Jane Smith', doh: '06/12/19'},

{id: 213, department: 'Product', name: 'Fred Jones', doh: '03/13/12'},

{id: 312, department: 'Engineering', name: 'Kim Tyler', doh: '12/19/21'},

];

const departments = Object.groupBy(employees,({department}) => department);

console.log(departments);

// {

// Engineering: [

// {id: 123, department: 'Engineering', name: 'John Doe', ...},

// {id: 312, department: 'Engineering', name: 'Kim Tyler', ...}

// ],

// Product: [

// {id: 321, department: 'Product', name: 'Jane Smith', ...},

// {id: 213, department: 'Product', name: 'Fred Jones', ...}

// ]

// }

In the above example, we see that the provided array can easily be grouped into specific properties, in this case, by department. We can just as easily have grouped the array by any other property as well, such as date of hire (doh) to categories by employee tenure (more on this shortly ).

Indeed, Object.groupBy is particularly useful for grouping collections of objects; however, it is not restricted to objects alone, it can also be used to create grouping primitives as well:

Example 2

const values = [true, false, true, true, false];

const {enabled, disabled} = Object.groupBy(

values, value => value ? 'enabled' : 'disabled'

);

console.log(enabled.length); // 3

console.log(disabled.length); // 2

While the above examples are useful in their own right, the real power of Object.groupBy is revealed when more complex logic is required for determining groupings. For example, we can group the employees array by tenure as follows:

Example 3

const employees = [

{id: 123, department: 'Engineering', name: 'John Doe', doh: '12/22/20'},

{id: 321, department: 'Product', name: 'Jane Smith', doh: '06/12/19'},

{id: 213, department: 'Product', name: 'Fred Jones', doh: '03/13/12'},

{id: 312, department: 'Engineering', name: 'Kim Tyler', doh: '12/19/21'},

];

const groupByTenure = (employees, target) => {

const year = (1000 * 60 * 60 * 24 * 365.25);

return Object.groupBy(employees,({doh}) => {

const tenure = (target - new Date(doh)) / year;

return (

tenure > 1 ? (

tenure <= 2 ? 'development' : 'retention'

) : 'onboarding'

)

})

};

console.log(

groupByTenure(employees, new Date('11/28/22'))

);

// {

// "development": [{

// "id": 123,

// "department": "Engineering",

// "name": "John Doe",

// "doh": "12/22/20"

// }],

// "retention": [{

// "id": 321,

// "department": "Product",

// "name": "Jane Smith",

// "doh": "06/12/19"

// }, {

// "id": 213,

// "department": "Product",

// "name": "Fred Jones",

// "doh": "03/13/12"

// }],

// "onboarding": [{

// "id": 312,

// "department": "Engineering",

// "name": "Kim Tyler",

// "doh": "12/19/21"

// }]

// }

Concluding Thoughts

New features such as Object.groupBy serve to highlight the TC39 Committee’s commitment to providing developers with powerful tools which simplify common tasks. By introducing a native facility for grouping objects, Object.groupBy simplifies overhead and maintainability while also opening up new opportunities for native data aggregation and analysis.

Update: November 28, 2023: Object.groupBy is now currently in Stage 4 status.

Comments Off

The Pipe Operator: A Glimpse into the Future of Functional JavaScript

In the dynamic landscape of JavaScript, the TC39 proposal for the Pipe Operator tends to stand out as an interesting progression in terms of streamlining function composition in a way increases readability, maintainability, and DX.

In this article, we dive a bit deeper into the realms of functional programming in JavaScript, and how upcoming language features such as the Pipe Operator aid in the ability to facilitate a more declarative approach to functional programming.

Understanding the Pipe Operator

At its core, the Pipe Operator, denoted by (|>) introduces syntactic sugar for function composition, allowing developers to pass the result of an expression as an argument to a function. And, while the syntax may appear somewhat unfamiliar at first glance, this seemingly simple language feature harbors some rather profound implications for code clarity and maintainability.

Before diving into some examples, let’s first take a look at how functions are typically composed in JavaScript, and then touch on some of the drawbacks that result from these traditional approaches.

For instance, consider this simple example which demonstrates how one could compose three functions:

Example 1

// utility function to handle nil values ...

const add = (x, v) => v ? v + x : x;

const addA = v => add('a', v);

const addB = v => add('b', v);

const addC = v => add('c', v);

const abc = addC(addB(addA()));

console.log(abc); // "abc"

As can be seen in the above, composing functions together in this manner is cumbersome at best. Moreover, implementations such as this significantly lack in readability as they effectively obscure intent; that is, we simply want to end up with “abc”, but to do so requires an inversion of our thinking.

Of course, we can simplify things quite a bit by implementing a simple compose function (or utilizing a utility library, such as lodash/fp), which we can then leverage for composing functions in a more natural way:

Example 2

// simple generic function composer ...

const compose = (...fns) => v => (

fns.reduce((acc, fn) => fn(acc), v)

);

const abc = compose(addA, addB, addC);

console.log(abc()); // "abc"

With the above implementation, managing the composition of functions becomes easier?-?and we can also defer invoking the function to a later time. Yet, it still leaves much to be desired, especially in terms of maintainability. For instance, should we need to change the composition, the order of arguments must be changed proportionately.

Alternatively, developers may choose to bypass chaining altogether and opt for a temporary variable approach in order to simplify implementation and readability. For example:

Example 3

...

const a = addA(); // 'a'

const ab = addB(a); // 'ab'

const abc = addC(ab); // "abc"

While this is rather subjective, the use of temporary variables arguably creates unnecessary cognitive load as one must follow the order of assignments, and contend with temporary values which, if not implemented as constants, could lead to potential mutations, etc.

Considering the traditional approach to nested function calls which results in a right-ward drift that is challenging to read and understand, the Pipe Operator on the other hand turns this paradigm on its head, so to speak, by enabling left-to-right composition of functions which organically reflects our natural way of thinking and recognizing patterns, as can be seen in the following:

Example 4

const result = expression |> functionA |> functionB |> functionC;

In the above example, expression is the value that is first passed to functionA, the result of which (i.e. the value returned from functionA) is then passed to functionB, and so on until the last function (functionC) returns, at which point the final value is assigned to result. The readability of this approach as compared to traditional function composition is self-evident, reducing cognitive load and making the flow of data much more apparent.

Given the previous examples, with the Pipe Operator, we can now simplify the implementation in a much more natural way:

Example 5

...

const abc = ''

|> addA

|> addB

|> addC;

console.log(abc);

The simplicity and utility of the Pipe Operator results in much more succinct expressions which in turn reduces the mental overhead of reading and understanding the implementations intent.

Practical Applications

The practical applications of the Pipe Operator are vast, as they can be used to simplify compositions for everything from data processing pipelines to event handling flows.

For instance, consider a scenario where we need to process a dataset through a series of transformations. Using the Pipe Operator, we can accomplish this in a simple and concise manner:

Example 6

const items = [

{id: 123, name: 'ABC', meta: {key: '3J454HK7'}},

{id: 321, name: 'XYZ', meta: {key: '6YR7FRHW'}},

{id: 456, name: '', meta: {key: '6YR7FRHW'}}

];

const validate = items => (

items.filter(item => item?.id && item?.name)

);

const enrich = items => items.map(item => ({

...item, title: `[${item.id}] - ${item.name}`

}));

const normalize = items => (

items.map(({meta, ...rest}) => rest)

);

// process items succinctly via pipes ...

const processed = items

|> validate

|> enrich

|> normalize;

console.log(processed);

With the streamlined syntax of the Pipe Operator, both intent and the flow of control become much clearer. In addition, maintainability is vastly improved as we can change the order of the processes with considerably less effort. For example, if we decide we want to enrich the results prior to normalizing, we simply just change the order accordingly as needed:

Example 7

// changing the order of composition is simple ...

const processed = items

|> validate

|> normalize

|> enrich;

As we see, changing the order of invocations is rather simple, thus maintainability is vastly improved.

Expanded Capabilities via Topic References

A particularly intriguing aspect of the Pipe Operator proposal is the inclusion of “Topic References”; a concept which increases expressiveness and the utility of the Pipe Operator by providing direct access to values via a topicToken.

Topic References allow for elegant handling of the current value within the pipeline, using a symbol (currently, %) as a placeholder reference to the value. This feature enables more complex operations and interactions with the piped value beyond that of simply passing the value as an argument to a function.

The main purpose of topic references is to enhance readability and flexibility for use-cases which involve multiple transformations or operations. By using a placeholder for the current value, developers can clearly express operations like method calls, arithmetic operations, and more complex function invocations directly on the value being piped through, without needing to wrap these operations in additional functions.

Consider a scenario where you’re processing a string to ultimately transform it into a formatted message. Without topic references, each step would require an additional function, even for simple operations. With topic references, however, the process becomes much more direct and readable:

Example 8

const usernameInput = ' some.user@domain.com ';

const isValid = true;

const message = usernameInput

|> %.trim()

|> `Username '${%}'`

|> %.concat(isValid ? ' is Available!' : ' already Exists');

console.log(message); // "Username 'some.user@domain.com' is Available!"

One point to note regarding the topicToken is that it has not been finalized, thus the token is subject to change but will ultimately be one of the following: %, ^^, @@, ^, or #. Currently, @babel/plugin-proposal-pipeline-operator defaults to %, which can be configured to use one of the proposed topicTokens.

Through the use of topic references, the Pipe Operator proposal not only adheres to traditional functional programming principles, but also enhances developer experience by allowing for more intuitive and maintainable implementations. Features such as these represents a significant step forward in providing more declarative and expressive patterns in JavaScript.

The Proposal at a Glance

The Pipe Operator proposal is currently in the pipeline for standardization, reflecting a collective effort within the JavaScript community to adopt functional programming paradigms. By facilitating a more declarative approach to coding, this proposal aligns with the language’s evolution towards offering constructs that support modern development practices.

Key benefits of the Pipe Operator include:

Enhanced Readability: Allows for a straightforward expression of data transformations, improving the readability of the code and making it more accessible to developers.
Reduced Complexity: Simplifies complex expressions that would otherwise require nested function calls or intermediate variables, thereby reducing the potential for errors.
A More Functional Paradigm: By promoting function composition, the Pipe Operator strengthens JavaScript’s capabilities as a language well-suited for functional programming.

Concluding Thoughts

As the JavaScript ecosystem continues to evolve, with TC39 proposals such as the Pipe Operator set to play an important role in shaping the future of the language, especially from a functional programming perspective.

While the proposal is still under consideration, its potential to enhance developer experience and promote functional programming principles is most certainly something to look forward to.

(Update: August, 2021, proposal has been moved to Stage 2)

May 22, 2021 ES+ / Functional Programming / JavaScript

Comments Off

Benefits of JavaScript Generators

One of the more nuanced features introduced in ES6 is that of Generator functions. Generators offer a powerful, yet often misunderstood mechanism for controlling the flow of operations, allowing developers to implement solutions with improved readability and efficiency. This article briefly delves into a few of the benefits that JavaScript Generators have to offer, elucidating on their purpose, functionality, and specific scenarios which can benefit from their usage.

Understanding Generators

A Generator function is a special type of function that can pause execution and subsequently resume at a later time, making it quite valuable for handling asynchronous operations as well as many other use cases. Unlike regular functions which run to completion upon invocation, Generator functions return an Iterator through which their execution can be controlled. It is important to note that while generators facilitate asynchronous operations, they do so by yielding Promises and require external mechanisms, such as async/await or libraries, to handle the asynchronous resolution.

Generator Syntax and Operation

Generators are defined with the function keyword followed by an asterisk (*); i.e. (function*), and are instantiated when called, but not executed immediately. Rather, they wait for the caller to request the next result. This is achieved using the Iterator.next() method, which resumes execution until the next yield statement is encountered, or the generator function returns.

function* generatorExample() {

yield 'First';

yield 'Second';

};

// create the generator, then get the values ...

const generator = generatorExample();

console.log(generator.next().value); // "First"

console.log(generator.next().value); // "Second"

console.log(generator.next().done); // true

Generator Iterators

As mentioned, Generator functions return an Iterator, therefore, all functionality of Iterables are available to them, such as for...of loops, destructuring, ...rest parameters, etc.:

function* generatorExample() {

yield 'First';

yield 'Second';

};

// for...of loops

for (const value of generatorExample()) {

console.log(value); // "First", "Second"

}

// array destructuring ...

const items = [...generatorExample(), 'Third'];

console.log(items); // ["First", "Second", "Third"]

// ...rest parameters

const updateItems = (...items) => {

console.log(items);

};

updateItems(...generatorExample()); // "First", "Second"

Custom Iterations

Generators allow for the creation of custom iteration logic, such as generating sequences without the need to pre-calculate the entire set. For example, one can generate a Fibonacci sequence using generators as follows:

function* fibonacci(limit) {

let [previous, current] = [0, 1];

while (limit-- > 0) {

[previous, current] = [current, previous + current];

yield current;

}

};

// each iteration yields the next number in the sequence ...

for (const num of fibonacci(6)) {

console.log(num); // 1, 2, 3, 5, 8, 13

};

Stateful Iterations

Generators have the ability to maintain state between yields, thus they are quite useful for managing stateful iterations. This feature can be leveraged in scenarios such as those which require pause and resume logic based on runtime conditions. For instance:

const gameState = function*() {

let gameOver = false;

let score = 0;

while (!gameOver) {

// receive, increment, and yield the updated score

// here, the "score" that is yielded is a reference

// to the value passed to .next

gameOver = (score += yield score) >= 10;

}

return 'Game Over'; // return 'Game Over' when the loop ends

};

// create the game generator ...

const game = gameState();

// starting the game, the first call initializes the game

// and returns the initial score ...

console.log(game.next().value); // 0

// simulate score increments ...

console.log(game.next(1).value); // 1

console.log(game.next(2).value); // 3

console.log(game.next(3).value); // 6

console.log(game.next(4).value); // "Game Over"

// subsequent calls will continue to return undefined as

// the game has completed ...

console.log(game.next(10).value); // undefined

console.log(game.next().done); // true

It may initially seem confusing as to how the value passed to game.next(value) is referenced within the Generator function. However, it is important to understand how this mechanism works as it is a core feature of generators, allowing them to interact dynamically with external input. Below is a breakdown outlining this behavior in the context of the above example:

Starting the Generator: When game.next() is first called, the gameState generator function begins execution until it reaches the first yield statement. This initial call starts the generator but does not yet pass any value into it, as the generator is not yet paused at a yield that could receive a value.
Pausing Execution: The yield statement pauses the generator’s execution and waits for the next input to be provided. This pausing mechanism is what differentiates generators from regular functions, allowing for a two-way exchange of values.
Resuming with a Value: After the generator is initiated and paused at a yield, calling game.next(value) resumes execution, passing the value into the generator. This passed value is received by the yield expression where the generator was paused.
Processing and Pausing Again: Once the generator function receives the value and resumes execution, it processes operations following the yield until it either encounters the next yield (and pauses again, awaiting further input), reaches a return statement (effectively ending the generator’s execution), or completes its execution block.

This interactive capability of generators to receive external inputs and potentially alter their internal state or control flow based on those inputs is what makes them particularly powerful for tasks requiring stateful iterations or complex control flows.

Generator Returns

In addition to yielding values with yield, generators have a distinct behavior when it comes to the return statement. A return statement inside a generator function does not merely exit the function, but instead, it provides a value that can be retrieved by the iterator. This behavior allows generators to signal a final value before ceasing their execution.

When a generator encounters a return statement, it returns an object with two properties: value, which is the value specified by the return statement, and done, which is set to true to indicate that the generator has completed its execution. This is different from the yield statement, which also returns an object but with done set to false until the generator function has fully completed.

function* returnExampleGenerator() {

yield 'First';

return 'Finished';

}

const generator = returnExampleGenerator();

console.log(generator.next().value); // "First"

console.log(generator.next()); // {value: "Finished", done: true}

This example illustrates that after the return statement is executed, the generator indicates it is done, and no further values can be yielded. However, the final value returned by the generator can be used to convey meaningful information or a result to the iterator, effectively providing a clean way to end the generator’s execution while also returning a value.

Generators also provide a return() method that can be used to terminate the generator’s execution prematurely. When return() is called on a generator object, the generator is immediately terminated and returns an object with a value property set to the argument provided to return(), and a done property set to true. This method is especially useful for allowing clients to cleanly exit generator functions, such as for ensuring resources are released appropriately, etc..

function* generatorExample() {

yield 'First';

yield 'Second';

}

const generator = generatorExample();

console.log(generator.next().value); // Logs "First"

// terminate the generator early ...

console.log(generator.return('Last').value); // Logs "Last"

console.log(generator.next()); // {value: undefined, done: true}

In this example, after the first yield is consumed, return() is invoked on the generator. This action terminates the generator, returns the provided value, and sets the done property of the generator to true, indicating that the generator has completed and will no longer yield values.

This capability of generators to be terminated early and cleanly, returning a specified value, provides developers fine-grained control over generator execution.

Error Handling in Generators

Generators provide a robust mechanism for error handling, allowing errors to be thrown back into the generator’s execution context. This is accomplished using the generator.throw() method. When an error is thrown within a generator, the current yield expression is replaced by a throw statement, causing the generator to resume execution. If the thrown error is not caught within the generator, it propagates back to the caller.

This feature is particularly useful for managing errors in asynchronous operations, enabling developers to handle errors in a synchronous-like manner within the asynchronous control flow of a generator.

function* errorHandlingGenerator() {

try {

yield 'First';

// error thrown here will be caught by the catch block below

yield 'Second';

} catch (error) {

console.log('Caught error:', error.message);

}

const generator = errorHandlingGenerator();

console.log(generator.next().value); // "First"

// Simulate an error

generator.throw(new Error('Something went wrong'));

This example illustrates how generator.throw() can be used to simulate error conditions and test error handling logic within generators. It also shows how generators maintain their state and control flow, even in the presence of errors, providing a powerful tool for asynchronous error management.

Generator Composition

One particularly interesting feature of Generators is that they can be composed of other generators via the yield* operator.

const generator1 = function*() {

yield 1;

yield 2;

yield 3;

};

const generator2 = function*() {

yield 'One';

yield 'Two';

yield 'Three';

};

const generator = function*() {

yield* generator1();

yield* generator2();

}

// for...of loops

for (let value of generator()) {

console.log(value); // 1, 2, 3, "One", "Two", "Three"

}

The ability to compose Generators allows for implementing various levels of abstraction and reuse, making their usage much more flexible.

Concluding Thoughts

Generators can be used for many purposes, ranging from basic use-cases such as generating a sequence of numbers, to more complex scenarios such as handling streams of data so as to allow for processing input as it arrives. Through the brief examples above, we’ve seen how Generators can improve the way we, as developers, approach implementing solutions for asynchronous programming, iteration, and state management.

August 1, 2019 APIs / ES+ / JavaScript

Comments Off

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.

July 3, 2019 ES+ / JavaScript / Quick Tips / React

Comments Off

Separation of Concerns: propTypes and Immutable.js

When considering the separation of concerns between Container and Presentational Components (stateful / stateless components), I find it useful to leverage the core concepts of these patterns in order to define a clear boundary between where Immutable data types are used, and where raw JavaScript types are referenced exclusively.

By having a clear separation which compartmentalizes where Immutable types are used and where they are not, team members are afforded the ability to easily determine a components propTypes; as, without having a clear cut-off point, one must give thought as to if a prop passed down to a component will be an Immutable object, or not.

It’s no stretch of the imagination to see how this can quickly lead to code which becomes much harder to maintain than it needs to be. As such, the Container / Presentational Component pattern provides a rather natural boundary for separating these concerns.

Unfortunately; however, while such a boundary may seem rather obvious, it may not always be clearly defined, and this tends to lead to overly complex propType declarations.

For instance, on a number of occasions I’ve seen propTypes declared similar to the following:

SomePresentationalComponent.propTypes = {

someList: oneOfType([array, object]).isRequired,

someItem: object.isRequired

}

// or

SomePresentationalComponent.propTypes = {

someList: oneOfType([array, instanceOf(Immutable.List)]).isRequired,

someItem: oneOfType([object, instanceOf(Immutable.Map)]).isRequired

}

// or ...

SomePresentationalComponent.propTypes = {

someList: oneOfType([array, instanceOf(Immutable.List)]).isRequired,

someItem: shape({

id: number,

get: func

})

}

// etc ...

Given the above example, it’s obvious that it was unclear to the original implementor (or current maintainer) of SomePresentationalComponent as to what the expected propTypes will ultimately be. In certain cases, it appears someList could be of type array; whereas, in other cases, it could be of type object (e.g. Immutable.List). Likewise, in some cases someItem could be an object, whereas in others it could be an Immutable.Map.

As you can see, this is obviously problematic and indeed a very good candidate for a bug (not to mention, a maintenance headache indeed).

Moreover, it results in all sorts of unnecessary type check permutations before accessing properties. For example, just to check the length of the list:

const len = typeof(someList.size) !== 'undefined' ? someList.size : someList.length;

// or ...

const len = someList instanceof(Immutable.List) ? someList.size : someList.length;

// or ...

const len = Immutable.Iterable.isIterable(someList) ? someList.size : someList.length;

// or ...

const len = _.isArray(someList) ? someList.length : someList.size;

// etc ...

const len = !_.isUndefined(someList.size) ? someList.size : someList.length;

// etc ...

Likewise, just to get the id of someItem:

const id = someObject.get ? someObject.get('id') : someObject.id;

// or ...

const id = typeof(someObject.get) === 'function' ? someObject.get('id') : someObject.id;

// or ...

const id = _.isFunction(someObject.get) ? someObject.get('id') : someObject.id;

// or ...

const id = !_.isUndefined(someObject.id) ? someObject.id : someObject.get('id');

// etc ...

At best, this is far from ideal, to say the very least …

Now, obviously the developer could simply define a single propType and refactor Containers which are passing an invalid type; however, it may not always be clear what the type should be, if say, the component is being used by multiple applications to which the developer does not have access, and some of those applications are not using Immutable.js, in which case, it would be best to simply disallow Immutable from the component all together and have consumers of the component update their Containers. In any event, it’s symptomatic of a team not having a clear understanding of what kind of components work exclusively with Immutable data types, and which do not.

Solutions

Fortunately, as one might imagine, there are a couple of very simple solutions to this problem:

Only use Immutable types throughout the entire application.
Segment which components use Immutable types, and which do not.

Now, in some cases the argument for Option #1 may very well be a valid one; however, I find Option #2 to be much more feasible (and flexible) as, it helps to ensure Presentational component are kept pure, and that means only using JavaScript types. For my purposes, this is especially important as I have to maintain a shared library which must limit dependencies as much as possible; and some projects are using Immutable, Redux, etc., and some are not. As always – consider the context.

Pros

By having an internal design contract (or convention) which mandates that Container components are only ever to work with Immutable types and, Presentational components are only ever to be passed JavaScript data types, it becomes much clearer to team members where the boundary is defined, and thus, much easier to maintain a large application over time.

Furthermore, it allows less experienced developers to gradually become acclimated with the React Ecosystem by assigning them tasks focused on presentational features. This can be very useful as it only requires knowledge of core concepts without being inundated with additional libraries and APIs. This approach also affords team members with more experience to focus on the more complex portions of the application (application logic, reducers, containers, etc.).

In addition, destructuring, …rest parameters and related ES6 features can be used much more extensively to simplify implementation when using JavaScript types exclusively, helping to ensure Presentational components are kept intentionally “dumb”. Not to mention, in doing so, testing becomes considerably less complex when working with native JavaScript types – and this is equally important when helping newer developers become productive while still getting up to speed.

And, while not always likely, by reducing our dependency on Immutable.js, we position ourselves for a much more easier migration path in the event we decide to swap out Immutable for another library in the future.

Cons

Arguably, one could be justified in the assertion that only Immutable Data types should be used by both Container and Presentational components (Option #1), and indeed that would be a fair argument if you will be calling toJS() frequently when passing props down to Presentational Components (as there is obviously an inherent expense in doing so).

That being said, there is no reason why one would need to call toJS when passing props to Presentational Components as the Immutable API can be utilized to reduce the given props before being passed down to child components. In such cases, a Higher Order Component can be defined for doing either, which can simplify implementation considerably.

Summary

Like most design decisions, there is rarely a one-size-fits-all approach that perfectly solves any given problem, and what ultimately makes sense in one context, may not always be appropriate in another. However, in the context of when and where Immutable types are used, in most cases it is fair to say there should always be a clear boundary defined, regardless of where that boundary must be.

July 25, 2018 Code Review / Design Patterns / JavaScript / React / Refactoring / Software Engineering

Comments Off

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.

October 18, 2017 APIs / Browsers / ES+ / JavaScript

Comments Off