Discussion, Questions, and Resources for Part 1 (JavaScript - April 2018 Cohort)

Discussion, Questions, and Resources for Part 1 (JavaScript - April 2018 Cohort)


It wouldn’t let me vote, did it close because I didn’t see this until April 15 perhaps? Anyway, I’ve finished all of section one and I’m working through section2. In fact I’m almost done with that too, working my way through functional programming. For me, the REGEX section was the hardest so far…


Might I suggest adding The JavaScript Way to the list of recommended resources? it’s a beginner-friendly book written in ES2015 and entirely free to read on GitHub (à la YDKJS). It also includes many exercises and projects. I do think it complements the FCC curriculum nicely.

Disclaimer: I’m the author.


please add me to the list?


Started today, and about halfway through basic. I’d like to finish today if possible. I’ve already done the FCC front end curriculum up to the front end intermediate projects. However I have struggled quite a bit on codewars, and i’m thinking I need to go back over some stuff. However the beta stuff looks really good!

Anyone know how the beta and legacy stuff will be handled? will one impact the other?


sorry - should have searched first. if anyone else was wondering, check out these links.


Strict Mode

I wasn’t familiar with "use strict" (i.e. Strict mode) so I looked it up.

In ES6: Explore Differences Between the var and let Keywords, it states:

Note the “use strict”. This enables Strict Mode, which catches common coding mistakes and “unsafe” actions.

That’s helpful, but is it necessary to use it? What are the suggested best practices?

According to MDN’s Strict mode page:

ECMAScript 5’s strict mode is a way to opt in to a restricted variant of JavaScript, thereby implicitly opting-out of “sloppy mode”. Strict mode isn’t just a subset: it intentionally has different semantics from normal code. Browsers not supporting strict mode will run strict mode code with different behavior from browsers that do, so don’t rely on strict mode without feature-testing for support for the relevant aspects of strict mode. Strict mode code and non-strict mode code can coexist, so scripts can opt into strict mode incrementally.

Here are some other resources about Strict mode that might be helpful:

In general, it seems to be best practice to use Strict mode on new projects but not necessarily to add it to existing projects.

map(), filter(), and reduce()

So, unfortunately, freeCodeCamp Beta doesn’t do a great job of introducing the map, filter, and reduce functions before they’re needed. Here’s a quick summary:

  • map()
    MDN map() page | fCC Guide on map()

    The map() method creates a new array with the results of calling a provided function on every element in the calling array.


    var numbers = [1, 4, 9];
    var roots = numbers.map(Math.sqrt);
    // roots is now [1, 2, 3]
    // numbers is still [1, 4, 9]
  • filter()
    MDN filter() page | fCC Guide on filter()

    The filter() method creates a new array with all elements that pass the test implemented by the provided function.


    const words = ["spray", "limit", "elite", "exuberant", "destruction", "present", "happy"];
    let longWords = words.filter(word => word.length > 6);
    // Filtered array longWords is ["exuberant", "destruction", "present"]
  • reduce()
    MDN reduce() page | fCC Guide on reduce()

    The reduce() method applies a function against an accumulator and each element in the array (from left to right) to reduce it to a single value.


    var sum = [0, 1, 2, 3].reduce(function (accumulator, currentValue) {
       return accumulator + currentValue;
    }, 0);
    // sum is 6


Write Higher Order Arrow Functions1
Write Higher Order Arrow Functions prb

Just want to hop in here and emphasize how useful these functions are, especially map and filter. I’m working on a masters in Cartography and one of my current courses heavily emphasizes D3 so I jumped ahead to work some of the data visualization projects. These functions were invaluable in completing the projects that I did. Basically what i’m saying is don’t skip on fully learning these, you’ll need to understand them.


Where do you think we should best introduce each of these concepts in the flow of freeCodeCamp’s beta curriculum?


If I may jump in here, these concepts are first passively mentioned in the ES6: Write Higher Order Arrow Functions lesson so it should probably be taught before that. I think somewhere at the end of the Basic JavaScript section - where some specific JS methods (random & parseInt) are introduced - makes the most sense.


hey guys,

anyone else having issues with this challenge? I’ve finally looked it up and entered the solution in, and its still not passing.

