You are viewing the Articles tagged in browsers

Benefits of JavaScript Generators

JavaScript Symbols

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.

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.

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.

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.:

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:

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:

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

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.

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..

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.

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.

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.

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

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

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.

Unique Identifiers with JavaScript Symbols

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.

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:

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

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.

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.

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.

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.

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.

Property Change Observers in Polymer

When building Web Components the ability to observe property / attribute changes on custom elements and respond to them accordingly can prove quite useful.

Fortunately, Polymer makes this incredibly easy. Let’s take a quick look …
(note, we’ll be using ES6 here)

Single Property Observers

In it’s most basic form, a Single Property Observer can be defined by simply implementing a method and adding it to the property’s observer configuration:

Now, whenever the property changes, Polymer will automatically invoke the observer method; handily passing two arguments: the updated value, and the previous value:

Try it

Pretty cool, right? It gets even better…

Multi-Property Observers

In addition to Single Property Observers, multiple properties can be observed for changes using the observers array:

The observers array is rather self-explanatory: each item is simply a string representation of the method to be invoked with the observed properties specified as arguments:

Try it.

For more information, see multi-property-observers.

Sub-Property Observers

Similar to Multi-Property Observers, sub-properties can be observed as well (e.g. user.username, or user.account.name, etc.). For instance:

Try it

Deep Sub-Property Observers

As with explicit Sub-Property Observers, (n-level) arbitrary sub-properties can be observed using wildcard notation:

Try it.

Both Sub-Property Observers and Deep Sub-Property Observers differ from Single-Property Observers in that a changeRecord is passed to the observer method as opposed to the updated value. A changeRecord is simply an object which contains the following properties (as per the Polymer Docs):

  • changeRecord.path: Path to the property that changed.
  • changeRecord.value: New value of the path that changed.
  • changeRecord.base: The object matching the non-wildcard portion of the path.

It’s important to keep in mind that Sub-Property, and Deep Sub-Property observations can only be made using either property bindings or the set method.

Array Mutation Observers

Complimentary to Single, Multi, Sub, and Deep Property Observers, Polymer provides Array Mutation Observers which allow for observing Array and Array element properties for changes.

This is where the API requires a little getting used to IMHO, and so I would recommend reading the Docs in detail.

That being said, Array Mutation Observers are quite powerful, for example:

Try it.

When observing Arrays, in order for bindings to reflect properly, Polymer’s Array Mutation Methods must be used. This is quite simple in that the API is the same as that of the corresponding Native Array methods, with the only difference being the first argument is the path to the array which is to be modified. For example, rather than: this.items.splice(...) one would simply use: this.splice('items', ...).

Conclusion

Hopefully this simple introduction to Polymer Observers has demonstrated some of the powerful capabilities they provide. Understanding how each can be implemented will certainly simplify the implementation of your custom elements, therefore leveraging them where needed is almost always a good design decision.

Feel free to explore any of the accompanying examples.

Simplifying Designs with Parameter Objects

Recently, while reading the HTML5 Doctor interview with Ian Hickson, when asked what some of his regrets have been over the years, the one he mentions, rather comically so as being his “favorite mistake”, also happened to be the one which stood out to me most; that is, his disappointment with pushState; specifically, the fact that of the three arguments accepted, the second argument is now ignored.

I can empathize with his (Hixie’s) frustration here; not simply because he is one of the most influential figures on the web – particularly for his successful work surrounding CSS, HTML5, and his responsibilities at the WHATWG in general – but rather, it is quite understandable how such a seemingly insignificant design shortcoming would bother such an obviously talented individual, especially considering the fact that pushState's parameters simply could not be changed due to the feature being used prior to completion. Indeed, the Web Platform poses some very unique and challenging constraints under which one must design.

While the ignored pushState argument is a rather trivial issue, I found it to be of particular interest as I often employ Parameter Objects to avoid similar design issues.

Parameter Objects

The term “Parameter Object” is one I use rather loosely to describe any object that simply serves as a wrapper from which all arguments are provided to a function. In the context of JavaScript, object literals serve quite well in this capacity, even for simpler cases where a function would otherwise require only a few arguments of the same type.

Parameter Objects are quite similar to that of an “Options Argument” – a pattern commonly implemented by many JavaScript libraries to simplify providing optional arguments to a function; however, I tend to use the term Parameter Objects more broadly to describe a single object parameter from which all arguments are provided to a function, optional arguments included. The two terms are often used interchangeably to describe the same pattern. However, I specifically use the term Options Argument to describe a single object which is reserved exclusively for providing optional arguments only, and is always defined as the last parameter of a function, proceeding all required arguments.

Benefits

Parameter Objects can prove beneficial in that they afford developers the ability to defer having to make any final design decisions with regard to what particular inputs are accepted by a function; thus, allowing an API to evolve gracefully over time.

For instance, using a Parameter Object, one can circumvent the general approach of implementing functions which define a fixed, specific order of parameters. As a result, should it be determined that any one particular parameter is no longer needed, API designers need not be concerned with requiring calling code to be refactored in order to allow for the removal of the parameter. Likewise, should any additional parameters need to be added, they can simply be defined as additional properties of the Parameter Object, irrespective of any particular ordering of previous parameters defined by the function.

As an example, consider a theoretical rotation function which defines five parameters:

Using a Parameter Object, we can refactor the above function to the following:

Should we wish to remove a parameter from the function, doing so simply requires making the appropriate changes at the API level without changing the actual signature of the function (assuming of course, there are no specific expectations already being made by calling code regarding the argument to be removed). Likewise, should additional parameters need to be added, such as a completion callback, etc., doing so, again, only requires making the appropriate API changes, and would not impact current calling code.

