function example(obj: { prop: string | number }): string {
if (typeof obj.prop === 'string') {
mutatesProp(obj);
return obj.prop;
} else {
return "default";
}
/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 calledinfer_ast
)./src/typing/statement.ml
: Most of the inference logic (runs through the AST and generates the initial constraints)
This is a proposal for a lightning talk at the Reactive 2016 conference.
NOTE: If you like this, star ⭐ the Gist - the amount of stars decides whether it makes the cut! You could also Retweet if you want :)
JavaScript is a dynamic language, and there's nothing wrong with that. It allows quick iteration and lowers barriers. However, sometimes some compile-time type checking is just what you need to keep your code in line and give yourself the confidence to build bigger and faster. Flow gives the best of both worlds. You can have normal JavaScript but you can also add types where they're helpful, and it adds zero cost at runtime. In this talk I'll show Flow as it applies to a Redux & React codebase.
This is a strawman proposal for adding pattern matching to ECMAScript. Pattern matching is useful for matching a value to some structure in a similar way to destructuring. The primary difference between destructuring and pattern matching are the use cases involved - destructuring is useful for binding pieces out of larger structures whereas pattern matching is useful for mapping a value's structure to data or a set of behaviors. In practice this means that destructuring tends to allow many shapes of data and will do its best to bind something out of it, whereas pattern matching will tend to be more conservative.
Additionally, the power of pattern matching is increased substantially when values are allowed to participate in the pattern matching semantics as a matcher as well as a matchee. This proposal includes the notion of a pattern matching protocol - a symbol method that can be implemented by objects that enables developers to use those values in pattern matching. A common scenario w
dummy file to create gist |
Examples:
Literals:
{{t 'user.last_name'}}
{{t 'user.email' count=1}}
Placeholders:
<patterndb version='4' pub_date='2010-10-17'> | |
<ruleset name='ssh' id='123456678'> | |
<pattern>ssh</pattern> | |
<rules> | |
<rule provider='me' id='182437592347598' class='system'> | |
<patterns> | |
<pattern>Accepted @ESTRING:SSH.AUTH_METHOD: @for @ESTRING:SSH_USERNAME: @from @ESTRING:SSH_CLIENT_ADDRESS: @port @NUMBER:SSH_PORT_NUMBER:@ ssh2</pattern> | |
</patterns> | |
<examples> | |
<example> |
As configured in my dotfiles.
start new:
tmux
start new with session name: