I no longer mantain this list. There are lots of other very comprehensive JavaScript link lists out there. Please see those, instead (Google "awesome JavaScript" for a start).
function mapValues(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
result[key] = fn(obj[key], key); | |
return result; | |
}, {}); | |
} | |
function pick(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
if (fn(obj[key])) { |
The final result: require() any module on npm in your browser console with browserify
This article is written to explain how the above gif works in the chrome (and other) browser consoles. A quick disclaimer: this whole thing is a huge hack, it shouldn't be used for anything seriously, and there are probably much better ways of accomplishing the same.
Update: There are much better ways of accomplishing the same, and the script has been updated to use a much simpler method pulling directly from browserify-cdn. See this thread for details: mathisonian/requirify#5
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
// Highlights all custom elements on the page. | |
// 7/31/2016: updated to work with both shadow dom v0 and v1. | |
// To create a bookmarklet, use http://ted.mielczarek.org/code/mozilla/bookmarklet.html | |
var allCustomElements = []; | |
function isCustomElement(el) { | |
const isAttr = el.getAttribute('is'); | |
// Check for <super-button> and <button is="super-button">. | |
return el.localName.includes('-') || isAttr && isAttr.includes('-'); |
function SimpleMap() { | |
this._data = {}; | |
} | |
SimpleMap.prototype = { | |
get: function(key) { | |
return this.has(key) ? this._data[key] : null; | |
}, |
#The Shadow DOM Diaries
Feature design is hard, and takes time. With time, it doesn't matter how public and consistent you are with communication during design process. In the end, it all will look like a jumbled mess of emails and bug comments. That seems bad. To make things less bad, I decided to start writing these little docs. Here they are. I may add more. Or not. Whatevs.
Sometimes You Need to Build a Larger Thing First looks back at the road we've traveled.
Shadow DOM Evolution outlines the path forward.
Why Do We Only Allow Children in Insertion Points provides a glimpse into the reasoning behind current insertion point design.
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="utf-8"> | |
<title>Building a router</title> | |
<script> | |
// Put John's template engine code here... | |
(function () { | |
// A hash to store our routes: |
We currently have an on-going design doc walking through our ideal implementation of Yeoman.next - a system of easily composable generators. Given the complexity of that task, we're likely going to need to break that proposal down into several sub-specs/tasks that we gradually introduce as generator system features. This gist is to mostly collect ideas that define how yo.next generators differ from what we have today.
The hope is that definitions will provide us some guidance when it comes to actually prototyping this system.
This gist is meant to help me compile "tips" for getting involved in the standards process. It will be used as a source of material for a talk I'm giving at LXJS in a couple days. The tips are meant to be somewhat tactical, i.e. provide concrete advice for first-timers, and not general sweeping statements about how standards bodies work in the abstract.
If you have any additional tips, please leave them in a comment or email them to me at domenic@domenicdenicola.com, and they'll hopefully make it into my presentation.
As with all new communities you're joining, you'll get better results if you lurk first, both in IRC and on the relevant mailing lists. You'll get to know who's active in what area; what kind of topics are on the group's radar; which issues are contentious; and even basic stuff like how to write emails (prefer plain text, never top-quote).