calebmer

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

calebmer

import {
  Dimensions,
  LayoutChangeEvent,
  Platform,
  ScrollEvent,
  ScrollView,
  StyleSheet,
  View,
} from "react-native";
import {Font, Space} from "../atoms";

calebmer

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>,

calebmer

// 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

calebmer

            ∀(∅) ∀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)

calebmer

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 {}

calebmer

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

calebmer

                          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' }]

calebmer

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

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.