Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reason React 0.8

github.com

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Reason React 0.8

#71

Post by osdiab »

shermanmccoy wrote: post #62
s-km wrote: post #58

Earlier quoted context omitted.

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.

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.

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!

Re: Reason React 0.8

#72

Post by davesnx »

parhamn wrote: post #3
thegreatpeter wrote: post #2

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 Fun facts about Reason: - exports TypeScript! If you have a TS project and looking f…

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?

There are a few differences between both, a lot of people mention the fast compilation and the type inference.

I would add that the types from Reason are much "smaller" and concise, Option type or Result type and the immutability of Records/Objects creates an environment of safety that I don't have it in TypeScript.

Re: Reason React 0.8

#73

Post by shermanmccoy »

osdiab wrote: post #71
shermanmccoy wrote: post #62

Earlier quoted context omitted.

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.

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!

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.

Re: Reason React 0.8

#74

Post by fulafel »

Scarbutt wrote: post #59
fulafel wrote: post #57

Earlier quoted context omitted.

This meritocratic model is unfortunately not really how language popularity plays out in the real world. At least not on career-length timescales.

Was referring to Facebook usage only, like in, why isn't it used more at FB?

I think the point stands doubly strong in case of Facebook. They're a PHP shop after all.

Re: Reason React 0.8

#75

Post by 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?

Re: Reason React 0.8

#76

Post by davesnx »

cpursley wrote: post #75

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?

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

Re: Reason React 0.8

#77

Post by machiaweliczny »

thegreatpeter wrote: post #27
parhamn wrote: post #3

Earlier quoted context omitted.

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?

1. Pattern Matching Pattern matching has been by far my most favorite feature as someone coming from TypeScript: https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394... The ability to use "constants" that are inherently typed mean less mistakes and a better path forward for handling your application state. Refactoring with this in mind, becomes a lot safer. For example, if I had a reducer that needed a new ac…

Is it possible to compile in presence of errors? I love TS that it's gradual and for prototyping I can use "transpileOnly" and after I'm done I can verify everything. I have bad memories from typing json interfeces for Elm while prototyping (maybe could be disabled).

Re: Reason React 0.8

#79

Post by pkilgore »

machiaweliczny wrote: post #77
thegreatpeter wrote: post #27

Earlier quoted context omitted.

1. Pattern Matching Pattern matching has been by far my most favorite feature as someone coming from TypeScript: https://gist.github.com/peterpme/10840585ddced15a7f4ecd05394... The ability to use "constants" that are inherently typed mean less mistakes and a better path forward for handling your application state. Refactoring with this in mind, becomes a lot safer. For example, if I had a reducer that needed a new ac…

Is it possible to compile in presence of errors? I love TS that it's gradual and for prototyping I can use "transpileOnly" and after I'm done I can verify everything. I have bad memories from typing json interfeces for Elm while prototyping (maybe could be disabled).

No, but you can slowly Reason-ify a javascript (or typescript!) app at the interfaces using gentype[1], which emits javascript/typescript/flow interfaces for the reason side. It works perfectly well to ship a slowly-becoming-reason frontend app.

But you do have to have the compiler give the thumbs up before it will compile the reason side of the project.

You can also checkout the tutorial for slowly converting a single file here, although I find myself doing this sort of thing very rarely: https://reasonml.github.io/docs/en/converting-from-js

[1] https://github.com/cristianoc/genType

Re: Reason React 0.8

#80

Post by pkilgore »

zaphirplane wrote: post #66

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/ and type.d seems like a challenge

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.

Post reply on HN