-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change function syntax #15
Comments
Did cause great confusion |
This pattern used to have great value in debugging. Note that
cannot be used recursively. |
I don't think I want to change this. It's a "teachable moment" and IMO an example of institutional knowledge being present in a README as well as in my head. The problem here is that the README does not mention:
|
To clarify this did cause great confusion. We had to change the way it was taught mis lesson to keep students on board. |
It's a scope of names discussion. const foo = function bar () {
}; The scope of The scope of This causes some heads to explode. Stack traces including |
I mentioned this during WDI 12 and didn't really experience much confusion during the lesson. I told them they could leave the function declaration name off and just use the assigned name. |
I'm not sure what you mean by "function declaration name". The syntax I used in my comments are function expressions. Adding the name does not create a declaration. function bar() {return "bar declared";}
const foo = function bar() {return "bar expression";} The second bar shadows the first inside the function stored in foo, and allows for recursive calls, but other than it doesn't do anything. So the two snippets of code, It was an issue for 009, 010, 011. I seem to remember it coming up when we told them not to use the declaration form. After typing for a bit I realize this may be too deep a point for WDI Developers, and the confusion may have come from my attempt to ensure they understood the distinction. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function |
const foo = function bar() {return "bar expression";}
// i meant this ------^
Maybe so. I glossed over the distinction, most likely because I couldn't express it in English. My "explanation" went: "There are two ways to define functions. You should use this way (expression), not that (declaration). If you want to call the function recursively, or if you want to improve debugging, do both." |
Just to be a pedant, the Restating, a name in a function expression isn't visible in the containing scope, just the function body. A name in a function declaration is visible in the containing scope. Are we having fun yet? So, the pedagogical point may be that I shouldn't try to make this distinction clear. I think that's probably correct and difficult for me to do.:-). Advice on on how I might achieve that would be useful. Or maybe Jason's original point of just leaving it out would be best for me. |
I think the best course of action is to tell them, Hey, you can declare your functions this way:
OR this way:
The reason you MAY want to declare them the original way involves recursion and should only be used when you need to call the function you're declaring within the function itself. IF what I just said makes your head spin, declare your functions like this until you have a better grasp on javascript:
Thoughts? @J-Weeks @gaand @jrhorn424 ? |
Honestly we can leave it out at this point. This is a great discussion and I learned a bit. Thanks @gaand for taking the time to explain and @J-Weeks for posting. My original resistance and the strongest point I've made is that debugging used to suck without putting a name on both sides of the assignment. I haven't experienced that much lately, and I use simple function expressions everywhere else in the curriculum, so I suspect I would have noticed the pain. |
We might want to be consistent and only do it one(*) way: const snafu = function (param) {
}
const fubar = () => {
}; (*) where one is two. |
Please see ga-wdi-boston/js-modules-study#17 as well. |
@ga-wdi-boston/core May we settle on my suggestion for all JavaScript functions not defined as methods, or would someone like to make a reasoned counter argument? |
@gaand I consider this settled and agree with your convention. Is this an accurate summary? // GOOD
const foo = function () { };
// GOOD if needed for recursion
const bar = function bar () {};
// BAD otherwise
const baz = function baz () {}; |
Is fat arrow appropriate? Or do we want to track that separately? |
I think setting it up like this will cause great confusion:
Should be changed to:
The text was updated successfully, but these errors were encountered: