What's so great about Reason?

PDXReactJS meetup / 13. Nov 2018 @benjamminj

Maintainability?

We want to make complex problems simple, and solve them in ways we can extend on.

JavaScript v. ReasonML:

Task	JavaScript	ReasonML
Lint	via Tooling (e.g. ESLint)	Compiler warnings (it's impossible to ship "unlinted" code)
Format	via Tooling (e.g. Prettier)	reformat is built in
Immutability	via Tooling (e.g. ImmutableJS)	by default. With some "mutable" niceties for imperative code
Utilities	via Tooling (Lodash / Ramda)	OCaml/BuckleScript standard library
Types	via Tooling (TypeScript / Flow)	yep.
Tests	via Tooling (Jest, Mocha, Enzyme, React Testing, etc)	left to userland

At least 6-10 tools for a project. Lots of them are cool. But that also means juggling lots of documentation, lots of different configurations. Decision fatigue is a real thing.

What does Reason give us?

Focus on why: why it's cool, worth using. What's reason?

• A syntax and toolchain for OCaml
• OCaml is an old, statically typed, functional language. It's been around for a while.
• Reason hasn't. Created by Jordan Walke (React creator) a few years back
• OCaml behavior is similar to JS in how it works. Not how it looks, but how it works

Remember that list of JS Tools? (Revised above)

Aside: types aren't tests

Q: Do I really need types when I can write unit tests for everything? No, but you don't want to write a test for every datatype flowing through your function.

Q: And tests, if I have types? No, as long as you don't have any business logic. A type-checker won't tell you if calculations are right, or if you added to the front of an array when you should have added to the end of the array.

More, ahem, Reason/s

Pragmatism over Dogma. Reason (OCaml) likes functional programming, but you can still write for loops, mutable references, etc. A very functional language (e.g. Haskell) can obstruct what you're trying to do (ultimately, deliver value to your users). Reason isn't that.

Reason can compile for native (via various? experimental? OCaml backends), web (via BuckleScript--optimizing compiler targeting JS).

Syntax isn't too far off JavaScript (one of Reason's goals was opening the OCaml ecosystem to JS devs). Syntax is terse and light on types--the compiler can infer a lot of stuff.

Workflow, same: still via npm.

Interop with the JS world?

Write external declaration.

Some examples

• List (immutable) - Linked list under the hood
• Array (mutable) - Slightly more awkward syntax, sometimes convenient
• Record - Sort of like a JavaScript object (with a type definition separate from the declaration)
• Variant - Union type, but branches can take arguments
• Pattern matching - Variants lend themselves well to matching, but you can match over all sorts of things. And if you forget to match elements in an array, you'll get a warning!

ReasonReact

Stateless components are easy: declare a make factory function. Otherwise it looks a lot like React.

• JSX is built-in as a language macro. Some small changes (don't need curly-braces to escape params, or assignment of attributes that match variable names)

State_ful_ components are created with the reducerComponent generator and another make.

• Reason doesn't have this, but can reference an explicit self. Use self.send() to pass actions back to the component reducer

• Reason is production-grade, but it's still early. OCaml is well-established; community around ReactReason is still figuring things out (you might spend some time digging through the docs to find answers for yourself).

• Definitely ready for a side project! Or converting some utility functions over.