Live data from Hacker News

Reason React 0.8

github.com

61–70 of 85 posts

Re: Reason React 0.8

#61
post #58

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.

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.

Note that "by default" here means "when strict mode is on, which is explicitly turned on when you run tsc --init". If you don't specify a config value for strict mode, it will be off. (At least last time I checked.)

Re: Reason React 0.8

#62
post #58

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.

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.

Re: Reason React 0.8

#63
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!

Re: Reason React 0.8

#64
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?

It is.

Re: Reason React 0.8

#65
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 asked a similar question recently, one of the maintainers was nice enough to reply with some info. Perhaps this sheds some light: https://news.ycombinator.com/item?id=23116754

Re: Reason React 0.8

#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

Re: Reason React 0.8

#67
post #60

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.

Hey, I recommend sticking to 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.

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.

Re: Reason React 0.8

#68
post #17

Earlier quoted context omitted.

The approach I've been taking is to use ReasonML to model the domain of my application as well as high level components. ReasonML code remains unaware of the styling of the "lower-level" components for the most part, which I write in typescript with styled-components or emotion.

Is there any reason to prefer styled-components over emotion? I did a deep dive on this a few months ago, and found that Emotion supports the same API as SC, while also offering benefits like the `sx` prop, not to mention SSR for "free". It also had a reputation for being faster, but I didn't bother to benchmark it.

SC and the styled API from emotion are identical syntactic-wise and performance-wise. SC used to suffer from performance and big bundle size but these last 2 versions are very balanced. The same way as the sx prop from Emotion it's the css prop from styled-components.

Just to clarify and sell a little my ppx, styled-ppx supports the css prop as well, many people prefer that over the component api.

Re: Reason React 0.8

#69
post #16

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.

I guess this lib would be the closest alternative in a safe statically typed way : https://github.com/davesnx/styled-ppx There's also a nice lib for tailwind : https://github.com/dylanirlbeck/tailwind-ppx

Thanks, let me know if you are using it!

Re: Reason React 0.8

#70
post #10
post #7

Earlier quoted context omitted.

What's the editor support like? TypeScript has industry-leading editor integration with insanely fast response times. I'm always wary of new languages for this reason; I've been burned before by Facebook's own Flow type system.

Reason support in VSCode is very solid.

That's not even true. It's still very early days for Reason VSCode tooling, since you might find a few extensions that support most of the cases but lacks a few key features that you might be used to while writing JS/TS.
Post reply on HN