
Reason React 0.8 - thegreatpeter
https://github.com/reasonml/reason-react/blob/master/HISTORY.md#080-042020
======
thegreatpeter
The long awaited 0.8.0 release from Reason React is out of beta! This includes
a lot of the niceties of writing React but in a very fast, type safe language.

If this is your first time hearing about Reason, watch a video from its
creator (Jordan Walke, creator of React) to learn more:

[https://www.youtube.com/watch?v=5fG_lyNuEAw&t=11s](https://www.youtube.com/watch?v=5fG_lyNuEAw&t=11s)

Fun facts about Reason:

\- exports TypeScript! If you have a TS project and looking for some extra
speed & stability, you don't have to sacrifice type safety interop

\- It powers all of Messenger.com. The team put out a case study where they
went from ~10 bugs a week to less than 10 a quarter by switching to Reason

\- It uses the npm / yarn ecosystem so you can use your favorite / current
packages without looking for something new.

~~~
parhamn
Awesome! Question, say you use TypeScript already, what are the biggest
tangible gains in terms of safety (measured by fewer bugs in production) you
think can be achieved by using Reason?

~~~
yawaramin
\- Full-fledged support for pattern-matching exhaustiveness check, not
something you have to bake together using a 'tag' field. This means if you
match on i.e. integers, the compiler will warn you if you don't include a
catch-all default case.

\- Simple module system where you don't need to deal with named vs default
imports and all the weird bugs getting them mixed up can bring

\- TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting
to type a pair of parentheses:

    
    
        function isSupported(): boolean {
          return false;
        }
    
        function test() {
          console.log(true && isSupported); // true
        }
    

Or doing object/array indexing and forgetting to handle the case of
'undefined' because TypeScript doesn't enforce that. Or how any typings from
before version 2 are suspect because they were written with the assumption
that every type can be implicitly nullable. There are lots of these little
footguns all over the place.

\- Higher-quality bindings: more stuff captured at the type level, you're not
left to deal with bindings full of 'any', 'object', and 'function'

It's not even just about safety though. One of the biggest productivity
drivers in Reason is its iteration speed–the compiler is so fast that you can
try out changes basically as fast as you can save the file. And there are
other things, like how all modules are implicitly available in scope, so you
don't need to manage a 'wall of imports' at the top of every file before you
can actually get to the code itself.

~~~
Kaze404
> TypeScript's inherent JS-like nature can pop up subtle bugs like forgetting
> to type a pair of parentheses

FWIW this was just fixed in TypeScript 3.9.

~~~
yawaramin
Interesting, can you link me?

EDIT: I just tried in the TypeScript Playground (v3.9.2), it's actually rather
worse than I thought, it prints not 'false' but the actual function itself as
a value...

~~~
Kaze404
[https://devblogs.microsoft.com/typescript/announcing-
typescr...](https://devblogs.microsoft.com/typescript/announcing-
typescript-3-9/#uncalled-in-conditionals)

Edit: Apparently the functionality already exists as of 3.7. The update in 3.9
was to add it to ternary operations as well

~~~
yawaramin
Great. But looks like it doesn't work inside a boolean expression.

------
shermanmccoy
For me a big strength is Reason's intolerance of null, this has eliminated a
great number of bugs for me. Reason React ultimately forces you to think about
every permutation of state your component might enter, and develop logic to
handle that. JS/TS will never help you with that.

~~~
s-km
What do you mean? Typescript by default assumes non-null, and if you specify
that something _can_ be null it'll force you to check that it isn't before
attempting to access it.

~~~
shermanmccoy
Sure. However the any type lets the nulls in. And the any type is very
convenient, perhaps even necessary to use in some situations. So then you are
back to plain old js check blocks and ternaries littered everywhere. If you
miss one, well, I don't need to remind anyone of the ubiquitous js console
error which every js developer has burned into the back of her/his brain.

~~~
osdiab
I use the no-explicit-any Typescript ESLint check and tsconfig no-implicit-
any, never turn them off unless absolutely necessary, making this is a non-
issue. Not that I’m not interested in Reason for other reasons though!

~~~
shermanmccoy
That's fine if you can control this configuration I suppose. But the escape
hatch is there, so in my opinion TS doesn't go far enough.

------
bgorman
ReasonML is awesome! I personally preferred the "reducer" state modeling
mechanism from ReasonReact 0.6, but you can still use it as a library with
[https://github.com/bloodyowl/reason-react-
update](https://github.com/bloodyowl/reason-react-update)

~~~
wwewe
I ended up just using redux with react-redux. I just wrote my own bindings
(does not cover the entire api surface but the essentials):
[https://gist.github.com/melbourne2991/b3093187505f2ee9e517bb...](https://gist.github.com/melbourne2991/b3093187505f2ee9e517bbcaa6d52580)

You get a lot of optimizations for free with react-redux. Given reason-react
now supports hooks you can also just use `useReducer` but this lacks some
optimizations.

------
zaphirplane
Assuming most serious projects will depend on a lot of npm modules. Do the
reason folk think that projects will add custom wrappers/typings Just like
with TS (mind share chicken and egg problem) or is there a way for the
compiler with its powerful type system to - handwave - deduce types in
JavaScript npm modules

Edit The gap between [https://redex.github.io/](https://redex.github.io/) and
type.d seems like a challenge

~~~
pkilgore
There is no way, currently, to deduce vanilla javascript types. You'll have to
write your own bindings (types) or as you pointed out, use community bindings
on redex.

Now? Writing a binding is barely a speed bump, but when I first started
writing Reason code it definitely tripped me up a few times. I tried to make
the road behind me a bit smoother [1], but that gap you observed is real.

But as someone who writes/reviews both Typescript and Reason, pretty much
every day, there is space for both projects, so I don't see that gap as being
relevant to the survival of Reason--rather, its something that with hard word
will be improved over time.

------
iddan
I am very pleased to see the revitalized efforts on ReasonML. I hope soon it
will be widespread enough I could use it professionally. Also, I love the new
website design!

------
cpursley
ReasonReact & ReasonML seem like a much more practice Elm.

Can anyone recommend some up to date ReasonReact & ReasonML tutorials & books?

Also, what is the recommended architecture - are there any good starter
projects?

~~~
davesnx
Sure, I worked with Elm before and I feel like they share the basics like
immutability and types. Which makes a lot of sense, since Elm got very
inspired by Haskell and Reason it's a syntax and a few beauties of OCaml.

A good intro (at least for me, since I'm into videotutorials) is
[https://egghead.io/courses/get-started-with-
reason](https://egghead.io/courses/get-started-with-reason).

[https://egghead.io/courses/get-started-with-
reason](https://egghead.io/courses/get-started-with-reason)

------
cosmosocean
Hey there, is there a `styled-components` library for Reason?

I'm really considering ReasonML for my app, however I'm not a big fan of the
styling in reason react.

~~~
JasoonS
Hey, I recommend sticking to bs-css ([https://github.com/reasonml-labs/bs-
css](https://github.com/reasonml-labs/bs-css)). Not because I don't think
styled-ppx is super cool or amazing, but because it's so cutting edge your 99%
chance going to run into an edge case that isn't well accounted for yet (I had
a number of issues when I tried it). bs-css is battle tested today, so if
you're goal is stability, I recommend it first.

~~~
davesnx
Hey JasoonS, I might agree with you, styled-ppx isn't feature complete, would
you mind explaining which edge cases aren't accounted?

I'm doing great progress on it and don't want to miss something that is
crucial for you.

