NOTE: This guide is ONLY for devs who don't want to edit their
yarn.lock
file by hand. If you don't care about that please carry on.
So you've pulled the latest master
git checkout master
git pull
// Pair helpers | |
// Map the first element of a pair | |
const first = <A, B, C> (f: A => B, [a, c]: [A, C]): [B, C] => | |
[f(a), c] | |
// Map the second element of a pair | |
const second = <A, B, C> (f: B => C, [a, b]: [A, B]): [A, C] => | |
[a, f(b)] |
// @flow | |
import { curry2, curry3 } from '@most/prelude' | |
export type Except<E, A> = Exception<E, A> | Result<E, A> | |
export const result = <E, A> (a: A): Except<E, A> => | |
new Result(a) | |
export const throwError = <E, A> (e: E): Except<E, A> => | |
new Exception(e) |
NOTE: This guide is ONLY for devs who don't want to edit their
yarn.lock
file by hand. If you don't care about that please carry on.
So you've pulled the latest master
git checkout master
git pull
The desire to create a new language has come from my own experiences in programming in a framework I’ve built, Motorcycle.js and the language TypeScript. Motorcycle is very similar to the more popular project Cycle.js. In my current place of employment we are building a rather large and complex application and we have felt the language barriers of ECMAScript and TypeScript much more than we have the programming patterns we have come to use.
This is, currently, a very informal and non-exhaustive list of things I wish a single programming language would have. This language would likely to be very opinionated, and geared towards functional and reactive web applications. In many ways, but not all, I’d like to see a language designed around the programming patterns of Cycle and Motorcycle.
I hope to develop this language in the future, unless someone else beats me to it! Following this is a
// ==UserScript== | |
// @name Toggl on Trello | |
// @namespace http://tampermonkey.net/ | |
// @version 0.4 | |
// @description Shows toggl entries that match C### where ### is the card number. | |
// @author sdebaun@sparks.network | |
// @match https://trello.com/c/*/* | |
// @match https://trello.com/b/*/* | |
// @require https://gist.github.com/raw/2625891/waitForKeyElements.js | |
// @grant GM_setValue |
Simple state management with xstream
and ramda
, in more transparent fashion than onionify
import * as R from 'ramda'
// first we create factory for making special state stream
// that will hold our stream value and will be modified with supplied streams of reducers
type StateReducer<T> = (state: T) => T
h('div.container', [ | |
h('label.nameLabel', 'Name:'), | |
h('input.myinput', {attributes: {type: 'text'}}), | |
h('hr'), | |
h('h1.greeting', `Hello ${name}`) | |
]) | |
// or | |
div('.container', [ |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent
/** | |
* Fix for vw, vh, vmin, vmax on iOS 7. | |
* http://caniuse.com/#feat=viewport-units | |
* | |
* This fix works by replacing viewport units with px values on known screen sizes. | |
* | |
* iPhone 6 and 6 Plus cannot run iOS 7, so are not targeted by this fix. | |
* Target devices running iOS 8+ will incidentally execute the media query, | |
* but this will still produce the expected result; so this is not a problem. |