Fastpack - pack JavaScript fast & easy
This gist is a submission for a lightning talk on the ReactiveConf 2018.
- JavaScript bundling can be a lot faster
- There are proper tools to guarantee consistency
- Writing OCaml code is fun!
This gist is a submission for a lightning talk on the ReactiveConf 2018.
Please 🌟 this gist to vote for this proposal!
No other topic in software development probably has so much controversy as linting.
With a wrong workflow linting can be really a pain and will slow you and your team down. With a proper setup, though, it can save you hours of manual work reformatting the code and reducing the code-review overhead.
/src/parser/spider_monkey_ast.ml
: The type definitions for the AST. Tries to stay very close to ESTree/src/parser/lexer_flow.mll
: The ocamllex lexer logic/src/parser/parser_flow.ml
: The recursive descent JS parser/src/typing/type_inference_js.ml
: Contains the "entry point" for inference (Function called infer_ast
)./src/typing/statement.ml
: Most of the inference logic (runs through the AST and generates the initial constraints)#!/usr/bin/env python | |
import pynvim, os, re, sys, time | |
# Get a list of buffers that haven't been deleted. `nvim.buffers` includes | |
# buffers that have had `:bdelete` called on them and aren't in the buffer | |
# list, so we have to filter those out. | |
def get_listed_buffers(nvim): | |
return set(buf.number for buf in nvim.buffers \ | |
if nvim.eval('buflisted(%d)' % buf.number)) |
This is taken directly from Figure 5.2 in http://nixos.org/~eelco/pubs/phd-thesis.pdf. It is presented here to be more directly linkable.
serialise(fso) = str("nix-archive-1") + serialise1(fso)
serialise1(fso) = str("(") + seralise2(fso) + str(")")
serialise2(type=Regular, exec, contents) =
str("type") + str("regular")
+ (
<ViewList animator> // passes context: { step: 0.555 } | |
<View /> // extends context with { index: 0 } | |
<View /> // ... | |
<View> // extends context with { index: 2 } | |
// here's the tricky part: you can nest ViewLists, and they should pass their "new" context down to their children | |
<ViewList> // reset context { step: 0 } | |
<View /> // reset context { index: 0 } | |
</ViewList> | |
</View> |
{ | |
"env": { | |
"browser": true, | |
"node": true, | |
"es6": true | |
}, | |
"plugins": ["react"], | |
"ecmaFeatures": { |
import { Component } from "React"; | |
export var Enhance = ComposedComponent => class extends Component { | |
constructor() { | |
this.state = { data: null }; | |
} | |
componentDidMount() { | |
this.setState({ data: 'Hello' }); | |
} | |
render() { |
/** @jsx React.DOM */ | |
var Bubbler = React.createClass({ | |
render: function() { | |
return <input type="button" onClick={this.props.onFoo} value="Click me"/>; | |
} | |
}); | |
var Handler = React.createClass({ | |
onFoo: function() { |
While I was experimenting with animation, I had to make a few basic prototypes for a layout system and see how they intertwine. Here's the API in conjunction with React:
var MyComp = React.createClass({
registerLayoutValues: function() {
return {
self: {
width: 30,
left: (get('parent', 'width') - get('self', 'width')) / 2 // Center.
}