If you haven't already set your NPM author info, now you should:
npm set init.author.name "Your Name"
npm set init.author.email "[email protected]"
npm set init.author.url "http://yourblog.com"
npm adduser
<html> | |
<head> | |
<script src="https://apis.google.com/js/client.js"></script> | |
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.1/jquery.min.js"></script> | |
<script> | |
function auth() { | |
var config = { | |
'client_id': 'OAUTH_CLIENT_ID', | |
'scope': 'https://www.google.com/m8/feeds' | |
}; |
If you haven't already set your NPM author info, now you should:
npm set init.author.name "Your Name"
npm set init.author.email "[email protected]"
npm set init.author.url "http://yourblog.com"
npm adduser
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:
var Article = require('../../../models/article');
Those suck for maintenance and they're ugly.
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I lead the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can'
// array utils | |
// ================================================================================================= | |
const combine = (...arrays) => [].concat(...arrays); | |
const compact = arr => arr.filter(Boolean); | |
const contains = (() => Array.prototype.includes | |
? (arr, value) => arr.includes(value) | |
: (arr, value) => arr.some(el => el === value) |
import React, { Component } from 'react'; | |
import { createStore, combineReducers, applyMiddleware, bindActionCreators } from 'redux'; | |
import { provide, connect } from 'react-redux'; | |
import thunk from 'redux-thunk'; | |
const AVAILABLE_SUBREDDITS = ['apple', 'pics']; | |
// ------------ | |
// reducers | |
// ------------ |
A lot of people mentioned other immutable JS libraries after reading my post. I thought it would be good to make a list of available ones.
There are two types of immutable libraries: simple helpers for copying JavaScript objects, and actual persistent data structure implementations. My post generally analyzed the tradeoffs between both kinds of libraries and everything applies to the below libraries in either category.
Libraries are sorted by github popularity.
Debounce a function when you want it to execute only once after a defined interval of time. If the event occurs multiple times within the interval, the interval is reset each time.
Example A user is typing into an input field and you want to execute a function, such as a call to the server, only when the user stops typing for a certain interval, such as 500ms.