React/Redux

Question 1

Describe how React modifies the DOM and responds to changes.

Answer 1

What is the Virtual DOM?
The virtual DOM (VDOM) is a programming concept where an ideal, or “virtual”, representation of a UI is kept in memory and synced with the “real” DOM by a library such as ReactDOM. This process is called reconciliation.

This approach enables the declarative API of React: You tell React what state you want the UI to be in, and it makes sure the DOM matches that state. This abstracts out the attribute manipulation, event handling, and manual DOM updating that you would otherwise have to use to build your app.

Since “virtual DOM” is more of a pattern than a specific technology, people sometimes say it to mean different things. In React world, the term “virtual DOM” is usually associated with React elements since they are the objects representing the user interface. React, however, also uses internal objects called “fibers” to hold additional information about the component tree. They may also be considered a part of “virtual DOM” implementation in React.

Is the Shadow DOM the same as the Virtual DOM?
No, they are different. The Shadow DOM is a browser technology designed primarily for scoping variables and CSS in web components. The virtual DOM is a concept implemented by libraries in JavaScript on top of browser APIs.

What is “React Fiber”?
Fiber is the new reconciliation engine in React 16. Its main goal is to enable incremental rendering of the virtual DOM. Read more.

Question 2

What is virtual DOM?

Answer 2

The DOM stands for Document Object Model and is a tree structure in which each node is an object that represents an HTML element. As nodes of the tree are manipulated, the corresponding HTML on the webpage is changed. The DOM provides us an API to traverse and change nodes. It is accessible through document.

The virtual DOM (VDOM) is a programming concept where an ideal, or “virtual”, representation of a UI is kept in memory and synced with the “real” DOM by a library such as ReactDOM. This process is called reconciliation.

The issue and relevance to our understanding of React is that as web pages grow in size, the DOM becomes more expensive to manage and traverse. This is where the Virtual DOM comes in.

The virtual DOM is a simpler and faster abstraction of the HTML DOM. While it might be more expensive to manage two DOMs in some respects, being able to traverse and perform operations on the virtual DOM saves React from having to have costly interactions with the real one, only updating it when it absolutely needs to.

Question 3

Describe React:

Answer 3

Declarative:
React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.

Declarative views make your code more predictable and easier to debug.

Component-based: Build encapsulated components that manage their own state, then compose them to make complex UIs.

Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.

Question 4

What is ReactDOM?

Answer 4

React elements are plain objects.

We render elements by passing in a getElemebtById(“root”) into the reactDOM.render function.

Question 5

Lifecycle methods: ComponentDidMount

Answer 5

This function will be called only once in the whole life-cycle of a given component and it being called signalizes that the component — and all its sub-components — rendered properly.

Since this function is guaranteed to be called only once it is a perfect candidate for performing any side-effect causing operations such as AJAX requests

Here is where you load in your data.

You can’t guarantee the AJAX request won’t resolve before the component mounts. If it did, that would mean that you’d be trying to setState on an unmounted component, which not only won’t work, but React will yell at you for. Doing AJAX in componentDidMount will guarantee that there’s a component to update.

ComponentDidMount is also where you can do all the fun things you couldn’t do when there was no component to play with. Here are some examples:

draw on a element that you just rendered
initialize a masonry grid layout from a collection of elements
add event listeners
Basically, here you want to do all the setup you couldn’t do without a DOM, and start getting all the data you need.

Most Common Use Case: Starting AJAX calls to load in data for your component.

Can call setState: Yes.

Question 6

Lifecycle methods: componentWillUnmount

Answer 6

Use this function to “clean up” after the component if it takes advantage of timers (setTimeout, setInterval), opens sockets or performs any operations we need to close / remove when no longer needed.

Here you can cancel any outgoing network requests, or remove all event listeners associated with the component.

Basically, clean up anything to do that solely involves the component in question — when it’s gone, it should be completely gone.

Can call setState: No.

Seems to clean up all the async stuff

Question 7

Lifecycle methods: shouldComponentUpdate(nextProps, nextState, nextContext)

Answer 7

By default, all class based Components will re-render themselves whenever the props they receiver, their state or context changes. If re-rendering the component is computation heave (e.g. generating a chart) or is not recommended for some performance reasons, the developer is given access to a special function which will be called in the update cycle.

This function will be called internally with next values of props, state and object. Developer can use those to verify that the change requires a re-render or not and return false to prevent the re-rendering from happening. In other case, you are expected to return true.