Additionally, taking these potential changes as an example, we can also see that with Parameter Objects, implementation specifics can be delegated to the API itself, rather than client code insofar that the provided arguments can be used to determine the actual behavior of the function. In this respect, Parameter Objects can also double as an Options Argument. For example, should the arguments required to perform a 3D rotation be omitted from the Parameter Object, the function can default to a 2D rotation based on the provided arguments, etc.

Convenience

Parameter Objects are rather convenient in terms of there being less mental overhead required than that of a function which requires ordered arguments; this is especially true for cases where a function defines numerous parameters, or successive parameters of the same type.

Since code is generally read much more frequently than it is written, it can be easier to understand what is being passed to a function when reading explicit property names of an object, in which each property name maps to a parameter name, and each property value maps to parameter argument. This can aid in readability where it would otherwise require reading the rather ambiguous arguments passed to a function. For example:

With Parameter Objects it becomes more apparent as to which arguments correspond to each specific parameter:

As mentioned, if a function accepts multiple arguments of the same type, the likelihood that users of the API may accidentally pass them in an incorrect order increases. This can result in errors that are likely to fail silently, possibly leading to the application (or a portion thereof) becoming in an unpredictable state. With Parameter Objects, such unintentional errors are less likely to occur.

Considerations

While Parameter Objects allow for implementing flexible parameter definitions, the arguments for which being provided by a single object, they are obviously not intended as a replacement for normal function parameters in that should a function need only require a few arguments, and the function’s parameters are unlikely to change, then using a Parameter Object in place of normal function parameters is not recommended. Also, perhaps one could make the argument that creating an additional object to store parameter/argument mappings where normal arguments would suffice adds additional or unnecessary overhead; however, considering how marginal the additional footprint would be, this point is rather moot as the benefits outweigh the cost.

A Look at pushState’s Parameters

Consider the parameters defined by pushState:

  1. data: Object
  2. title: String
  3. url: String

The second parameter, title, is the parameter of interest here as it is no longer used. Thus, calling push state requires passing either null or an empty String (recommended) as the second argument (i.e. title) before one can pass the third argument, url. For example:

Using a Parameter Object, pushState could have been, theoretically, implemented such that only a single argument was required:

  1. params: Object
    • data: Object
    • title: String
    • url: String

Thus, the ignored title argument could be safely removed from current calling code:

And simply ignored in previously implemented calls:

As can be seen, the difference between the two is quite simple: the specification for pushState accepts three arguments, whereas the theoretical Parameter Object implementation accepts a single object as an argument, which in turn provides the original arguments.

Concluding Thoughts

I certainly do not assume to understand the details surrounding pushState in enough detail to assert that the use of a Parameters Object would have addressed the issue. Thus, while this article may reference pushState as a basic example to illustrate how the use of a Parameter Object may have proved beneficial, it is really intended to highlight the value of using Parameter Objects from a general design perspective, by describing common use-cases in which they can prove useful. As such, Parameter Objects provide a valuable pattern worth considering when a function requires flexibility.

Quick Tip: Chrome Developer Tools Shortcut Keys

Sometimes it is the more subtle, less obvious features provided by tools which prove to be surprisingly useful. Interestingly, while such features can save developers considerable time and effort, they are often much less apparent, and thus, occasionally overlooked when compared to their main counterparts.

A noteworthy example of some very simple, yet extremely useful features can be found in just a few of the basic Chrome Developer Tools shortcut keys. Below is a brief description of the most convenient shortcuts I find myself using regularly.

Go to Source (Cmd-O)

Perhaps the most useful short-cut available in the sources panel, Cmd-O allows one to quickly search for a specific source file (thanks to @augiemarcello for this one):
Chrome Developer Tools Command-O

Show Functions (Cmd-shift-O)

Another extremely useful feature in the Sources Panel, Cmd-shift-O displays a list of all functions and their corresponding line numbers within the current source file:
Chrome Developer Tools Command-Shift-O

Clear Console (Cmd-K/)

Clears the console when in focus:
Chrome Developer Tools Command-k

Previous/Next Panel (Cmd-[ / Cmd-])

Toggles between Developer Tools Panels (e.g. Elements, Resources, Network, Sources etc.):
Chrome Developer Tools Command-[]

There are quite a few additional shortcut keys available in Chrome Developer Tools, and Jared has done a excellent job of providing a Devtools cheat sheet. I highly recommend trying some of them out; committing to memory those which you find most useful – and sharing them with others as well.

Configuring iOS HTTP Monitoring

When developing Web Applications for the Mobile Web Experience it is often useful to have a clear view into all HTTP requests and responses sent between the client and server. This is quite simple to accomplish when developing Web Applications for the Desktop as, the browser is running locally so any standard HTTP Monitor will suffice. And, while it is a normal part of a typical development workflow to run an application locally the majority of the time, testing on each target device is obviously an essential part of the process as well.

Luckily, with Charles, on iOS this is quite simple to accomplish.

Configuration

To configure Charles to proxy all requests from an iOS device, simply follow these basic steps:

  1. From your iOS Device, open Settings.
  2. Go to Wi-Fi, select your Network and select the Blue “arrow” icon.
  3. Scroll to HTTP Proxy and select the Manual Button.
  4. In the Server field, enter the IP address of your development machine.
  5. In the port field, enter port 8888 (the default port to which Charles binds).
  6. Leave Authentication set to Off.

And that’s all there is to it. Now, open Mobile Safari and go to your Web Application’s URL (or any page on the web for that matter). On your development machine, in Charles you will receive a prompt with the IP Address of your Mobile Device, click “Allow” and you are all set. When you are done working, make sure to turn off HTTP Proxy on your device.

Additional Note

While this article may be focused on Mobile Web Applications, these same configurations apply to all HTTP traffic from any application on your device that requires resources over the web.