bringing it all together
Discuss in words something you learned in class today or this week.
check my last blog
Explain the use cases for, and differences between — bind, apply and call.
this gets pretty in-depth depending on your level of understanding of the concept of this in JavaScript.
assuming that you fully understand that:
.bind() will bind this to an object of your choice, even when it is called outside of that context (where it was first defined in some method on a different object). it is used for a later callback (as you create a new variable to bind).
.call() does the same thing except you don’t have to create a new variable, as it is used immediately. additionally, its first argument indicates which object’s context this refers to, and the remaining arguments represent the arguments to whatever function you’re calling, if it has any.
.apply() does the same thing as .call(), except it accepts an array of arguments as a second argument (after the first argument which indicates the context for this, if necessary).
notice how the function is applied to each item from a given array. by contrast, check out .call():
the arguments are passed directly to .call()’s parameters, simply separated by commas.
important to note, however, is that ever since ES6, with arrow functions, these methods are not exactly necessary. one can simply call on a method which references this, and return it as an anonymous callback:
onClick={() => someMethod()}
which works because arrow functions do not bind to the this keyword, so this will always reference its caller (which greatly simplifies such callback patterns).
but you will certainly continue to see classic patterns as well.
How do you handle code organization?
prettier handles that for me (in terms of formatting) and as a React developer using redux to handle state, i have a folder for components, their containers, and redux itself. my components folder may have further folders to organize my components depending on the app (like layout components for example).
i use Router.js to render all of my components that have a pathname, and then i wrap my <Router />, its navbar and similar components like a footer, etc. inside redux’s <Provider />, which is all wrapped up in my <App /> component in App.js.
obviously, organization is extremely project-dependent.
How do you handle dependency management?
package.json and package-lock.json handle that for me.
What is React.cloneElement? And the difference with this.props.children?
this.props.children is a reference to each of the children elements to some component (assuming it’s a class-based component, otherwise it would be just props.children). if you wanted to reuse those particular children, you could display them by referencing them with, for example:
buttons = this.props.children
However, this.props.children is read-only, which means you cannot update their state with that reference alone. but, as long as you map over it properly (using the React.Children API), you can wrap your props.children functionality in React.cloneElement to return a new, alterable state… which React can now properly track, without side effects.
for some syntax and context, there’s no replacement for the official documentation:
Walk us through the process of creation of an application or website you’ve built.
TBA
What are the differences between functional and imperative programming styles, and explain your preference, if any.
these are 2 sides to the same coin. in order for a program to be a program, it must contain an executable set of instructions. that is imperative programming: telling the computer what to do step by step (as in, it is imperative that you do this, and then do that). however, once you abstract that set of instructions and then name (declare) it — as some variable —it becomes a function that returns a value. you can now reuse that bit of code simply by calling it inside of other code, and you are using functional programming.
obviously, we would all prefer if there was already a function that did all the things we want the computer to do. but even telling the computer to run said function is itself imperative, so there is no escape from imperative programming.
however, it is best to write composable code, which implies using pure functions that always return the same value given the same arguments. this just makes it easier to build stuff without repeating ourselves constantly.
for example, instead of telling your robot every single step to go pick up your mail, as in:
- face door
- place hand on lock
- rotate lock counter-clockwise and move hand to knob
- rotate knob counter-clockwise and pull door open
- goto sidewalk and face east
- proceed 10 yards and stop
- etc.
you can just wrap all these instructions inside of getMail() and now you can type 9 characters whenever you want to fetch the mail. and if you want more flexibility, you can pass in variables as arguments. for example, getMail(house1, tuesday)where the first argument takes in a certain address and the second argument takes in the day it should pick it up.
— please feel free to correct any information i have misunderstood, misapplied, or even worse, misquoted.
