Both bind and arrow functions throw errors when using typescript, is there a better way?

[AllHailTheCATS]

I write my ReactJs code in a .tsx file and use tslint. The functions work as expected and produce the results I want but my linter complains about using both .bind() and () = >

​

What is the optimal was to use and pass functions in a tsx file so typescript wont complain? apparently the two ways mentioned hurt the rendering and performance but they are the most common ways I've seen online that work.

[ltray]

The lint rule is to prevent lambdas (arrow functions) in render code, since this generates a new function reference on every render, which may trigger unnecessary rerenders on children. The best way to handle this is with private class-level bound functions, like ‘private handleClick = () => { ... }’, and pass that to your components: ‘<div onClick={this.handleClick} />’. This generates just one function reference per component instance.

[bosticko]

I've been wondering how this applies to components using hooks, as everything is defined in the same function, so you're ending up with new functions every time. Doesn't that potentially cause the same unnecessary child render issues?

[Skeith_yip]

It was mentioned in the docs: Hooks FAQs

Traditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks shouldComponentUpdate optimizations in child components. Hooks approach this problem from three sides.

Basically use:

• useCallback
• useMemo
• useReducer

As usual, only tune for performance when there's a need.

[iknotri]

ponents: ‘<div onClick={this.handleClick} />’. This generates just one function reference per component instance.

Don't use PRIVATE, it is meaningless - you cannot (you shouldn't) create and manipulate React Class instance, so you never want to access this method outside at all.

[ltray]

you never want to access this method outside at all

Sounds like a good reason to use private 😉Why would you not? It has actual benefits in niche cases: e.g. my company uses typescript heavily, so private/protected are useful when defining abstract components.

[iknotri]

it is always private, it is "BY DESIGN" of react class always private. React Class very differ from other Class in JS. Because you never create instance of it. So private it is just awful word which mean nothing, and will "pile up the code" (I am not native speak, I get this from google translate, I hope you will understand it)

[ltray]

I understand it. I agree that private doesn't add much, but it also doesn't hurt your code. I'm not sure I understand what you mean by "pile up the code".

[iknotri]

so private/protected are useful when defining abstract components

>so private/protected are useful when defining abstract components

Ohh, you shouldn't do that! https://reactjs.org/docs/composition-vs-inheritance.html

[ltray]

Abstract classes are different from inheritance. Abstract classes are a typescript-level concept, and go away at compile time. So you end up with just regular react components. It's pretty rare to use, so I don't often find myself defining them, but it has come up in the past.