Skip to content

Instantly share code, notes, and snippets.

Charles Lowell cowboyd

Block or report user

Report or block cowboyd

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
cowboyd / structured-tns.js
Created May 1, 2019
What starting the application on NativeSript ought to look like using structured concurrency.
View structured-tns.js
import { launchSimulator, webpack, xcodeBuild, installApp, waitForRemoteAgent } from "tnx";
import { call } from '@microstates/effects';
function* start() {
let launch =; // happens in parallels
let server = yield webpack(); //build the webpack code
yield xcodeBuild(); // build the iOS app
cowboyd / bluetooth-controller.ts
Created May 1, 2019
A more fluent, generator based syntax for structured effects.
View bluetooth-controller.ts
import ble from "~/system/ble";
import { until, wait } from '@microstates/effects';
import Bluetooth from "~/bluetooth/bluetooth.model";
export function* controlBluetooth(bluetooth: Bluetooth) {
this.when(bluetooth => bluetooth.isOn, function*() {
while (true) {
yield until(bluetooth, { scan: { isRequested: true } });
cowboyd / microstates.d.ts
Created Apr 26, 2019
Microstate relationship bindings
View microstates.d.ts
declare module "microstates" {
interface Cell<Type> {
Type: Constructor<Type>;
value?: any;
interface Edge<Parent> {
value: any;
parent: Parent;
cowboyd / bundle.js
Last active Mar 27, 2019
Built assets resulting from a run of `tns test ios` on the `cl/blueteeth` branch of the application:
View bundle.js
module.exports =
(global["webpackJsonp"] = global["webpackJsonp"] || []).push([["bundle"],{
/***/ "../node_modules/nativescript-unit-test-runner sync recursive (root|page)\\.(xml|css|js|ts|scss)$":
/***/ (function(module, exports, __webpack_require__) {
var map = {
"./app-root.xml": "../node_modules/nativescript-unit-test-runner/app-root.xml",
"./bundle-app-root.xml": "../node_modules/nativescript-unit-test-runner/bundle-app-root.xml",
"./bundle-main-page.js": "../node_modules/nativescript-unit-test-runner/bundle-main-page.js",
cowboyd / uploader-controller.js
Created Feb 14, 2019
Hypothetical effects API for microstates
View uploader-controller.js
import { act, every } from '@microstates/effects';
* An effects function matches the state emitted by the store using
* the specified patterns. For every time the pattern is recognized,
* execute the callback with the matching object.
* This particular effects function recognizes every upload that is
* brand new and initiates the XHR, and also every upload that has
* been cancelled by the user and aborts it.
View App.js
import React, { Component } from 'react';
import Store from './store'
import Uploader from './uploader';
import UploaderController from './uploader-controller';
import { valueOf } from 'microstates';
import { append } from 'funcadelic';
import 'react-json-pretty/themes/monikai.css';
import JSONPretty from 'react-json-pretty';
cowboyd /
Created Jan 30, 2019
Outline for a blog post on "Why BigTest?"
  • Theoretically, what does the perfect test look like? Obviously, the perfect test doesn't actually exist, any more than an ideal gas, or a perfect sphere BUT if it did, what properties would it have?
    • It would verify all the things. And by all the things, literally all the things
    • every user interaction,
    • every workflow,
    • every browser
    • every level of user ability
    • every possible combination and sequence of events in the system.
    • Such a perfect test would have an incredible impact in terms of saving our team cost by ensuring that no bugs escaped to production, and that our products worked all the time, every time, for every one.
    • with the concept of a perfect test as a maximum, we could write every test on a spectrum, from a throw-away test, up to the theoretical limit implied by our our "perfect" test.
View state.js
* Model stateful computations (those that return a result, but also
* have the side effect of altering some shared context).
* Each stateful computation, is a function that takes a current
* state, and returns two values, the result, `r`, and the new shared
* state `s'`.
* In other words, a function `s => [r, s']`
* The State monad allows you to compose these effectful computations
cowboyd / a-question-for-state-machines-in-stores.js
Last active Jan 18, 2019
Show diffferent ways to model state changes in a store with persistent identities
View a-question-for-state-machines-in-stores.js
import { valueOf } from 'microstates';
* When modelling side-effects, you generally listen to the output of a
* `Store`, and then conditionally trigger state transitions based on
* some sequence of events. The references that the store generates
* are "smart" in the sense that they really represent a "path" into
* the central datastructure of the store. In that way, the same
* reference, can be used again and again and never become stale,
cowboyd / field.js
Last active Jan 15, 2019
A very, very rough draft of a custom field to perform validations on its input. (has not been tested)
View field.js
* A higher-order microstate that takes a validation function, and returns
* a field class that validates the input of that field based on inputs.
export function Field(validationFn) {
return class Field extends String {
get validation() {
return validationFn(valueOf(this));
get hasErrors() {
You can’t perform that action at this time.