ianmcnally

//@flow
import React, { Component } from 'react'
import type { ElementRef } from 'react'

type Props = { src: string, alt: string }

type State = { source?: string }

export default class LazyImage extends Component<Props, State> {
  state = {}

ljharb

Array Iteration

https://gist.github.com/ljharb/58faf1cfcb4e6808f74aae4ef7944cff

While attempting to explain JavaScript's reduce method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.

Intro

JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it mu

marcysutton

NOTE: This is no longer an experiment! You can use the accessibility inspector in Chrome Devtools now, including a fantastic color contrast inspection tool. Read more: https://developers.google.com/web/updates/2018/01/devtools#a11y

---

Just like any good element inspector helps you debug styles, accessibility inspection in the browser can help you debug HTML and ARIA exposed for assistive technologies such as screen readers. There's a similar tool in Safari (and reportedly one in Edge) but I like the Chrome one best.

As an internal Chrome experiment, this tool differs from the Accessibility Developer Tools extension in that it has privileged Accessibility API access and reports more information as a result. You can still use the audit feature in the Chrome Accessibility Developer Tools, or you could use the aXe Chrome extension. :)

To enable the accessibility inspector in Chrome stable:

renehamburger

'use strict';

/**
 * Javascript version of https://gist.github.com/jbroadway/2836900
 *
 * Slimdown - A very basic regex-based Markdown parser. Supports the
 * following elements (and can be extended via Slimdown::add_rule()):
 *
 * - Headers
 * - Links

ericelliott

Essential JavaScript Links

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

addyosmani

CSS Layout Debugger

A tweet-sized debugger for visualizing your CSS layouts. Outlines every DOM element on your page a random (valid) CSS hex color.

One-line version to paste in your DevTools

Use $$ if your browser aliases it:

~ 108 byte version

jackslocum

/**
 * @author Jack Slocum
 * MIT License
 *
 * Adds support for "listens" config on components.
 * http://jackslocum.com/blog/listens/
 */
Ext.define('xui.mods.Listens', {
    override: 'Ext.Component',

dhoelzgen

class API::V1::BaseController < ApplicationController

  skip_before_filter :verify_authenticity_token

  before_filter :cors_preflight_check
  after_filter :cors_set_access_control_headers

  def cors_set_access_control_headers
    headers['Access-Control-Allow-Origin'] = '*'
    headers['Access-Control-Allow-Methods'] = 'POST, GET, PUT, DELETE, OPTIONS'

betesh

source 'https://rubygems.org'

gem 'activerecord', '~> 3.2.18'
gem 'sqlite3', '= 1.3.5'
gem 'rspec'

DavidFrahm

When you use $resource within a service, you don't need to impose mocking $httpBackend on your controller. If you want tests for the $resource, those should be in the unit tests for the service.

The controller should only test things directly under its control, which means testing the service directly.

The examples below show how to mock a $resource service factory, in the simplest way I could come up with.

TODO:

• These are real-world examples and it might be helpfule to visitors if I removed all the extra junk that isn't directly related to testing $resource.
• Should this be updated to be a better example of utilizing promises?