Skip to content

Instantly share code, notes, and snippets.

View joshblack's full-sized avatar

Josh Black joshblack

View GitHub Profile
@jeffmo
jeffmo / a.md
Last active October 3, 2016 16:38

A few reasons why we decided to build Flow

tldr: Flow is built to find a lot more kinds of bugs than what TypeScript is built for.

Flow avoids as much gratuitous unsoundness as possible in order to find more bugs: It never infers any, it models variance for objects/functions/type parameters soundly (this is critical), it minimizes type precision loss, it has sound support for various dynamic features with inference (Function.prototype.bind()/Function.prototype.call()/Object.assign()/etc), etc.

Flow infers and understands more kinds of types with fewer annotations. Extensive inference was important to us for easing the process of converting untyped code without missing errors as much as possible. It also helps reduce boilerplate when writing new, typed code. You get to decide if and when you want to express types in your code (with type annotations), but Flow will pick things up from there without much worry of losing type info.

Flow is built on top of a more general level of code understandi

@steveluscher
steveluscher / graphql-js-migration-guide.md
Last active September 26, 2016 13:01
GraphQL 0.6.0 migration guide

GraphQL 0.6.0 migration guide

This version of graphql-js introduces a breaking change to the method signature of the resolve() method.

Previously, resolve() had this method signature:

type GraphQLResolveInfo = {
  fieldName: string,
 fieldASTs: Array,

Why I think Webpack is the right approach to build pipelines

(I've reposted this on my blog, which you may find more pleasant to read: http://devlog.disco.zone/2016/06/01/webpack/)

I was asked on Twitter why I think Webpack is the right approach to build tooling in JavaScript applications. My explanation is, uh, a bit longer than fit in a single tweet.

When I say "right approach," I'm specifically talking about the way Webpack's pipeline functions. There are certainly some deficiencies in various aspects of Webpack: it has a rather unintuitive API, and often requires quite a bit of boilerplate to set up. However, even with these issues, I think the core principles of how Webpack functions are sound.

I should also mention here this argument basically applies to SystemJS as well. I'm skeptical of various aspects of SystemJS, but I've only taken a very surface-level look at it, so I'm gonna withhold judgement until I've had a chance

import React from 'react'
const provideContext = (contextKey, contextType) => (
React.createClass({
childContextTypes: {
[contextKey]: contextType
},
getChildContext() {
const { children, ...props } = this.props

architectures and whatnot

  1. plain ol' React
let state = initial
render(view(state), element)
  • view is pure!
@idibidiart
idibidiart / GraphQL-Architecture.md
Last active September 16, 2023 18:36
Building an Agile, Maintainable Architecture with GraphQL

Building a Maintainable, Agile Architecture for Realtime, Transactional Apps

A maintainable application architecture requires that the UI only contain the rendering logic and execute queries and mutations against the underlying data model on the server. A maintainable architecture must not contain any logic for composing "app state" on the client as that would necessarily embed business logic in the client. App state should be persisted to the database and the client projection of it should be composed in the mid tier, and refreshed as mutations occur on the server (and after network interruption) for a highly interactive, realtime UX.

With GraphQL we are able to define an easy-to-change application-level data schema on the server that captures the types and relationships in our data, and wiring it to data sources via resolvers that leverage our db's own query language (or data-oriented, uniform service APIs) to resolve client-specified "queries" and "mutations" against the schema.

We use GraphQL to dyn

if (typeof Promise === 'undefined') {
require.ensure([], (require) => {
require('imports?this=>window!es6-promise')
})
}
if (typeof fetch === 'undefined') {
require.ensure([], (require) => {
require('imports?self=>window!whatwg-fetch')
})
// " In short, the closer the code is to a description of “what I want the program to do”, the better."
// http://staltz.com/why-react-redux-is-an-inferior-paradigm.html
////////////////////////////////////////////////////////////////////////////////
// Cycle
import {Observable} from 'rx';
import Cycle from '@cycle/core';
import {div, button, p, makeDOMDriver} from '@cycle/dom';
function main({DOM}) {
import React from 'react'
const { number, func, array, shape } = React.PropTypes
export default React.createClass({
propTypes: {
itemHeight: number.isRequired,
renderItem: func.isRequired,
items: array.isRequired,
let rootValue = {
response: {
timing: {
fields: []
}
}
}
const start = new Date().getTime();
return graphql(schema, query, rootValue, variables).then(response => {