Live data from Hacker News

Learning Node.js and React while building a product

javascriptkicks.com

11–20 of 42 posts

Re: Learning Node.js and React while building a product

#11
post #3

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 fr…

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. Bookm…

> 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.

Re: Learning Node.js and React while building a product

#12
post #10

Earlier quoted context omitted.

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.

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.

Re: Learning Node.js and React while building a product

#14
If your team is from a .NET background, you may be better off using something with first class Typescript support.

I have been working on a boilerplate that uses VueJS with typescript. It is still reactive. I setup the UI to closely mirror the structure of a .NET MVC app. It is much more intuitive to me coming from a strongly typed OO background.

The boilerplate is not fully done yet, but here is the UI portion if you'd like to browse the structure: https://github.com/caleblloyd/dotnet-core-boilerplate/tree/d...

Re: Learning Node.js and React while building a product

#15
post #10

Earlier quoted context omitted.

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.

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.

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:

  

Re: Learning Node.js and React while building a product

#16
post #3

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 fr…

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. Bookm…

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.

Re: Learning Node.js and React while building a product

#17
post #3

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 fr…

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.

Re: Learning Node.js and React while building a product

#18
post #10

Earlier quoted context omitted.

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.

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:

Good suggestion - Thank you

Re: Learning Node.js and React while building a product

#20
You don't have to use 'this' at all in React. I've written about it here: https://medium.com/@baronmaximilianwilleford/react-without-t...

I never use 'this', 'bind', 'apply', 'call', 'class', and only use 'new' to create React components. I find it much easier and more fun to work with React as a result. I hope other people would give it a try.

Post reply on HN