You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 25, 2019. It is now read-only.
I'm of the belief that each challenge should try to get across a single concept. I don't feel your users are familiar enough with scoping and the behaviour of named function expressions. And moreover, it's not relevant to the lesson we are attempting to teach, and I feel it distracts from it a little.
For reference, here is the code:
const sum = (function() {
"use strict";
return function sum(x, y, z) {
const args = [ x, y, z ];
return args.reduce((a, b) => a + b, 0);
};
})();
I assume the use of assigning the arguments to a single identifier and then using it for the reduction is so that it's significantly easier to replace (x, y, z) with (...args) and it will then Just Work. This is great, and really useful for teaching.
Yet, the code could (and should!) be:
function sum(x, y, z) {
"use strict";
const args = [ x, y, z ];
return args.reduce((a, b) => a + b, 0);
}
This preserves the same behaviour of ease of transformation.
(If you really must avoid the hoisting behaviour of the use of a function declaration, this can be done).
I propose we change the default snippet to the above.
For reference, here is a thread in which conversion to arrow notation was attempted, and it was noted that it wasn't as easy as if it would be had the function been written as above.
Thoughts are welcome.
The text was updated successfully, but these errors were encountered:
joker314
changed the title
Overly intricate IIFE for scoping causes confusion
Overly intricate IIFE when no scoping conflicts present causes confusion
Sep 1, 2018
joker314
changed the title
Overly intricate IIFE when no scoping conflicts present causes confusion
Overly intricate IIFE whith no scoping conflict causes confusion
Sep 2, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When viewing the default code that the editor is initialised with for the ES6: Use the rest operator with function parameters, it appears to be too confusing.
I'm of the belief that each challenge should try to get across a single concept. I don't feel your users are familiar enough with scoping and the behaviour of named function expressions. And moreover, it's not relevant to the lesson we are attempting to teach, and I feel it distracts from it a little.
For reference, here is the code:
I assume the use of assigning the arguments to a single identifier and then using it for the reduction is so that it's significantly easier to replace
(x, y, z)
with(...args)
and it will then Just Work. This is great, and really useful for teaching.Yet, the code could (and should!) be:
This preserves the same behaviour of ease of transformation.
(If you really must avoid the hoisting behaviour of the use of a function declaration, this can be done).
I propose we change the default snippet to the above.
For reference, here is a thread in which conversion to arrow notation was attempted, and it was noted that it wasn't as easy as if it would be had the function been written as above.
Thoughts are welcome.
The text was updated successfully, but these errors were encountered: