Skip to content

Instantly share code, notes, and snippets.

@calebmer
calebmer / Emitter.ts
Last active Feb 27, 2020
Caleb’s Collection of utilities
View Emitter.ts
import queueUncaughtException from './queueUncaughtException';
export default class Emitter<T> {
private readonly _listeners = new Set<(data: T) => void>();
emit(data: T) {
this._listeners.forEach(callback => {
try {
callback(data);
} catch (error) {
View PostVirtualizedComments.tsx
import {
Dimensions,
LayoutChangeEvent,
Platform,
ScrollEvent,
ScrollView,
StyleSheet,
View,
} from "react-native";
import {Font, Space} from "../atoms";
View 00-GroupTable.ts
import {AccountID, GroupID, PostID} from "@connect/api-client";
import {GroupMemberTable} from "./GroupMemberTable";
import {PGTable} from "../pg/PGTable";
import {PGType} from "../pg/PGType";
export const PostTable = PGTable.define({
name: "post",
columns: {
id: PGType.int as PGType<PostID>,
group_id: PGType.int as PGType<GroupID>,
View SQL.ts
// Heavily inspired by my (Caleb’s) old [`pg-sql`][1] module. Updated now that
// I’ve learned a thing or two. Main differences include:
//
// - A more efficient implementation.
// - Symbol stamps to avoid SQL injection attacks using JSON.
//
// Also takes inspiration from Benjie’s fork, [`pg-sql2`][2].
//
// [1]: https://github.com/calebmer/pg-sql
// [2]: https://github.com/graphile/pg-sql2
View proof.txt
∀(∅) ∀b.T b ⊑ ∀b.T b
───────────────────────── (Eq-Free)
∀(∅) ∀(b, b).T b ⊑ ∀b.T b
───────────────────────── (R-Context)
∀(b) ∀b.T b ⊑ T b
─────────────────────────────────────── (I-Context)
∀(b) ∀(a ≥ ∀b.T b).T a ⊑ ∀(a ≥ T b).T a
───────────────────────────────────────────── (R-Context)
∀(∅) ∀(b, a ≥ ∀b.T b).T a ⊑ ∀(b, a ≥ T b).T a
───────────────────────────────────────────── (Eq-Free)
View bad-component.js
function MyComponent() {
// 40 conditions
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
View .bash_profile
export PS1="\[\033[0m\]\W \[\033[00;95m\]❯\[\033[0m\] "
# export EDITOR="code -r"
export CLICOLOR=1
export TERM=xterm-color
function nm_notify_done() {
previous=$?
if [ $previous -eq 0 ]; then
osacript -e "display notification \"Done\" with title \"Node Modules Install\"";
else
View proof.txt
fresh(a') fresh(s')
(row-var) ─────────────────────────────────────────
s ≃ { p: a' | s' } : [s ↦ { p: a' | s' }] q ≠ p a ∉ ftv(a') r ∉ ftv({ q: b | s' })
(row-swap) ─────────────────────────────────────────────────────────────── (uni-varl) ───────────────── (uni-varl) ───────────────────────────────────────
{ q: b | s } ≃ { p: a' | { q: b | s' } } : [s ↦ { p: a' | s' }] a ∼ a' : [a ↦ a'] r ∼ { q: b | s' } : [r ↦ { q: b | s' }]
(uni-row) ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
{ p: a | r } ∼ { q: b | s } : [r ↦ { q: b | s' }, s ↦ { p: a | s' }]
View x.md

In this case, it looks like TypeScript unifies the function type parameters. Flow does not unify function type parameters. Instead Flow defines “bounds” for function type parameters. Which is the more expressive choice when type-checking JavaScript.

Consider the following function:

function choose<T>(a: T, b: T): T {
  return Math.random() > 0.5 ? a : b;
@calebmer
calebmer / 00-notes.md
Last active Dec 8, 2017
Tiny GraphQL Client Ideas
View 00-notes.md

Notes

Principles

  1. The client must help create applications that are very small. This means not only should the runtime be small, but also the query artifacts that will be included in the bundle. Including the entire query AST could be counter to this goal. Other options are only including the query text, or only including a query identifier (persisted queries) in the bundle.
  2. In order to serve the first principle queries must be statically defined outside of JavaScript. GraphQL AST “selection sets” should be transformed into minimal viable data shape representations to inform the client. These transformed “data shapes” can be imported and used by the client.
  3. Static type checking of query data should be a feature of the client and not an afterthought. GraphQL is statically typed after all. Since we are building query files, and importing the built artifcats adding types should be easy.
  4. Data from newer queries must be merged with data from older queries automatically so the UI stays consistent.