Notes from Tim & Austin Pairing

pairingNotes_20150622.js

/*

BIG TAKEAWAY LESSON:

* stop and ask yourself: "WHAT PROBLEM AM I TRYING TO SOLVE RIGHT NOW"
* particularly when the code starts pushing you around

* you can tell the code is pushing you around when:
  * things are breaking
  * you start chasing frantically from error message to error message
  * you are wildly careening through various console loggings, none of which seem to make that much sense, none of which are testing a specific hypothesis that you can clearly articulate to yourself
  * you lose perspective on what you were originally trying to do
  * answers to problems are occuring to you in terms of data structures or error messages instead of an original big-picture intent that you went into the session trying to accomplish

* with regards switching to flux:
  * we ask ourselves: "what problem is this trying to solve"
  * we answer "ease of reasoning where change happens because that's getting hard as i thread things through multiple layers of the code"
  * so, in order to avoid jumping to an answer that doesn't address our question (or jumping from tool to tool, which just creates more confusion), as we reach to flux, we should be examining it to hold it accountable to standards like:
    * "is it easier to reason about my code? how? why?"
    * "am i threading less things through less places?"
    * "is the cost of setting up this architecture less than the cost of getting confused about threading?"
    * in sum: "do i know what problems this structure is solving?"

* with regards debugging:
  * "what problem am i trying to solve" is super important!
  * we were jumping around 5 different files and overlooked the fact that the problem was in an incorrectly named method call in the first file we looked at
  * careful retracing of steps, asking at each step "what problem is this line of code trying to solve?" unearthed the bug
  * same thing as you write code. step by step. keep your problem statement in mind. don't write any line of code if you don't know what problem it's trying to solve.

ON FLUX:

* record and report facts
  * view -> facts -> state change -> facts -> view

* actions -> stores -> component is a pipeline
* the ends of the pipeline are stupid
  * actions just dispatch, components just render
  * they can put stuff into or get stuff out of the pipe, but not alter its internal workings
* the middle of the pipeline is smart
  * all change happens in the stores
  * the stores are the "source of truth"

* actions should be written in the past tense
  * "something that happened in the news"
  * stores can subscribe to multiple newspapers and update themselves accordingly
  * components do whatever stores say via fetching

* reducing complexity from O(n) to constant time
  * direct access to the stores and action dispatchers is in the same family of "important concepts in computing" as dependency injection
  * by giving any layer of a deeply nested heirarchy direct access to important information that might change, we save the programmer a linear amount of "thought complexity" spent iterating over all the layers of the heirarchy "O(n)" where n is the number of layers, and allow the programmer to spend a constant (short!) amount of time thinking about where to get some information from or where to put it, no matter what level of the heirarchy she or he is currently in
  * and yet we still don't maintain mutable global state, because of our "pipeline" structure
  * this is a good pattern! let's remember it!
*/

// TIPS AND TRICKS

//variables as keys
var key = 'a';
var obj = { a: 1, b: 2};
obj[key];

// hiding through diffing base
var tweetStore = {
  tweets: [1,2,3,4],
  groups: [ [1], [2], [3,4]],
  hides:[ 2,3]
};
getShown(allTweets, hides);

// using object as switch statement

tweets.map(function(tweet){
  return {
     single: <SingleTweetContainer docs={tweet.docs} />,
     grouped: <GroupedTweetContainer docs={tweet.docs} />
  }[tweet.props.type];
});

// functions as values (aka 'lambdas')
function add1(n){ return n + 1;}
var nums = [1,2,3];
var otherNum = 99;

nums.map(add1); // === nums.map(function(n){ return add1(n)}) b/c function(x){ return f(x)} === f
nums.map(function(num, otherNum){ return add(num); });
add(1);

// binding to smuggle arguments in

//given:
class MyComponent{
  _handleNavClick(someId){ doSomethingWithId();}
}

//in a render block:
someElements.map(
  el => <SomeComponent onClick={this._handleNavClick.bind(this, el.id)} />);

// no magic numbers!
//instead of:
var display = new Display({ zoom: -1.5 * 8 });

//do:
var display = new Display({ zoom: shrinkFactor * nativeSize });


// no magic conditional tests!
//instead of:
if (User.isLoggedIn === true && SpecialBox.isClicked === true){ showThing();}

//do:
if (showConditionsMet(User,SpecialBox){ showThing(); }

function showConditoinsMet(user, specialBox) { user.isLoggedIn && specialBox.isClicked }

// avoid null/undefined checks!
// name a case for the EmptyWhatever, and have rules for how your logic should respond to it!

// instead of:
//(in render function)
tweets.map(function(tweet){
  if (tweet.props.elements.length > 1 || tweet.props.elements != undefined) {
    return <TweetContainer docs={tweets.docs} />;
  }
  return null;
});

//do:
tweets.map(function(tweet){
  return {
    single: <SingleTweetContainer docs={tweet.docs} />,
    grouped: <GroupedTweetContainer docs={tweet.docs} />,
    empty: <EmptyTweetContainer />
  }[tweet.props.type];
});

// FANCY LANG STUFF (not that important, but maybe interesting...)

// arrow functions
var maps = [];
var Component = "don't yell at me!";

//es5 style
maps.map(function(m){
  return Component;
});

// one arg, one statement
maps.map(m => Component(m+1));

// multiple args, one statement
maps.map((m,n) => Component(m));

// one arg, multiple statements
maps.map(m => {
  var n = m + 1;
  return Component(n);
});


// Immutable.js syntax

var state = Immutable.Map({a: Immutable.Map({ b: 1}), c: 3});
state.get('a'); // Immutable.Map({b: 1})

var jsState = {a: { b: 1}, c: 3};
jsState.a; // {b: 1}

jsState.a.b; // 1
state.get('a').get('b'); // 1
state.getIn(['a', 'b']); // 1