Design Principles React
Tags: react, javascript
Published: 2021-04-08 08:16:53

#Thinking in React
Step 1: Break The UI Into A Component Hierarchy
Step 2: Build A Static Version in React
Step 3: Identify The Minimal (but complete) Representation Of UI State
Step 4: Identify Where Your State Should Live
Step 5: Add Inverse Data Flow
#Composition##
>Components written by different people should work well together. 
>It is important to us that you can add functionality to a component without causing rippling changes throughout the codebase.
>There is nothing “bad” about using state or lifecycle methods in components. 
>It may enable more functional patterns in the future, but both local state and lifecycle methods will be a part of that model.
>Components are often described as “just functions” but in my view, they need to be more than that to be useful. 
>In React, components describe any composable behavior, and this includes rendering, lifecycle, and state. 
#Common Abstraction
<a href="https://www.youtube.com/watch?v=4anAwXYqLG8" target="_blank">Resist adding features</a>
>If React didn’t provide support for local state or lifecycle methods, people would create custom abstractions for them.
>When there are multiple abstractions competing, React can’t enforce or take advantage of the properties of either of them. It has to work with the lowest common denominator.
#Escape Hatches
>React is pragmatic.
> If some pattern that is useful for building apps is hard to express in a declarative way, it will provide an imperative API for it. such as Refs and the DOM.
#Stability
>Facebook has more than 50 thousand components using React. Many other companies, including Twitter and Airbnb, are also heavy users of React. This is why we are usually reluctant to change public APIs or behavior.
>However I think stability in the sense of “nothing changes” is overrated. It quickly turns into stagnation. Instead, I prefer the stability in the sense of “It is heavily used in production, and when something changes, there is a clear (and preferably automated) migration path.”
#Interoperability
> React provides escape hatches to work with mutable models and tries to work well together with other UI libraries. 
>You can wrap an existing imperative UI into a declarative component, and vice versa. This is crucial for gradual adoption.
#Scheduling
>Even when your components are described as functions when you use React you don’t call them directly.
>Every component returns a description of what needs to be rendered, and that description may include both user-written components like <LikeButton> and platform-specific components like <div>. It is up to React to “unroll” <LikeButton> at some point in the future and actually apply changes to the UI tree according to the render results of the components recursively.
#Debugging
>When something goes wrong, it is important that you have breadcrumbs to trace the mistake to its source in the codebase. In React, props and state are those breadcrumbs.
>If you see something wrong on the screen, you can open React DevTools, find the component responsible for rendering, and then see if the props and state are correct. If they are, you know that the problem is in the component’s render() function or some function that is called render(). The problem is isolated.
>If the state is wrong, you know that the problem is caused by one of the setState() calls in this file. This, too, is relatively simple to locate and fix because usually there are only a few setState() calls in a single file.
>If the props are wrong, you can traverse the tree up in the inspector, looking for the component that first “poisoned the well” bypassing bad props down.
#Glossary of React Terms
>Single-page Application
>Compilers- Babel is the compiler most commonly used with React.
>Bundlers-Some bundlers commonly used in React applications include Webpack and Browserify.
>Package Managers-npm or yarn 
>CDN-CDN stands for Content Delivery Network. CDNs deliver cached, static content from a network of servers across the globe.
>JSX-JSX is a syntax extension to JavaScript.JSX gets compiled to React.createElement() calls which return plain JavaScript objects called “React elements”. To get a basic introduction to JSX see the docs here and find a more in-depth tutorial on JSX here.
```
const name = 'Kaustav';
ReactDOM.render(
  <h1 className="hello">My name is {name}!</h1>,
  document.getElementById('root')
);
```
>Elements-An element describes what you want to see on the screen. React elements are immutable.
```
const element = <h1>Hello, world</h1>;
```
>##Components
>React components are small, reusable pieces of code that return a React element to be rendered to the page. The simplest version of React component is a plain JavaScript function that returns a React element:
```
function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}
or Components can also be ES6 classes:
class Welcome extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}
```
#Controlled vs. Uncontrolled Components
##React has two different approaches to dealing with form inputs.
>An input form element whose value is controlled by React is called a controlled component. When a user enters data into a controlled component a change event handler is triggered and your code decides whether the input is valid (by re-rendering with the updated value). If you do not re-render then the form element will remain unchanged.
>An uncontrolled component works like form elements do outside of React. When a user inputs data into a form field (an input box, dropdown, etc) the updated information is reflected without React needing to do anything. However, this also means that you can’t force the field to have a certain value.
##Keeping discussion about React community.