var contacts = [
        "firstName": "Akira",
        "lastName": "Laine",
        "number": "0543236543",
        "likes": ["Pizza", "Coding", "Brownie Points"]
        "firstName": "Harry",
        "lastName": "Potter",
        "number": "0994372684",
        "likes": ["Hogwarts", "Magic", "Hagrid"]
        "firstName": "Sherlock",
        "lastName": "Holmes",
        "number": "0487345643",
        "likes": ["Intriguing Cases", "Violin"]
        "firstName": "Kristian",
        "lastName": "Vos",
        "number": "unknown",
        "likes": ["JavaScript", "Gaming", "Foxes"]

function lookUpProfile(name, prop){
// Only change code below this line
  for (var i = 0; i < contacts.length; i++) {
    if (contacts[i].firstName === firstName) {
      if (contacts[i].hasOwnProperty(prop)) {
        return contacts[i][prop];
      } else {
        return "No such property";
  return "No such contact";
// Only change code above this line

// Change these values to test your function
lookUpProfile("Akira", "likes");


You have a parameter named name, but you reference a variable named firstName. The reference to firstName causes a Reference Error, because firstName is not defined.


OMG. thanks!! thats why I was getting the firstName is not defined error. good to go!


I feel like the regular expressions section could use more detailed explanations for why the Regex does what it does.

For example, the part that explains what “lookaheads” are is confusing me quite a bit. FCC says a lookahead tells JavaScript to look-ahead in your string to check for patterns further along, but then says it doesn’t actually match?
It then lists an example of how to validate a 3-5 character password that has at least one number, and I do not understand the why behind why this regex works, if it isn’t actually ‘matching’ the pattern.
/(?=\w{3,6})(?=\D*\d)/ .
Are lookaheads meant to be used when you want to match more than one pattern in a string? If so, typically would you use at least two or more lookaheads?


@RHoneyman87, That’s a good question. I think the use-case that’s being described in the Positive and Negative Lookahead challenge is one where the regex is validating the password, not returning matches for it. If I’m understanding it correctly, a regex that uses lookaheads for something like this is meant to return true or false, not an actual match. This is why the code in the challenge uses .test() instead of .match():

let result = pwRegex.test(sampleWord);

It’s not clear to me how to use lookaheads to aid in matching strings. :question: Maybe someone else can help with that. An example would be helpful.

I agree. That said, I found the regex section to be pretty good when I combined it with the RegExr and regex101 tools. Some of the challenges are just a matter of typing a word or two, others are more complicated and require more thought. Overall, I enjoyed the section and I learned a lot, both about regular expressions and about the regular expression tools. :hammer_and_wrench: :

If you or others are interested in more regex practice, here are some games and exercises:

For those interested in JavaScript security and regex, the freeCodeCamp YouTube channel recently posted a great video entitled Writing Secure JavaScript. At about the 12:18 mark, the presenter talks about denial-of-service attacks taking advantage of regular expressions (ReDoS) using Catastrophic Backtracking.

One way to prevent this:

To prevent catastrophic backtracking, you want to keep an eye out for anytime you’re using ‘+’ or ‘*’ operators within proximity to each other. If you are, chances are they’re going to end up in the type of tug-of-war that results in catastrophic backtracking. Make sure that both operators are in fact necessary. You can also consider replacing one of them with a limited set.



@RHoneyman87 @camper, I struggled with this quite a bit and I think I understand it now.

Generally, a RegEx expression used within the .test method asks the question ‘does anything in this string match expression regex?’. A lookahead pattern adds to this question and asks ‘does anything in this string that matches expression regex also have a match to expression lookahead further up in the string?’.
In both cases, what you want in return is just the part that matches regex and not the part that matches lookahead.

So when used with the .match method, the example below returns "Regular ", not “Regular expressions”.

let ourStr = "Regular expressions";
let ourRegex = /Regular (?=expressions)/;

But if you change the expression to the one below, you will get null.

let ourStr = "Regular expressions";
let ourRegex = /Regular (?=stuff)/;

What these examples demostrate is that even though I only get the word "Regular " returned, I will still only get it if there is the word “expression” somewhere further up (hence the name lookahead) in the string.

BTW, it should be clarified that a lookahead doesn’t really look for a match anywhere in the string ahead by default. It will look for a match right ahead of the previous part of the expression. That’s why I had to include the space in my regex, here:
/Regular (?=expressions)/;.
If you wish to look for the lookahead part anywhere further up in the string, you will have to add .* (period and asterisk) at the beginning of the lookahead statement, like this:
Adding it before the lookahead statement will return the whole string up till the lookahead, like this:

I hope that clarifies it and that this is the correct explanation :blush: . I learned a lot while answering so thanks for asking :clap: .


@yoizfefisch Awesome answer! I think it should be added to the challenge. :white_check_mark:

So, would using the following regex and using .match() be a way to return the string that meets the criteria in the challenge example?



@camper @yoizfefisch
Thanks to both of you! Your explanations definitely helped.
I just started studying again this evening and the very next regex challenge Reuse Patterns Using Capture Groups also wound up confusing me! I figured it out this time.

It mentioned that you can wrap a regex in parentheses to find repeat substrings, and listed an example using \1 to repeat the (\w+) capture group. The challenge is to use two capture groups. I thought that you just had to use \2! Turns out \1 is literally pointing to the first capture group used. So you can use \1 over and over again to repeat the regex found in the first capture group. Using \2 would point to a second capture () group, not just use the same capture group twice. Hopefully if someone else gets confused by that as well and comes here, they’ll get it.


@camper What you are trying to do is get all the characters after any charcter that satisfies the lookahead. In this case it should be the complete string since the expression starts with the lookahead.

However, you are breaking the upper limit of 3-6 characters by adding a wildcard period and a 0-or-more asterisk…
It’s actually an interesting question and if anyone can think of a way to return the password with .match alone, I would love to hear.


In the ES6 module talking about const, what are the rules regarding capitalization? The module mentions capitalizing but often does not. Shouldn’t we always capitalize const or did I miss something?


I’ve been working on several different React tutorials all of which use ES6 and none of them are using capitals for their const. In https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20%26%20beyond/ch2.md
he says

Essentially, const declarations enforce what we’ve stylistically signaled with our code for years, where we declared a variable name of all uppercase letters and assigned it some literal value that we took care never to change. There’s no enforcement on a var assignment, but there is now with a const assignment, which can help you catch unintended changes

but he doesn’t capitalize in the example…