MB Burch mbburch

Use this gist to write down notes and questions as you read through the lesson plan. https://github.com/turingschool/lesson_plans/blob/master/ruby_04-apis_and_scalability/react_in_theory.markdown

What does React do?

It's used to create user interfaces. Small components that present data. Tells HTML what to render and how to respond to events. (?Well structured component tree?) Clarify how different from regular JS and JQuery? Unclear.

How does React interact with the DOM?

Each component has a render function. It executes the code and renders the JS and HTML in the return statement. ?Virtual DOM? React listens for state changes (data that can change) and re-renders it (in contrast to polling the data). When setState is called in a component, React knows to re-render it. (?Clarify mounted on the DOM?)

Step One: Watch Mary Rose Cook Live Codes Space Invaders from Front-Trends. (The second worst conference name ever?)

Step Two: Fork this gist.

Step Three: Respond to this question in your fork: What is one approach you can take from this Mary's code and implement in your project?

Step Four: Totally Optional: take a look at some of the other forks and comment if the spirit moves you.

That was super cool to watch! I thought her explanation of tick and updating was really clear. I also thought it was interesting that the bodies array held three different object types. I think I have a few takeaways I'd like to hang on to.

Step One: Watch Writing Testable JavaScript - Rebecca Murphey from Full Frontal 2012 (award for worst conference name ever?)

Step Two: Fork this gist.

Step Three: Respond to this question in your fork: Consider the four responsibilities that Rebecca lists for client side code (hint: they're color coded). Respond below with your thoughts. Did any of the responsibilities that she lists surprise you? Do you feel like you mentally split your client side code in IdeaBox and other past projects into these responsibilities?

I had a few good takeaways from this, but it really wasn't that easy for me to separate what she was talking about into the four responsibilities. I don't feel like my IdeaBox in any way split this up, and I'd love to try refactoring it as a practice exercise. I think in Rails apps I had gotten to the point of splitting things up nicely in the models, views, and controllers, and this talk made some points that I could connect to that

I can explain how the new keyword changes the way a function behaves. 2

I can explain the implicit steps that happen in my function when I use the new keyword. 2

I can explain the difference between an object's prototype and the prototype property on the constructor function. 2

I understand how to place method on a prototype.

I can explain the difference between function declarations and function expressions. 3

I can explain what the value of this is in a normal function. 3

I can explain what the value of this is when called from the context of an object. 3

I can explain how to explicitly set the value of this in a function. 2

I can explain the difference between call and apply. 3

Array Prototype Methods

I understand that functions in JavaScript can take any number of arguments. 3

I can describe the similarity between blocks in Ruby and anonymous functions in JavaScript. 2

Where are the methods available to all arrays (e.g. forEach, map, etc.) defined? Array.prototype

	Respond to this question in your fork: "What are some of the balances and trade offs between different sorting algoritms?"

	Steve, did you make us watch this solely because they refer to "JerseyScript"??

	- Lexicographical sort: if you just call sort on an array of numbers using js sort, (Array.prototype.sort), it doesn't sort by value but lexicographically. Computer doesn't know they are integers unless we tell it. Need to give (a, b) as args and return (a-b) for ascending sort.

	-Important characteristics of sorting: stability, runtime analysis, implementation
	-stable sort maintains relative order with items that are equal
	-runtime analysis compares time and complexity of sorting algorithms. helps determine best sorting algorithm. Big O is worst case.