This question already has answers here:
Are 'Arrow Functions' and 'Functions' equivalent / interchangeable?
(4 answers)
Closed 3 years ago.
When I have a react hook and inside of it I want to define a function in it, would I better use
useEffect(() => {
//...
function handler() {}
//...
}, []);
or the newer const declaration
useEffect(() => {
//...
const handler = () => {}
//...
}, []);
Are both exactly equivalent or are there differences in how Javascript handles these things?
If I define a const, it's only valid within the current scope, while defining a function would be valid elsewhere, is this true?
Does react need the functions accessible in different scopes or are they staying local in the current hook scope?
Since THIS is apart of the past by using React Hooks, you can use them both :) it's just syntax sugar es6.
If you want to go deeper on their differences you can use this article: https://www.freecodecamp.org/news/constant-confusion-why-i-still-use-javascript-function-statements-984ece0b72fd/ (there are plenty of more)
BUT IN REACT HOOKS THEY HAVE THE SAME SCOPE
React hooks you can only use in pure components, means functions. So most of things you do there is just working as would you work with just some js function, no much difference really. In hooks themselves not all things possible, like one time I tried to make useEffect hook callback to be async function and get warning to run async function inside of it instead.
Inside pure component, that function, you not really need any this, so as Renaldo Balaj said, there is no difference wether use usual or arrow function.
Related
This question already has answers here:
Standard conventions for indicating a function argument is unused in JavaScript
(6 answers)
Closed 9 months ago.
Specifically, I am using react-semantic-ui's Select Form, which takes an onChange function. So I have defined my function as such:
const handleInputChange = function handleInputChange(event, data){// does something with data}
(don't mind the ugly syntax, that's airbnb style guide)
I am doing something with data, but I am not using the event parameter at all. What would be the best practice in this case, since it is generally a bad practice to declare a variable without using it?
You must declare a parameter for every argument before the one you want to use.
The idiomatic approach to marking a parameter as unused is to prefix its name with an underscore.
function handleInputChange(_event, data){
Some linters will recognise this and not emit a "unused variable" warning.
For example ESLint has a argsIgnorePattern option (but it also has a args option that lets you specify after-used).
Actually by using Js es6 you could code without unused argument:)
function handleInputChange(...[, data]) {
console.log(data);
}
handleInputChange('event', 123);
And bellow is a similar question you could check out:)
Standard conventions for indicating a function argument is unused in JavaScript
This question already has answers here:
What do multiple arrow functions mean in JavaScript?
(7 answers)
Closed 3 years ago.
Below is a code snippet which I came across in one of the blog for redux.
This snippet explains redux-thunk. But I am trying to make sense out of the weird syntax
return ({dispatch, getState}) => next => action =>{}
I tried a google search with this syntax but did not get much help. I am not understanding how next and action objects are getting their values. Can someone please help me understand what's going on here?
Chaining of functions in this way is usually to enable a user to bind arguments to a final function in a controlled fashion, rather than having to supply them all in one go.
In effect it is an API design choice for a piece of functionality.
({dispatch, getState}) => next => action => {}
...is equivalent to:
function({dispatch, getState}) { // destructure two properties into arguments
return function(next) {
return function(action) {
// this function has access to `dispatch`, `getState`, `next` & `action`
}
}
}
Note that the "binding" of the arguments to the inner functions occurs through a feature of JavaScript called closures. Full explanation of closures in JavaScript here.
This question already has answers here:
Are 'Arrow Functions' and 'Functions' equivalent / interchangeable?
(4 answers)
Closed 4 years ago.
does it help in handling the this keyword sometimes, when compared to the normal functions like in ReactJS?
Because in react to pass functions through components we need consider the this keyword very carefully so please help me understand how arrow functions help.
Arrow functions lack scope. For example:
function outer()
{
function inner()
{
console.log(this) //Refers to inner function
}
inner();
}
function outerTwo()
{
let inner = () => {
console.log(this) //refers to outer
}
inner();
}
outer();
outerTwo();
If you try to use an arrow function for a prototype method definition and you use thisanywhere in there, it'll refer to the window / global context.Because it will not have it's own scope. Because they lack scope, they can be useful for method injection, where they can refer to the the container that's calling them. Hence, why they're often used as callbacks.
You answered the question yourself. Using arrow function helps you with referencing this context of the given component and sometimes is also used as it is shorter and therefore faster to write.
This question already has answers here:
Why would you ever call .call() on Observable functions?
(3 answers)
Closed 5 years ago.
I have seen in the ngrx source, for example, that they use call.
pluck.call(route.params, 'id');
What is the difference between the above code and:
route.params.pluck('id');
When do we need to use call when using observables?
When you use call, you explicitly give the context of the function - to which this refers in the function.
See the difference between calls.
function test() {
console.log(this.n);
}
const obj = { n: 'Your Name' };
test();
test.call(obj);
Better. Thanks to #cartant. Based on his comment editing the answer
The call mechanism was recommended for library authors, so that they don't patch Observable.prototype with operators that library clients could accidentally depend upon. If a library were to patch and later remove operators, client code could break. It was tedious for library authors and it can now be avoided using pipe and pipeable/lettable operators
This question already has answers here:
Proper use of const for defining functions
(5 answers)
Closed 5 years ago.
I was wondering if there is any difference in performance when dealing with dumb component in React, since there are 2 possible ways to achieve the same result.
function Comp(props) {
...
}
const Comp = props => {
...
}
Really they are two ways to define a function and there should be no difference in the performances.
There's definitely no difference between the two in your example. Hence this code also gets compiled and you end up having the same thing:
function CompA(props) {}
const CompB = props => {}
gets transpiled to:
function CompA(props) {}
var CompB = function CompB(props) {};
edit: There is difference in both functions tho. In performance they are the same but in behavior the code is different. We have hoisting and different context involved.
edit2: Well, it looks like there IS a difference. Check out https://jsperf.com/react-stateless-compare