omegahm

#!/usr/bin/env bash

# Colours picked from https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/

###
# Label definitions
###
declare -A LABELS

# Platform

jhorneman

Async data loading in Flux

I've been working with Flux a lot recently, and one of the questions I've been struggling with is in which part of the Flux cycle to put my asynchronous data requests.

Here are some different opinions:

The diagram

The famous Flux diagram puts them in the action creators.

The chat example

jhorneman

How to combine the Flux pattern with large hierarchical data

I've been converting the web client part of an application I'm developing for a client from plain old JavaScript to React and Flux. (Because this is closed-source client work, I will be a bit vague about what the application is and does.)

Something about my data, my use case, and how I've implemented things, or some combination of those three, doesn't fit the Flux pattern well. So I am writing this to explain my problem and hopefully get some interesting feedback on it. (If you're reading this: thanks.)

The application

I have a Python server which talks to a PostgreSQL database and provides data in JSON format over a REST-ish API (not pure REST, more RPC-style).

jsdf

var util = require('util');

// nobody cares about warnings so lets make them errors

// keep a reference to the original console methods
var consoleWarn = console.warn;
var consoleError = console.error;

function logToError() {
  throw new Error(util.format.apply(this, arguments).replace(/^Error: (?:Warning: )?/, ''));

kkemple

module.exports = {
  development: {
    client: 'postgresql',
    connection: {
      port: process.env.DATABASE_PORT,
      host: process.env.DATABASE_HOST,
      database: process.env.DATABASE_NAME,
      user: process.env.DATABASE_USER,
      password: process.env.DATABASE_ACCESS_KEY,
    },

fay-jai

import React from "react";
import { render } from "react-dom";

const ParentComponent = React.createClass({
  getDefaultProps: function() {
    console.log("ParentComponent - getDefaultProps");
  },
  getInitialState: function() {
    console.log("ParentComponent - getInitialState");
    return { text: "" };

subfuzion

Common Options

-#, --progress-bar Make curl display a simple progress bar instead of the more informational standard meter.

-b, --cookie <name=data> Supply cookie with request. If no =, then specifies the cookie file to use (see -c).

-c, --cookie-jar <file name> File to save response cookies to.

skratchdot

// source: http://stackoverflow.com/a/11058858
function ab2str(buf) {
  return String.fromCharCode.apply(null, new Uint16Array(buf));
}

Rich-Harris

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.

iammerrick

import React from 'react';

const MIN_SCALE = 1;
const MAX_SCALE = 4;
const SETTLE_RANGE = 0.001;
const ADDITIONAL_LIMIT = 0.2;
const DOUBLE_TAP_THRESHOLD = 300;
const ANIMATION_SPEED = 0.04;
const RESET_ANIMATION_SPEED = 0.08;
const INITIAL_X = 0;