When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
| define(function(require) { | |
| var React = require('react'); | |
| var paramRegex = /__(\d)+/; | |
| var parser = new DOMParser(); | |
| var errorDoc = parser.parseFromString('INVALID', 'text/xml'); | |
| var errorNs = errorDoc.getElementsByTagName("parsererror")[0].namespaceURI; | |
| // turns the array of string parts into a DOM | |
| // throws if the result is an invalid XML document. |
This Gist presents a new design of class-based object construction in ES6 that does not require use of the two-phase @@create protocol.
One of the characteristics of this proposal is that subclass constructors must explicitly super invoke their superclass's constructor if they wish to use the base class' object allocation and initialization logic.
An alternative version of this design automatically invokes the base constructor in most situations.
| /** | |
| * performance-timing.js: Polyfill for performance.timing object | |
| * For greatest accuracy, this needs to be run as soon as possible in the page, preferably inline. | |
| * The values returned are necessarily not absolutely accurate, but are close enough for general purposes. | |
| * @author ShirtlessKirk. Copyright (c) 2014. | |
| * @license WTFPL (http://www.wtfpl.net/txt/copying) | |
| */ | |
| (function (window) { | |
| 'use strict'; |
| var webpack = require('webpack'); | |
| var HtmlWebpackPlugin = require('html-webpack-plugin'); | |
| var path = require('path'); | |
| var folders = { | |
| APP: path.resolve(__dirname, '../app'), | |
| BUILD: path.resolve(__dirname, '../build'), | |
| BOWER: path.resolve(__dirname, '../bower_components'), | |
| NPM: path.resolve(__dirname, '../node_modules') | |
| }; |
Some of the most important changes in ES6 involve improved support for the patterns we already commonly use to organize JavaScript functionality. This chapter will explore Iterators, Generators, Modules, and Classes.
An iterator is a structured pattern for pulling information from a source in one-at-a-time fashion. This pattern has been around programming for a long time. And to be sure, JS developers have been ad hoc designing and implementing iterators in JS programs since before anyone can remember, so it's not at all a new topic.
What ES6 has done is introduce an implicit standardized interface for iterators. Many of the built in data structures in JavaScript will now expose an iterator implementing this standard. And you can also construct your own iterators adhering to the same standard, for maximal interoperability.
| var EventSystem = (function() { | |
| var self = this; | |
| self.queue = {}; | |
| return { | |
| publish: function (event, data) { | |
| var queue = self.queue[event]; | |
| if (typeof queue === 'undefined') { |
| class Dog { | |
| @deprecated('Dogs don\'t roar, they talk.') | |
| roar() { | |
| console.log('RRRRR'); | |
| } | |
| @deprecated() | |
| smile() { | |
| console.log('smile'); | |
| } |
| /** | |
| * Callable objects in ES2015. | |
| * by Dmitry Soshnikov <[email protected]> | |
| * MIT Style License | |
| */ | |
| class Callable extends Function { | |
| constructor() { | |
| super('(' + Callable.prototype.__call__ + ')();'); | |
| return this.bind(this); |
| /* | |
| ##Device = Desktops | |
| ##Screen = 1281px to higher resolution desktops | |
| */ | |
| @media (min-width: 1281px) { | |
| /* CSS */ | |
