General Assembly WDI, Week 2

More JavaScript, our first encounter with Rails, and three days of AJAX.

Friday wrapped up my second week of General Assembly Boston’s Web Development Immersive program: as of this weekend, I’m one-sixth done, which is at this point mostly terrifying. How can there be only ten weeks to go?!?

I feel like I’m learning cool things (making AJAX requests that use methods other than GET, for example), but in a very, very controlled and somewhat black box-y environment. GA’s basic approach to a day of class is: pull down these git repos, run Node and/or Bundler commands, and then open up a specific file and do a specific thing. I understand why they don’t want to throw us off the deep end and go too far into things like “runtime environments” and “what is a gem” while we’re still asking questions like “what does ‘PATCH’ mean?,” but at this point I would struggle to implement what I’m learning outside of the structure of GA’s pre-packaged tooling.

To be fair, this is probably because at this point, most of us are only maybe half a step above this:

So. On to the cool stuff:

Day 6

More about fat arrow functions, which (along with template literals) remain one of my new favorite things about JavaScript:

  • The value of this doesn’t change (and can’t be changed) within a fat arrow function. this is fixed at the value it was when the function was called. (This is also known has “having only a lexical this, not a dynamic this).
  • Fat arrow functions can’t be used as Constructors: they don’t have a prototype, and they don’t have a Construct method.
  • Fat arrow functions don’t have an arguments variable.

A bunch of methods for array manipulation: .every().filter(), .forEach(), .map(), .reduce(), and .some().

Assignment using the || (OR) operator: result will be set to the first truthy value. If there are no truthy values, result will be set to the last value. Examples:

     let result = 'result' || 0;
     > 'result'
     let result = undefined || 0;
     > 0
     let result = 7 || 3;
     > 7

Apparently it’s now déclassé to set CSS styles on IDs.

A couple of cool tricks for Sublime/Atom:

  • ⌘ + ? will add an empty comment (using the correct syntax for whichever language you’re using)
  • ⌘ + multiple clicks will set multiple cursors within a document

Day 7

Building multi-row, multi-column CSS layouts from scratch: a serious weakness of mine. Ouch. Also, wireframes that don’t conform to a grid: BOOO.

There are THREE values for box-sizing: content-box (default), border-box (reasonable), and padding-box (only supported in FF.). More in CSS Tricks: Box-Sizing.

An explanation of those horrid unwanted spaces between inline-block elements.

Day 8

First time using Rails! Though only very, very lightly: we cloned the existing Rails code for a simple API and got it running locally so we could make curl and AJAX requests against it.

Some conventions for writing JavaScript:

  • “Predicate” functions return true or false. Begin names of predicate functions with “is” (isEven, isOdd, etc.).
  • Use “on” as a prefix for handlers (onGetAllBooks, onSignUp, etc.).

You can use debugger; as a standalone line in Node to set a breakpoint.

Day 9

Philip Roberts’ “What the heck is the event loop anyway?” is an excellent introduction to the JS event loop. My notes:

  • one thread === one call stack === one thing at a time (single threaded)
  • call stack: data structure. records place in the program. step into a function: add something to call stack. complete a function: pop it off call stack.
  • slow things “block” the stack b/c JS can only do one thing at at time.
  • particularly bad in JS b/c of browsers: you click on a button and get stuck, and the browser can’t return that button back to its un-depressed state. everything hangs. this is because the browser can only render when the call stack is empty.
  • callbacks get pushed to a queue when they’re ready to run, NOT to the call stack.
  • the event loop monitors the queue & the call stack. when the call stack is empty, it moves one thing from the queue to the call stack so it can run.
    • this is why callbacks passed to setTimeout with a timeout of 0 ms will run *after* lines of code that follow setTimeout. the event loop has to wait to give that callback to the call stack until the call stack is empty, even though the timeout is 0.
    • setTimeout is not a guaranteed time to execution. it’s a *minimum* time to execution, since we have to wait for call stack to clear before callback can run.

Day 10

We spent the last three days of this week on HTTP methods (GET/POST/PATCH/DELETE) and AJAX. We started by using curl requests to interact with a basic books API, then built AJAX requests to replicate that process in the browser (click on a button, send the request, handle success and failure). Day 10 focused on authentication: signing up/logging in/logging out, and doing things (changing information, viewing protected information) that require an auth token.

Coming up

Next week is our first “project week.” The challenge is to build a single-page tic-tac-toe game in JavaScript that relies on an existing Rails API to help with authentication and data storage. I’m looking forward to putting what we’ve learned over the last two weeks together into something usable, rather than a series of code snippets that aren’t connected. I feel like I have a good pile of building blocks now, and I’m excited to start using them to *build.*