Congratulations! You’ve graduated from the Flatiron program! That took a lot of work!
But wait, there’s more work to be done! There is a treasure of information that has been curated to help you learn some of the things that weren’t covered in the curriculum. These aren’t just the resources and information you’ll need to know to be effective at your job search (Flatiron provides a ton of great information on that, too!). These are the topics that Computer Science majors learn that cover things related to how a computer operates, stores data, allocates memory, etc. You’ll need all of this information in order to feel more confident moving forward.
Generally, students graduating with CS degrees have a deeper understanding of how a computer works, but less experience actually building applications, whereas students graduating from bootcamps have more experience building things, and less understanding/exposure to how computers actually make it all happen.
That’s where the graduate access to additional Flatiron tracks (like Computer Science) comes into play. But before we talk about that, I want to make a suggestion:
After you graduate, I strongly suggest working through the whole Career Prep track, beginning to end. Then go back and review each lesson as it pertains to your current job search situation. There is a LOT of fantastic resources and important instructions throughout the track, but the latter part of the track includes suggestions and topics you’ll want to get started learning about before you are too far along in your job search. These are covered in the Computer Science track.
So, if you’re thinking that you’re done with Flatiron, and can run out there and land your dream job right now, I’m going to spoil it for you. You’ll be competing for jobs with CS grads, and you’ll be asked about those CS topics as well. Why? Because you need to know how a computer executes and handles data in order to write your programs in a way that caters to things like speed and memory. Users don’t like sites that take forever to load information, and businesses don’t like to waste resources on endless storage needed to run their applications. You need to understand these trade offs.
If you’re thinking that you don’t need to do the additional tracks on Learn, then I hope you already understand what Big O notation is, can determine how to calculate it and express it in terms of runtime and space, and understand what Log n is. Do you know what a Linked List is and why it is used? How do Linked Lists and Arrays differ when storing information? Did you know that Arrays and Linked Lists have different impacts on Big O? And there’s more, like Trees and Binary Trees…
Simply put, Big O is used to describe the running time or space requirements of executing an algorithm as the size of the input to the algorithm increases. The differences between two functions that do the same thing, but in different ways (like iteration vs. recursion), becomes very clear when you consider very large datasets passed into the algorithm.
Liked lists are like arrays, but an array takes up a continuous portion of memory, so each element in the array is next to each other. So, imagine changing an element in the beginning of the array. It’s very likely that the space in memory right before (and after) the array is already being taken up by some other, unrelated data. So in order to keep all the elements grouped together next to each other in memory, you’ll need additional space and would have to move them all to a new location big enough to hold them all together. This is where linked lists come in. Each element in a linked list is in it’s own location in memory, and points to where in memory the next element is located. With this setup, each element only requires one space, so adding or removing an element in the list only involves updating the information pointing to the next element.
Now, don’t be intimidated by these new terms and topics. Flatiron taught us how to build things we weren’t able to build before the program. Their CS track will teach you about the computer science topics you’ll need to understand, too. That’s why I strongly suggest working through the Career Prep and Computer Science tracks immediately after graduation. Yes, take a moment and really celebrate your accomplishment, we all deserve that after putting in the hard work. But then go back, focus and work through the rest… You’ll be very glad that you did!
SPA’s (or Single Page Apps) are exactly as the name implies. Instead of serving multiple pages for different content, like index, about, contact, portfolio for example, an SPA only serves the index.html page. Within this one page can be different content, so when the user clicks a link in the nav bar at the top of the page, the link scrolls to the target anchor point on the page where that content lives.
Normally, clicking that link would cause a sudden, jerking movement to the requested anchor point on the page. But users expect a better quality experience from websites today, so this just wouldn’t be okay. Instead, try using a smooth scroll to your anchor point.
Smooth scrolling can be accomplished several ways, like if you want to set smooth scrolling for your whole site, just add this to your CSS file:
html {
scroll-behavior: smooth;
}
In React, you can add the react-scroll package to your project and set the smooth attribute of your <Link> to true. You can also set additional attributes like duration, which controls how long it takes to scroll to the anchor point, and offset which is like padding and allows you to scroll additional px (like to accommodate a fixed nav bar height).
While smooth scrolling is almost an expected behavior by users for some sites, it also comes with a couple downsides, too. For instance, if your user is navigating quickly between points on your site, a slow scroll can become frustrating. Another issue can be accessibility. You’ll need to accommodate for users that rely completely on a keyboard to navigate your site. So, when this user follows a link, the keyboard focus should follow it.
There’s also the normal browser behavior that should be maintained, like being able to go back using the browser back button, or being able to copy/paste a URL and having the browser navigate to the last specific location. There is a great post on CSS-Tricks (link below) that walks through these issues and provides some demos.
Additional references:
Smooth Scrolling and Accessibility on CSS-Tricks
React-scroll on npm
Scroll-behavior on MDN
Recursive functions can certainly be confusing, and base case isn’t always explained well, either. Let’s take a look at what a recursive function is, how it executes, and where the base case comes into play.
Wikipedia’s definition of recursion is:
Recursion in computer science is a method of solving a problem where the solution depends on solutions to smaller instances of the same problem.
… and their definition for base case is:
A terminating scenario that does not use recursion to produce an answer
A recursive function is one that calls itself repeatedly until it reaches the base case, then the base case simply returns an answer/value because it is evaluated after the last recursion.
Let’s say that you want to add all the numbers from 1 to n. This can be broken down into the same repeated step of adding each number to the next, repeated until you reach the last number. When you reach the last number, you can just return the number. This is your base case.
Let’s look at an example:
function sumToN(n) {
if (n > 1) {
return n + sumToN(n - 1)
} else {
return n;
}
}
Now let’s walk through calling this function and set n as 5. As the function calls itself until it hits the base case, it would be the equivalent to the following steps:
1. return 5 + sumToN(4)
2. return 4 + sumToN(3)
3. return 3 + sumToN(2)
4. return 2 + sumToN(1)
5. return 1 // base case, just return the value here.
// Now that there is a value, the function then fills in the calculations going back up the stack:
6. return 2 + 1 // equals 3
7. return 3 + 3 // equals 6
8. return 4 + 6 // equals 10
9. return 5 + 10 // equals 15
I hope that this helps simplify what recursion does, visually, and makes base case easier to understand!
When learning JavaScript, scope can be confusing to understand. Without understanding scope, you can experience unexpected behavior in your code.
Take a look at the following code snippet. What do you think will be logged to the console?
let word = ‘outside';
function logWord(){
console.log(word);
let word = ‘inside';
};
logWord();
I’ll give you a hint: it won’t log ‘outside’. It won’t log ‘inside’. And guess what, it won’t throw an error.
What’s the answer? It will log ‘undefiined’ to the console. This is because of functions create their own, or a new, scope.
let word = ‘outside’;
// global scope
function logWord(){
// new scope starts here, so variables declared inside won’t be available outside the function
console.log(word);
let word = ‘inside';
};
To understand this better, we should go over declaration vs. assignment.
Declaration vs. Assignment
Declaration is simply that, declaring that a variable exists. This does not include the assignment of its value. It only initializes the variable and by default sets its value to ‘undefined’.
let word
// word is assigned a value of 'undefined' by default
We could also declare the variable and assign its value at the same time:
let word = ‘outside’
In JavaScript, variable declarations are hoisted to the top of their scope, but their assignments are not, so their values are set to ‘undefined’ by default.
Let’s rewrite our code to reflect the way it is read:
let word = ‘outside’;
function logWord(){
let word // word is declared and assigned a value of ‘undefined'
console.log(word);
word = ‘inside’; // word is assigned a value of ‘inside’
};
So when we hit the console.log() line in our function, the value of word is ‘undefined’, until the next line in the function which assigns the value of word to ‘inside’. Therefore, the console statement will log ‘undefined’.
The best way to avoid unexpected behavior in your code is to declare your variables at the top of their scope.
Event delegation allows attaching an event listener to a parent node/element, rather than directly to the element itself.
To understand event delegation, we first need to know what event bubbling is. Event bubbling is the process where an event (a mouse click, for example) “bubbles” up through all its parent elements, or nodes. This is also event propagation, when the event (click) propagates up the DOM, and can be “heard” by all its parent elements. You can “listen” for the event by setting an event listener. An event listener is when we listen for actions that happen on an elements, in order to then execute a function. The event itself contains information about what happened (like what element/node was clicked).
For example:
```
const parentNode = document.getElementByID(“parentIdName”)
parentNode.addEventListener( “click”, () => { doSomething(event) } )