Comment by acemarke | Hacker News Reader

Comment by acemarke | Hacker News Reader

Hmm. So, the complaints about React are "no convention over configuration", "we didn't like JSX", "event handlers require binding for `this`", and "trouble finding a correct source of truth" for articles and such.

The first two are pretty common. Some people _love_ that React lets you pick and choose the other pieces that you need for your own application, while others hate that React isn't a kitchen-sink-provided framework like Angular. (Relevant HN comment from a while back on "frameworks vs libs": https://news.ycombinator.com/item?id=10969819 ). Ditto with JSX - some people love that it's almost exactly the same syntax as HTML, while others hate the idea of having anything HTML-like in their components or dislike that it does have a few minor differences from actual HTML syntax.

The event handler complaint I find a bit more odd. Admittedly, I never got too deep into "vanilla JS" or jQuery, so I haven't spent too much time writing non-React event handlers, but having to bind methods is very much an artifact of how `this` works in Javascript (especially with classes) and not specific to React.

As for a "correct source of truth", well, I have that covered :) I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.

Agreed. The main complaint is just "I want a framework and I chose a library."

JSX isn't even required either. It just desugars into:

    React.createElement(elementClassorString, props, children);

If they want to use their own function for that... they can, but JSX is a trivially easy way to describe nested components (which can get verbose with the above).

A nice bonus of JSX is that it also means your components and render templates are not tied to React at all (if you're using stateless functions anyhow). You can switch the React.Component part trivially with babel to anything else (like deku, yolk, a custom one, whatever).

So.. yeah, seems an odd complaint.

I find it a bit odd that both you and the parent commenter (acemarke) seemed to have interpreted the post in a completely different tone than I did.

I didn't find anything in the original blog post in the tone of a "complaint". If anything, they were merely pointing out what kind of things they run into and their thoughts, while transitioning from an ASP.NET background.

It's actually a really helpful read if you also happen to come from ASP.NET and are looking to pick up the Node/React stack. I personally also came from a different stack only recently (not ASP.NET) and dove into Node/React a few months ago, and found the way he expressed his views helpful for myself to align my thoughts.

Yeah, re-reading it, the tone was a bit more "things we ran into" then "stuff we hated". That said, the items listed are definitely common complaints or points of argument about React that I've seen numerous times, so I was coming at it from more of that reaction.

> I didn't find anything in the original blog post in the tone of a "complaint". If anything, they were merely pointing out what kind of things they run into and their thoughts, while transitioning from an ASP.NET background.

Yes, exactly this! There's nothing to hate really. It's more of a complaint against our inability to quickly grasp new concepts than trying to throw some stones over to React.

Hey @acemarke, thanks for the comment!

For myself, I still have not decided whether I like JSX or not :) My colleague finds it great, and I like the declarative nature of it, just need to persuade myself to accept it mixed in JS file.

Yes on .bind, but I got used to not having to care about it in Aurelia (and Angular also). Got my fair share of `this` handling in pre-ES6.

And of course, thank you for the links. Bookmarked! :)

Are you using arrow functions? I find that using es2015 arrow functions for class methods takes care of most of the problems around this and react.

The only annoyance is dealing with binding event handlers to items/components in a list. Generally you need to abstract the list item into it's own component and do the event handler binding there.

I don't use .bind() anywhere in my react code.

Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. In fact, I believe class property syntax helps with that, but we only figured it out after we built these few pages and components necessary for the web app part.

>Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers.

They do. Just do:

  myHandler = (v) => {
    ...
  }

and you don't need to bind in the constructor anymore. You'll need to use Babel of course to transpile that.

Yes, class properties syntax. I mentioned that in the article.

Hmm, so why do you say "but they don't help with event handlers"? Because it's not yet standard?

Sorry, I didn't think about the arrow functions being used in class property syntax too. :) So yes, they do help with event handlers, I stand corrected.

One note: From what I've read, using arrow functions as props in a render method of a component will create new functions each render, so you might end up with a good bit more GC than normal. There are some nice little mix-ins that will autobind to remove the need to remember to .bind everything.

Not using arrow functions in JSX code to define error handler. Yes, I believe you are right, that would create multiple handlers.

Nowadays you can just stick a class property anywhere in your React component:

   handleSomething = (params) => {
     ...
   };

and the use it in your render function like this without any binding:

  <Foo onSomething={this.handleSomething}/>

Good suggestion - Thank you

Yes, class properties are the way to go.

Try react-native, react-gl or something with different render target than the web platform. It makes perfect sense to you then.

The SGML syntax is just perfect for composing and nesting components. So does HTML, XML etc. You just have to get your head around the idea that you´r writing HTML, because your´re not.

> just need to persuade myself to accept it mixed in JS file

Why is this a bad thing? The most important thing about JSX is that it's a single source of truth -- you never have to wonder if data is processed in the JS or in the template. I really think everything in one file is the ideal, we've even started moving the styles inline via styled-components.

Not a bad thing. Just a personal preference of trying to separate views and view models for a long time. I believe it just needs some time to get used to it. As I said, I really do like declarative nature of JSX, knowing that it's just compiled to a regular JS/DOM code.

Fwiw I think "compiled to" is a bit of a misnomer. From my understanding it's more like a DSL that gets interpreted by the renderer.

I think compilation is fair wording -- JSX is just sugar around the createElement API. : https://facebook.github.io/react/docs/react-api.html#createe...

A bit late, but my thought is that compiled to js/Dom api to me implies that it's compiled directly to document.createElement and friends.

I've found that the best way to make event handlers is instead of doing

     class Blah {
        private handleThing(...) {}
     }

to instead do this

    class Blah {
        private handlething = (...) => {}
    }

this means that it is created only once, at instantiation of the component, so it is fast, looks decent, and has access to `this` as it's technically a method on the object, not the class.

Also, if you're coming from C# land, head straight to TypeScript 2.3 - it's lush and handles the latest ECMAScript stuff wonderfully, and you get static type checking, interfaces, union types, etcetera. The only issue is when a package has no type definitions or no supplementary @types package, which sucks but they exist for most popular packages. Also VS Code is built with it in mind and brilliant to work with.

As for stacks, I'm currently really enjoying redux/redux-observable and my helper lib redux-rx-http (for API), I find harnessing the power of RxJS to manage side-effects through "epics" is a really elegant and decoupled way to chain a bunch of things that you want happen together.

Yep, the class property syntax helps with event handlers.

As for C# and TypeScript, we also have a very strong JavaScript background, from vanilla pre-ES6 to the latest ES2017+. We still prefer JavaScript to TypeScript, although out of languages that compile to JS, TypeScript is the best in our opinion.

One problem with using fat arrow syntax like this is the method is no longer attached to the prototype so it's not shared across all instances and is less memory efficient. It also doesn't work well with React HMR if you're using that. If you can use decorators I highly recommend autobind-decorator: https://github.com/andreypopp/autobind-decorator

Also I think you're using a TypeScript-specific `private` syntax there which likely changes the runtime semantics so my comment really only applies if you don't use that.

React is a tool like any other. If someone argues for or against the use of React based on anything other then the actual design / API / implementation / results of the framework its just a bad argument.

Well, this is just my (and partially of my colleague) subjective opinion after spending a month working with it. Of course, that's due to change once I get enough mileage with it.

Reply on news.ycombinator.com