shouldComponentUpdate should always return a boolean — an answer to the question, “should I re-render?” Yes, little component, you should. The default is that it always returns true.

But if you’re worried about wasted renders and other nonsense — shouldComponentUpdate is an awesome place to improve performance.

I wrote an article on using shouldComponentUpdate in this way — check it out:

But keep in mind that it can cause major problems if you set it and forget it, because your React component will not update normally. So use with caution.

Most Common Use Case: Controlling exactly when your component will re-render.

Can call setState: No.

Question 8

Lifecycle methods: componentWillUpdate(nextProps, nextState)

Answer 8

If the shouldComponentUpdate function is not implemented, or it decided that the component should update in this render cycle, another life-cycle function will be called. This function is commonly used to perform state and props synchronization for when parts of your state are based on props.

In cases where shouldComponentUpdate is implemented, this function can be used instead of componentWillReceiveProps as it will be called only when the component will actually be re-rendered.

Similarly to all other componentWill* functions, this function might end up called multiple times before render so it it not advised to perform side-effects causing operations here.

Functionally, it’s basically the same as componentWillReceiveProps, except you are not allowed to call this.setState.

If you were using shouldComponentUpdate AND needed to do something when props change, componentWillUpdate makes sense. But it’s probably not going to give you a whole lot of additional utility.

Most Common Use Case: Used instead of componentWillReceiveProps on a component that also has shouldComponentUpdate (but no access to previous props).

Can call setState: No.

Question 9

Lifecycle methods: componenetDidUpdate(prevProps, prevState, prevcontext)

Answer 9

This function will be called after render is finished in each of the re-render cycles. This means that you can be sure that the component and all its sub-components have properly rendered itself.

Due to the fact that this is the only function that is guaranteed to be called only once in each re-render cycle it is recommended to use this function for any side-effect causing operations. Similarly to componentWillUpdateand componentWillReceiveProps this function is called with object-maps of previous props, state and context, even if no actual change happened to those values. Because of that developers are expected to manually check if given value changed and only then perform various update operations:

Here’s why: in componentDidUpdate, you don’t know why it updated.

So if our component is receiving more props than those relevant to our canvas, we don’t want to waste time redrawing the canvas every time it updates.

That doesn’t mean componentDidUpdate isn’t useful. To go back to our masonry layout example, we want to rearrange the grid after the DOM itself updates — so we use componentDidUpdate to do so.

Most Common Use Case: Updating the DOM in response to prop or state changes.

Can call setState: Yes.

Question 10

Lifecycle methods: componenetWillReceiveProps(nextProps)

Answer 10

This function will be called in each update life-cycle caused by changes to props (parent component re-rendering) and will be passed an object map of all the props passed, no matter if the prop value has changed or not since previous re-render phase.

This function is ideal if you have a component whose parts of state are depending on props passed from parent component as calling this.setState here will not cause an extra render call.

Please keep in mind that due to the fact that the function is called with all props, even those that did not change it is expected the developers implement a check to determine if the actual value has changed, for example:

Perhaps some data that was loaded in by a parent component’s componentDidMount finally arrived, and is being passed down.

Before our component does anything with the new props, componentWillReceiveProps is called, with the next props as the argument.

we have access to both the next props (via nextProps), and our current props (via this.props).

Here’s what we should do:

check which props will change (big caveat with componentWillReceiveProps — sometimes it’s called when nothing has changed; React just wants to check in)
If the props will change in a way that is significant, act on it

Question 11

componentDidCatch(errorString, errorInfo)

Answer 11

A new addition in React 16 — this life-cycle method is special in way that it can react to events happening in the child component, specifically to any uncaught errors happening in any of the child components.

With this addition you can make your parent-element handle the error by — for example — setting the error info in state and returning appropriate message in its render, or logging to reporting system, e.g.:

Question 12

Why use lifecycle methods?

Answer 12

The beauty of React is the splitting of complicated UI’s into little, bite-sized bits. Not only can we thus compartmentalize our app, we can also customize each compartment.

Through lifecycle methods, we can then control what happens when each tiny section of your UI renders, updates, thinks about re-rendering, and then disappears entirely.

Question 13

componentWillMount

Answer 13

connecting to external API’s. For example, if you use Firebase for your app, you’ll need to get that set up as your app is first mounting.

But the key is that such configuration should be done at the highest level component of your app (the root component). That means 99% of your components should probably not use componentWillMount.

You may see people using componentWillMount to start AJAX calls to load data for your components. Don’t do this. We’ll get to that in the second.

