discussing in words, one last time. redux-thunk, react native, commonJs, require/AMD, debugging

Discuss in words something you learned in class today or this week.

this week was more about bringing together all of 411 in one big project, and even bringing a lot of things back from 311 (like debugging, minifying, npm folder structure, etc.) and lighting them in the context of actual front-end development. i definitely learned a lot about redux in the process of tying together our final project (other than the capstone).

What is Redux Thunk used for?

straight from the horse’s mouth (redux-thunk’s github repo readme.md… that’s quite a mouthful… even for a horse):

A thunk is a function that wraps an expression to delay its evaluation.

basically, it’s for fetch requests (APIs). technically, it’s for asynchronous function calls. but those mostly boil down to fetch requests from APIs.

What is the difference between React Native and React?

React Native will compile using APIs native to the specific mobile platform it is run on, while React.js — for the web in general — uses a virtual DOM (which combines JavaScript and HTML). in React Native you don’t even have to worry about the HTML (not that you really have to in React.js either) as you simply write your entire app in JSX and React Native will render it for iOS or android, for example.

Are you familiar with AMD/require.js or commonjs? What can they do for you?

turns out i was sort of familiar with it without realizing it. commonJs is the standard specifications for importing, using, and classifying modules for JavaScript in order to import and export dependencies. for example:

// someModule.js
exports.doSomething = function() { return "foo"; };

//otherModule.js
var someModule = require('someModule'); // in the vein of node    
exports.doSomethingElse = function() { return someModule.doSomething() + "bar"; };

so now you can share JavaScript variables across files. but because it is synchronous, require.js came along to implement AMD (Asynchronous Module Definition) which is better suited for the browser environment (so that code can run while other code does stuff… without the whole page stopping while it’s doing it).

Explain your personal troubleshooting techniques. Include devtools and environments.

console.log each step. use break points in your code editor. use the debugger keyword to debug inside of the browser.

use console.log() to find out what certain variables represent at certain points in your code. you can trace the timeline of a variable to where you expected it to take on a value (but it didn’t).

break points are little bookmarks that tell your code “stop here while i inspect you” and can even allow you to step through the bookmarks while you investigate snapshots of your variables, functions, literally whatever you want. you can even step into a function and come out the other side to see what called it or what it called.

debugger is a physical line of code you write, which works exactly as breakpoints described above, except inside the browser’s inspect tools. so you can put that word by itself on a line before or after a function for example, and travel between those points inside the source tab (chrome) or debugger tab (firefox) in your browser’s inspect tools. you can add variables to a “watch list” while you step through your code and tons of other features which are a must for large applications.

troubleshooting is basically just tracing back to the scene of the crime. your error message will (hopefully) give you a hint as to the last place your code was seen alive. if it’s a variable that’s undefined, then you need to locate that variable’s most recent caller and go ask ’em some questions, see what they know.