Skip to content

Instantly share code, notes, and snippets.


Block or report user

Report or block busypeoples

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
busypeoples / SmallFormValidation.js
Last active Apr 30, 2019
Small Validation Library
View SmallFormValidation.js
const { converge, mergeAll } = require("ramda");
// Small validation function...
const validate = (validations) => {
return converge((...results) => mergeAll(results), validations);
// Validators
const isGt4 = x => x > 4;
const isGT8 = x => x > 8;
busypeoples / InferProps.tsx
Created Mar 9, 2019
Infer Props using PropTypes.InferProps
View InferProps.tsx
import React from "react";
import { render } from "react-dom";
import PropTypes from "prop-types";
// Using PropTypes.InferProps
type InferPropTypes<
DefaultProps = {},
Props = PropTypes.InferProps<PropTypes>
busypeoples / TypeScriptFundamentals.ts
Last active May 19, 2019
TypeScript Fundamentals For JavaScript Developers
View TypeScriptFundamentals.ts
// TypeScript Fundamentals For JavaScript Developers
Tutorial for JavaScript Developers wanting to get started with TypeScript.
Thorough walkthrough of all the basic features.
We will go through the basic features to gain a better understanding of the fundamentals.
You can uncomment the features one by one and work through this tutorial.
If you have any questions or feedback please connect via Twitter:
A. Sharif :
busypeoples / Match.js
Created Jan 9, 2019
Pattern Matching Functionality
View Match.js
// Modelled after Ramda's Cond function
const match = <T, U>(
conditions: [(i: T) => boolean, (i: T) => U][],
data: T
): U | undefined => {
return conditions.reduce((result: U | undefined, [predicate, transformer]) => {
if (result) {
return result;
busypeoples /
Last active Mar 5, 2019
Declarative Style Definitions Pt.1

Declarative Style Definitions Pt.1

** Note: This is a first try at understanding the topic better. Not an expert in styling or design. The following write-up is a collection of ideas from people that have been thinking about the topic for a very long time: Brent Jackson, Adam Morse, Michael Chan, Jon Gold, Sunil Pai and many more. **

When building UIs, we mostly have a good grip of the very initial requirements. We choose tools and concepts around these requirements and implement a UI resembling the initial definition. But overtime these requirements start to evolve. More features or changes to the initial definition require changing parts of the application, sometimes even more than just small refactorings and rewrites. Most of the UI work tends to be a repetition of existing solutions but with explicit requirements that don't align with alre

busypeoples /
Last active Sep 15, 2019
Monolithic Components, Composable Components

Monolithic Components, Composable Components


Building reusable UI components is a non trivial task, as we need to anticipate a number of things when planing for reuseability. On the one end of the spectrum we want to enable customization and on the other side we want to avoid developers doing the wrong thing, like breaking the component or displaying invalid states.

To get a better understanding of what we need to think about and consider upfront, we will build a non-trivial UI component, that displays tags. Our Tags component will take care of managing and displaying tags.

The following examples are all built with Tachyons and React, but these ideas apply to any UI component and any general styling approach.

busypeoples /
Last active Jun 22, 2019
Making unrepresentable UI representations unrepresentable!

Making Unrepresentable UI Representations Unrepresentable!

When building components, we mostly start out with a minimal API, as we mostly have a clear initial idea of what the Component should do. But as requirements start to change, our API might start to evolve a long the way too. We start adding more props to cover conditional or special cases etc. Sometimes we use optional props, as in not required, or we might start using flags, as in boolean props or enums, to handle variants. Let's take a closer look at optional props and what effects these can have on our UI representation.

Optional props

busypeoples / diff.js
Last active Nov 16, 2018
Diff 2 items and group into (toCreate, toUpdate, toDelete)
View diff.js
import { find, filter, propEq, reject } from "ramda";
const findFn = (key, selectedItem, items) =>
find(item => item[key] === selectedItem[key], items);
const diff = (nextItems, currentItems, key, diffFn) => {
const toCreate = reject(
item => item[key] && findFn(key, item, currentItems),
busypeoples /
Last active Jul 31, 2018
Data Structures in ReasonML: #9 Queue
/* Queue */
/* FIFO: First In First Out*/
exception Empty;
module type Queue = {
type queue('a) = list('a);
let create: unit => queue('a);
let add: ('a, queue('a)) => queue('a);
let delete: queue('a) => queue('a);
let peak: queue('a) => 'a;
busypeoples /
Last active Nov 18, 2019
Data Structures in ReasonML: #8 Graph
/* Graph */
exception Not_found;
type nodes = list(int);
type edges = list((int, int));
type graph =
| Empty
| Graph(nodes, edges);
You can’t perform that action at this time.