Most Common Use Case: App configuration in your root component.

Can call setState: Don’t. Use default state instead.

Question 14

Redux: The Single Immutable State Tree

Answer 14

We are represented the whole state of our application as a Javascript object.

All mutations and changes are explicit and they’re easily trackable in the state tree.

This is a big reason WHY we use Redux.

Question 15

Redux: Describing State Changes with Actions

Answer 15

The state tree is read only. We cannot modify or write it.

Any time we want to change the state, we need to dispatch an action. The action is a POJO that describes the minimal representation of the data (state) in our app.

Actions need to have a type property (not undefined) - its recommended to use strings because they are serializable.

They are the middleman between the components and database. To toggle the state, we need only dispatch an action to get the desired data.

Question 16

Redux: Pure and Impure Functions

Answer 16

Pure Functions:
Functions whose values rely solely on the values of the arguments. Do not have any observable side effects. We will always get the same values and do not modify values passed through them.

Impure functions:
May call DB or network or have side effect.
May override value passed through

Redux functions have to be pure.

Question 17

Redux: Reducer Function

Answer 17

Pure function that takes the mutations of our previous state and action being dispatched and returns the next state of our application.

We don’t have to change reference points from our previous versions when updating our new state. Only the relevant data will be effected.

Question 18

Redux: Writing a Counter Reducer with Tests

Answer 18

make a function and pass in the state and actions.
The actions will contain an argument with a type.
Within the function, do a case/when and decide how to modify the state based on action.type

Question 19

Redux - Store: getState(), dispatch(), subscribe()

Answer 19

The store binds together the three main principles of Redux.

It holds the current application state objects,
It dispatches actions,
when we create it, we need to specify the reducer which tells how the state is updated by actions.

3 methods:

getstate - retrieves current state of redux store.
dispatch - dispatch actions to change the state of our app
subscribe - lets us register a callback any time an action has been dispatched.

Question 20

Redux: Avoid mutations of State

Answer 20

1) Object.freeze(state)
2) Use Object.assign({ }, actions that we want)
or merge({},actions wanted)

Question 21

How does {combineReducers} work

Answer 21

const combineReducers = (reducers) => {
return (state = {}, action) => {
return Object.keys(reducers).reduce(nextState, key) => {
    nextState[key] = reducers[key](
            state[key], 
            action
      ); 
     return nextState;
     },{}
    );

};
};

Question 22

Thinking in React: 5 best practices to abide by.

Answer 22

Start with a mock.

1) Break the UI into a component hierarchy
how do you know what should be its own component? Just use the same techniques for deciding if you should create a new function or object. One such technique is the single responsibility principle, that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents

2) Build a Static Version in React
The easiest way is to build a version that takes your data model and renders the UI but has no interactivity. To build a static version of your app that renders your data model, you’ll want to build components that reuse other components and pass data using props. props are a way of passing data from parent to child. If you’re familiar with the concept of state, don’t use state at all to build this static version. State is reserved only for interactivity, that is, data that changes over time. Since this is a static version of the app, you don’t need it.
React’s one-way data flow (also called one-way binding) keeps everything modular and fast.

3) Identify the minimal representation of UI state
to make your UI interactive, you need to be able to trigger changes to your underlying data model. React makes this easy with state.

To build your app correctly, you first need to think of the minimal set of mutable state that your app needs. The key here is DRY: Don’t Repeat Yourself. Figure out the absolute minimal representation of the state your application needs and compute everything else you need on-demand. For example, if you’re building a TODO list, just keep an array of the TODO items around; don’t keep a separate state variable for the count. Instead, when you want to render the TODO count, simply take the length of the TODO items array.

4) Identify where your state should live
OK, so we’ve identified what the minimal set of app state is. Next, we need to identify which component mutates, or owns, this state.
Remember: React is all about one-way data flow down the component hierarchy. It may not be immediately clear which component should own what state.
For each piece of state in your application:

Identify every component that renders something based on that state.
Find a common owner component (a single component above all the components that need the state in the hierarchy).
Either the common owner or another component higher up in the hierarchy should own the state.
If you can’t find a component where it makes sense to own the state, create a new component simply for holding the state and add it somewhere in the hierarchy above the common owner component.

5) Add inverse data flow (if needed)
In the parent, create an onChange event handler. have the change function alter state as you see fit. pass this function in as props to the child component. create another onchange handler in the child component. have it invoke the prop change function passed from the parent, and pass into the prop e.target.value