Thanks to Hurricane Matthew raining down on Colombia, I’m forced to do something productive with my time. So naturally, I’ve been thinking about type systems, specifically for . Flowtype JavaScript Our team have been using Flow types for some time at Red Badger and we’ve seen some real benefits. Namely, more robust code that is easier and safer to refactor, and significant productivity gains thanks to excellent tooling with the Nuclide IDE (thanks Facebook!). Without engaging in the static vs. dynamic typing debate, I believe provides an excellent balance of confidence vs. flexibility. I’ve seen it work effectively on a large (and important) JavaScript codebase. gradual typing Inspiration Yesterday I watched an excellent Strangeloop talk on : clojure.spec Stuart Halloway’s Talk on clojure.spec For those unfamiliar, it’s a specification language for the dynamically typed language Clojure. It allows developers to specify the shape of some data a function expects, and specify some invariants that should be satisfied before or after execution. It seems somewhat inspired by and there are some definite overlaps with the kind of guarantees provided by a . design by contract type system However — the powerful idea behind is that enforcement of these specifications is completely left up to the developer. Albeit aided by some built in utility functions. For this to work, the specifications must be available clojure.spec at runtime. Statically typed languages commonly only make usage of type information at . Yet, languages such as C# and Java have also had mechanisms for accessing type information at runtime, as part of a “ for a long time**.** compile time Reflection API”, To bring some of the ideas from to JS, I set about building a similar feature for Flowtyped JavaScript. core.spec Exposing Flowtypes at Runtime Flow is written in OCaml, not JavaScript, and type checking happens in the Flow process during development. This means type information is not accessible from JavaScript. Furthermore, users of Flow normally run their JS code through Babel, where removes any annotations and outputs executable code. In order to retain type information, we can instead replace this plugin with a small transform library I wrote for this purpose**.** flow-strip-types flow-runtime-types, exposes the AST of our Flow annotations to runtime code, we can then interpret this AST to build some interesting features. flow-runtime-types The AST looks like this: Quite simple to understand, and low level enough to build some tooling that takes advantage of it. Use Cases Type Conformance Validation At the edges of any system, type checked or otherwise, it is necessary to implement validation logic to ensure data is in the correct shape. When using Flow, encoding these rules once as part of the type system, and again as part of executable code can feel redundant. Instead, we could utilise the Flow annotations AST to produce automatic runtime validation of the data. I chose to convert the flow types into a Joi schema object ( ) so validation can be handled by a battle tested library. For example, using the above type definitions: https://github.com/hapijs/joi This doesn’t mean we can remove all other validation logic, as there is no way to encode arbitrary constraints (e.g. the max length of a string) in Flow. It does however save us from the tedium of structural validation, so we can instead focus on validating the of the data. semantic meaning I’ve implemented this as a proof of concept for primitive and generic types in Flow, and it seems to work effectively. We could certainly also use this approach to completely replace runtime in React components. propType validation Generating test cases for property-based/unit tests We can also use the Flow AST to generate valid fixtures to use in unit or property based tests. Usage as follows: We can execute this function many times over to produce random, but valid, output for our system. We can then directly use this in or (as seen in tools such as ) when applied to UI . property based tests fuzz testing https://github.com/carteb/carte-blanche programming Limitations & Improvements One limitation of this approach is that runtime introspection is only available for One of the major benefits of Flow is type inference. Addressing this limitation could take one of the following approaches: explicit type declarations. Request typed AST information from Flow via the CLI with the ` — json` flag. This type of integration is used by Nuclide and other tools. The specific call needed to make this work doesn’t yet exist, but is being discussed at . https://github.com/facebook/flow/issues/248 Compile Flow (OCaml) into JS. This is theoretically possible with a tool like and would open up many other integration opportunities, but seems like a of work. If possible, this would also mean that we could directly use Flow’s model of the type system rather than re-implementing our own weaker form in JavaScript. https://github.com/ocsigen/js_of_ocaml lot Related Projects https://github.com/codemix/babel-plugin-typecheck https://github.com/gcanti/babel-plugin-tcomb Interesting? Can you think of any other use cases for runtime type introspection? Or an easier way to achieve it? A proof of concept is available here on GitHub, not yet distributed to NPM: _babel-transform-flow-introspection - Rough PoC for exposing Flowtype annotations to runtime code_github.com JoeStanton/babel-transform-flow-introspection is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
