What is the significance of “{” “}” braces around this react library code? [on hold]
I was going through react library code. After going through I found a special piece of code I am unable to understand its significance. Can someone help?
var validateFormat = function () {};
{
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
Here why react developer has wrapped the validateFormat into curly braces? is there any significance of doing this.
If I do the following it works the same -
var validateFormat = function () {};
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
javascript reactjs ecmascript-6
put on hold as off-topic by estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto Dec 28 '18 at 22:15
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "This question was caused by a problem that can no longer be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was resolved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting." – estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto
If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 3 more comments
I was going through react library code. After going through I found a special piece of code I am unable to understand its significance. Can someone help?
var validateFormat = function () {};
{
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
Here why react developer has wrapped the validateFormat into curly braces? is there any significance of doing this.
If I do the following it works the same -
var validateFormat = function () {};
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
javascript reactjs ecmascript-6
put on hold as off-topic by estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto Dec 28 '18 at 22:15
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "This question was caused by a problem that can no longer be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was resolved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting." – estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto
If this question can be reworded to fit the rules in the help center, please edit the question.
7
Can you cite this source? They seem superfluous, but my guess is you've "dumbed down the code" for the sake of presentation and just making them appear superfluous.
– Patrick Roberts
Dec 27 '18 at 8:29
1
It creates a block around the function. But since there's no block scope when using vars, it has no meaning written this way. Possible explanations that come to mind are: 1) Transpiled code, 2) Inexperienced dev, 3) There used to be a label on the block that got removed.
– Shilly
Dec 27 '18 at 8:31
@Shillysince there's no block scope in JS
is wrong. Starting in ES6let
andconst
are block scope declarations.
– Patrick Roberts
Dec 27 '18 at 8:31
2
@abhishekgangwar there's like 100s of files in here. Save us some time and edit your question to properly cite this source.
– Patrick Roberts
Dec 27 '18 at 8:35
1
The question is actually off-topic because it's caused by incorrectly pasted code.
– estus
Dec 28 '18 at 14:49
|
show 3 more comments
I was going through react library code. After going through I found a special piece of code I am unable to understand its significance. Can someone help?
var validateFormat = function () {};
{
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
Here why react developer has wrapped the validateFormat into curly braces? is there any significance of doing this.
If I do the following it works the same -
var validateFormat = function () {};
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
javascript reactjs ecmascript-6
I was going through react library code. After going through I found a special piece of code I am unable to understand its significance. Can someone help?
var validateFormat = function () {};
{
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
Here why react developer has wrapped the validateFormat into curly braces? is there any significance of doing this.
If I do the following it works the same -
var validateFormat = function () {};
validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
javascript reactjs ecmascript-6
javascript reactjs ecmascript-6
edited Dec 27 '18 at 8:29
John Kennedy
2,5202926
2,5202926
asked Dec 27 '18 at 8:25
abhishek gangwar
550313
550313
put on hold as off-topic by estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto Dec 28 '18 at 22:15
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "This question was caused by a problem that can no longer be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was resolved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting." – estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto
If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as off-topic by estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto Dec 28 '18 at 22:15
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "This question was caused by a problem that can no longer be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was resolved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting." – estus, snakecharmerb, Styx, Phil Ross, fabio.sussetto
If this question can be reworded to fit the rules in the help center, please edit the question.
7
Can you cite this source? They seem superfluous, but my guess is you've "dumbed down the code" for the sake of presentation and just making them appear superfluous.
– Patrick Roberts
Dec 27 '18 at 8:29
1
It creates a block around the function. But since there's no block scope when using vars, it has no meaning written this way. Possible explanations that come to mind are: 1) Transpiled code, 2) Inexperienced dev, 3) There used to be a label on the block that got removed.
– Shilly
Dec 27 '18 at 8:31
@Shillysince there's no block scope in JS
is wrong. Starting in ES6let
andconst
are block scope declarations.
– Patrick Roberts
Dec 27 '18 at 8:31
2
@abhishekgangwar there's like 100s of files in here. Save us some time and edit your question to properly cite this source.
– Patrick Roberts
Dec 27 '18 at 8:35
1
The question is actually off-topic because it's caused by incorrectly pasted code.
– estus
Dec 28 '18 at 14:49
|
show 3 more comments
7
Can you cite this source? They seem superfluous, but my guess is you've "dumbed down the code" for the sake of presentation and just making them appear superfluous.
– Patrick Roberts
Dec 27 '18 at 8:29
1
It creates a block around the function. But since there's no block scope when using vars, it has no meaning written this way. Possible explanations that come to mind are: 1) Transpiled code, 2) Inexperienced dev, 3) There used to be a label on the block that got removed.
– Shilly
Dec 27 '18 at 8:31
@Shillysince there's no block scope in JS
is wrong. Starting in ES6let
andconst
are block scope declarations.
– Patrick Roberts
Dec 27 '18 at 8:31
2
@abhishekgangwar there's like 100s of files in here. Save us some time and edit your question to properly cite this source.
– Patrick Roberts
Dec 27 '18 at 8:35
1
The question is actually off-topic because it's caused by incorrectly pasted code.
– estus
Dec 28 '18 at 14:49
7
7
Can you cite this source? They seem superfluous, but my guess is you've "dumbed down the code" for the sake of presentation and just making them appear superfluous.
– Patrick Roberts
Dec 27 '18 at 8:29
Can you cite this source? They seem superfluous, but my guess is you've "dumbed down the code" for the sake of presentation and just making them appear superfluous.
– Patrick Roberts
Dec 27 '18 at 8:29
1
1
It creates a block around the function. But since there's no block scope when using vars, it has no meaning written this way. Possible explanations that come to mind are: 1) Transpiled code, 2) Inexperienced dev, 3) There used to be a label on the block that got removed.
– Shilly
Dec 27 '18 at 8:31
It creates a block around the function. But since there's no block scope when using vars, it has no meaning written this way. Possible explanations that come to mind are: 1) Transpiled code, 2) Inexperienced dev, 3) There used to be a label on the block that got removed.
– Shilly
Dec 27 '18 at 8:31
@Shilly
since there's no block scope in JS
is wrong. Starting in ES6 let
and const
are block scope declarations.– Patrick Roberts
Dec 27 '18 at 8:31
@Shilly
since there's no block scope in JS
is wrong. Starting in ES6 let
and const
are block scope declarations.– Patrick Roberts
Dec 27 '18 at 8:31
2
2
@abhishekgangwar there's like 100s of files in here. Save us some time and edit your question to properly cite this source.
– Patrick Roberts
Dec 27 '18 at 8:35
@abhishekgangwar there's like 100s of files in here. Save us some time and edit your question to properly cite this source.
– Patrick Roberts
Dec 27 '18 at 8:35
1
1
The question is actually off-topic because it's caused by incorrectly pasted code.
– estus
Dec 28 '18 at 14:49
The question is actually off-topic because it's caused by incorrectly pasted code.
– estus
Dec 28 '18 at 14:49
|
show 3 more comments
3 Answers
3
active
oldest
votes
The block scope is a result of their babel-preset-fbjs. If you look at the original source you'll find that instead, this function is conditionally defined depending on the value of __DEV__
, which is optimized out during transpilation since it is equivalent to process.env.NODE_ENV !== 'production'
.
let validateFormat = () => {};
if (__DEV__) {
validateFormat = function(format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
6
Yes, the problem here is that the code was misquoted.
– estus
Dec 27 '18 at 8:45
add a comment |
This code makes perfect sense.
var v = function () {};
{
v = function (format) {
// actual code
};
}
The first assignment defines v
to an empty placeholder function so that code does not break.
The second assignment contains the actual code of the function. It is inside a block scope, which is a legit JS construct.
But... block scoping does nothing because of variable hoisting, which nullifies any locality contrary to C/C++ adepts' expectations. Many say there is no block scoping in JS, which is false. There is block scoping but it's ineffective (apart from more recent let
/const
declarations).
So what this code does is abuse the ineffective block syntax to separate visually parts of code.
But (and this is what I think is going on here) what we see here is just an EXAMPLE. I could very well come up with another example that makes perfect sense, such as this:
var v = function () {};
{
let localValue = 0;
v = function (format) {
// actual code using localValue
localValue = 1;
};
}
In other words, you may find other examples in the code base which leverages block scoping through let
/const
and encapsulates the definition as shown. The example you give just doesn't leverage this opportunity but the scoping remains because:
- it does not disrupt or break code;
- uniformity;
- in future may carry more weight adding
let
/const
.
This is all guessing on my part.
add a comment |
Curly braces here are block statement. They don't serve any good purpose in this case and can safely omitted. Block scope doesn't work with var
. Even if it was let
, block statement wouldn't affect it because validateFormat
is already defined outside block statement.
An example where block statement is useful would be:
let validateFormat = function () {};
{
// doesn't reassign validateFormat from outer scope
let validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
// validateFormat from block scope is used here
}
// validateFormat from outer scope is used here
The answer provides technically correct explanation. The real problem here is that the question contains wrong code that doesn't make sense because if (...)
statement was omitted when the code was pasted, as accepted answer shows.
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The block scope is a result of their babel-preset-fbjs. If you look at the original source you'll find that instead, this function is conditionally defined depending on the value of __DEV__
, which is optimized out during transpilation since it is equivalent to process.env.NODE_ENV !== 'production'
.
let validateFormat = () => {};
if (__DEV__) {
validateFormat = function(format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
6
Yes, the problem here is that the code was misquoted.
– estus
Dec 27 '18 at 8:45
add a comment |
The block scope is a result of their babel-preset-fbjs. If you look at the original source you'll find that instead, this function is conditionally defined depending on the value of __DEV__
, which is optimized out during transpilation since it is equivalent to process.env.NODE_ENV !== 'production'
.
let validateFormat = () => {};
if (__DEV__) {
validateFormat = function(format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
6
Yes, the problem here is that the code was misquoted.
– estus
Dec 27 '18 at 8:45
add a comment |
The block scope is a result of their babel-preset-fbjs. If you look at the original source you'll find that instead, this function is conditionally defined depending on the value of __DEV__
, which is optimized out during transpilation since it is equivalent to process.env.NODE_ENV !== 'production'
.
let validateFormat = () => {};
if (__DEV__) {
validateFormat = function(format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
The block scope is a result of their babel-preset-fbjs. If you look at the original source you'll find that instead, this function is conditionally defined depending on the value of __DEV__
, which is optimized out during transpilation since it is equivalent to process.env.NODE_ENV !== 'production'
.
let validateFormat = () => {};
if (__DEV__) {
validateFormat = function(format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
}
edited Dec 27 '18 at 8:45
answered Dec 27 '18 at 8:43
Patrick Roberts
19.3k33475
19.3k33475
6
Yes, the problem here is that the code was misquoted.
– estus
Dec 27 '18 at 8:45
add a comment |
6
Yes, the problem here is that the code was misquoted.
– estus
Dec 27 '18 at 8:45
6
6
Yes, the problem here is that the code was misquoted.
– estus
Dec 27 '18 at 8:45
Yes, the problem here is that the code was misquoted.
– estus
Dec 27 '18 at 8:45
add a comment |
This code makes perfect sense.
var v = function () {};
{
v = function (format) {
// actual code
};
}
The first assignment defines v
to an empty placeholder function so that code does not break.
The second assignment contains the actual code of the function. It is inside a block scope, which is a legit JS construct.
But... block scoping does nothing because of variable hoisting, which nullifies any locality contrary to C/C++ adepts' expectations. Many say there is no block scoping in JS, which is false. There is block scoping but it's ineffective (apart from more recent let
/const
declarations).
So what this code does is abuse the ineffective block syntax to separate visually parts of code.
But (and this is what I think is going on here) what we see here is just an EXAMPLE. I could very well come up with another example that makes perfect sense, such as this:
var v = function () {};
{
let localValue = 0;
v = function (format) {
// actual code using localValue
localValue = 1;
};
}
In other words, you may find other examples in the code base which leverages block scoping through let
/const
and encapsulates the definition as shown. The example you give just doesn't leverage this opportunity but the scoping remains because:
- it does not disrupt or break code;
- uniformity;
- in future may carry more weight adding
let
/const
.
This is all guessing on my part.
add a comment |
This code makes perfect sense.
var v = function () {};
{
v = function (format) {
// actual code
};
}
The first assignment defines v
to an empty placeholder function so that code does not break.
The second assignment contains the actual code of the function. It is inside a block scope, which is a legit JS construct.
But... block scoping does nothing because of variable hoisting, which nullifies any locality contrary to C/C++ adepts' expectations. Many say there is no block scoping in JS, which is false. There is block scoping but it's ineffective (apart from more recent let
/const
declarations).
So what this code does is abuse the ineffective block syntax to separate visually parts of code.
But (and this is what I think is going on here) what we see here is just an EXAMPLE. I could very well come up with another example that makes perfect sense, such as this:
var v = function () {};
{
let localValue = 0;
v = function (format) {
// actual code using localValue
localValue = 1;
};
}
In other words, you may find other examples in the code base which leverages block scoping through let
/const
and encapsulates the definition as shown. The example you give just doesn't leverage this opportunity but the scoping remains because:
- it does not disrupt or break code;
- uniformity;
- in future may carry more weight adding
let
/const
.
This is all guessing on my part.
add a comment |
This code makes perfect sense.
var v = function () {};
{
v = function (format) {
// actual code
};
}
The first assignment defines v
to an empty placeholder function so that code does not break.
The second assignment contains the actual code of the function. It is inside a block scope, which is a legit JS construct.
But... block scoping does nothing because of variable hoisting, which nullifies any locality contrary to C/C++ adepts' expectations. Many say there is no block scoping in JS, which is false. There is block scoping but it's ineffective (apart from more recent let
/const
declarations).
So what this code does is abuse the ineffective block syntax to separate visually parts of code.
But (and this is what I think is going on here) what we see here is just an EXAMPLE. I could very well come up with another example that makes perfect sense, such as this:
var v = function () {};
{
let localValue = 0;
v = function (format) {
// actual code using localValue
localValue = 1;
};
}
In other words, you may find other examples in the code base which leverages block scoping through let
/const
and encapsulates the definition as shown. The example you give just doesn't leverage this opportunity but the scoping remains because:
- it does not disrupt or break code;
- uniformity;
- in future may carry more weight adding
let
/const
.
This is all guessing on my part.
This code makes perfect sense.
var v = function () {};
{
v = function (format) {
// actual code
};
}
The first assignment defines v
to an empty placeholder function so that code does not break.
The second assignment contains the actual code of the function. It is inside a block scope, which is a legit JS construct.
But... block scoping does nothing because of variable hoisting, which nullifies any locality contrary to C/C++ adepts' expectations. Many say there is no block scoping in JS, which is false. There is block scoping but it's ineffective (apart from more recent let
/const
declarations).
So what this code does is abuse the ineffective block syntax to separate visually parts of code.
But (and this is what I think is going on here) what we see here is just an EXAMPLE. I could very well come up with another example that makes perfect sense, such as this:
var v = function () {};
{
let localValue = 0;
v = function (format) {
// actual code using localValue
localValue = 1;
};
}
In other words, you may find other examples in the code base which leverages block scoping through let
/const
and encapsulates the definition as shown. The example you give just doesn't leverage this opportunity but the scoping remains because:
- it does not disrupt or break code;
- uniformity;
- in future may carry more weight adding
let
/const
.
This is all guessing on my part.
answered Dec 27 '18 at 8:41
pid
9,57552447
9,57552447
add a comment |
add a comment |
Curly braces here are block statement. They don't serve any good purpose in this case and can safely omitted. Block scope doesn't work with var
. Even if it was let
, block statement wouldn't affect it because validateFormat
is already defined outside block statement.
An example where block statement is useful would be:
let validateFormat = function () {};
{
// doesn't reassign validateFormat from outer scope
let validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
// validateFormat from block scope is used here
}
// validateFormat from outer scope is used here
The answer provides technically correct explanation. The real problem here is that the question contains wrong code that doesn't make sense because if (...)
statement was omitted when the code was pasted, as accepted answer shows.
add a comment |
Curly braces here are block statement. They don't serve any good purpose in this case and can safely omitted. Block scope doesn't work with var
. Even if it was let
, block statement wouldn't affect it because validateFormat
is already defined outside block statement.
An example where block statement is useful would be:
let validateFormat = function () {};
{
// doesn't reassign validateFormat from outer scope
let validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
// validateFormat from block scope is used here
}
// validateFormat from outer scope is used here
The answer provides technically correct explanation. The real problem here is that the question contains wrong code that doesn't make sense because if (...)
statement was omitted when the code was pasted, as accepted answer shows.
add a comment |
Curly braces here are block statement. They don't serve any good purpose in this case and can safely omitted. Block scope doesn't work with var
. Even if it was let
, block statement wouldn't affect it because validateFormat
is already defined outside block statement.
An example where block statement is useful would be:
let validateFormat = function () {};
{
// doesn't reassign validateFormat from outer scope
let validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
// validateFormat from block scope is used here
}
// validateFormat from outer scope is used here
The answer provides technically correct explanation. The real problem here is that the question contains wrong code that doesn't make sense because if (...)
statement was omitted when the code was pasted, as accepted answer shows.
Curly braces here are block statement. They don't serve any good purpose in this case and can safely omitted. Block scope doesn't work with var
. Even if it was let
, block statement wouldn't affect it because validateFormat
is already defined outside block statement.
An example where block statement is useful would be:
let validateFormat = function () {};
{
// doesn't reassign validateFormat from outer scope
let validateFormat = function (format) {
if (format === undefined) {
throw new Error('invariant requires an error message argument');
}
};
// validateFormat from block scope is used here
}
// validateFormat from outer scope is used here
The answer provides technically correct explanation. The real problem here is that the question contains wrong code that doesn't make sense because if (...)
statement was omitted when the code was pasted, as accepted answer shows.
edited Dec 28 '18 at 14:51
answered Dec 27 '18 at 8:44
estus
67.1k2198213
67.1k2198213
add a comment |
add a comment |
7
Can you cite this source? They seem superfluous, but my guess is you've "dumbed down the code" for the sake of presentation and just making them appear superfluous.
– Patrick Roberts
Dec 27 '18 at 8:29
1
It creates a block around the function. But since there's no block scope when using vars, it has no meaning written this way. Possible explanations that come to mind are: 1) Transpiled code, 2) Inexperienced dev, 3) There used to be a label on the block that got removed.
– Shilly
Dec 27 '18 at 8:31
@Shilly
since there's no block scope in JS
is wrong. Starting in ES6let
andconst
are block scope declarations.– Patrick Roberts
Dec 27 '18 at 8:31
2
@abhishekgangwar there's like 100s of files in here. Save us some time and edit your question to properly cite this source.
– Patrick Roberts
Dec 27 '18 at 8:35
1
The question is actually off-topic because it's caused by incorrectly pasted code.
– estus
Dec 28 '18 at 14:49