Create 구현 - contents 변경

constructor에 아래의 코드를 추가한다.

this.max_content_id = 3;

또한 this.state.mode의 create 부분을 수정한다.

else if (this.state.mode === 'create') {
      _article = <CreateContent onSubmit={function(_title, _desc){
        this.max_content_id = this.max_content_id+1;
        var _contents = this.state.contents.concat(
          {id:this.max_content_id, title:_title, desc:_desc}
        )

위 방법은 state에 값을 추가할 때는 push와 같이 원래의 데이터를 변경하는 것을 사용하지 않고, concat과 같은 원래의 데이터를 변경하지 않고, 새로운 데이터를 추가하는 것을 사용한 것이다.

위와 같은 방법으로 리액트의 성능 저하가 일어나지 않는다. 

아래는 push와 concat의 차이이다.

var a = [1, 2];
a.push(3);
console.log(a);
//[1, 2, 3]

var a = [1, 2];
var b = a.concat(3);
console.log(a, b);
// [1, 2] [1, 2, 3]

'create' 부분의 코드는 setState를 변경하려고 할 때 push를 통해 직접적으로 바꾸지 않고, concat을 통해 복제하여 state를 넣어 주었다.

shouldComponentUpdate

App.js는 비효율적인 면을 갖고있다.

TOC가 rendering 되기 위해 필요한 데이터는 state의 contents []이다. 이 내용이 바뀌면 TOC 컴포넌트의 render가 다시 실행될 것이다.

이 말은 즉슨, 만약 contents가 바뀌지 않는다면 TOC의 render()는 호출될 필요가 없다. 그러나 현재 코드에서는 사용자의 모든 act에 TOC의 render()가 실행되고 있다.

facebook은 이러한 이슈를 방지하기 위해 shouldComponentUpdate()라는 함수를 만들었다. 이 함수의 return이 false라면 react는 그 밑의 render() 함수를 읽지 않는다. 

또한 shouldComponentUpdate의 매개변수는 newProps, newState로 약속이 되어 있다. 
 -console.log(newProps, 'A');
 -console.log(this.props.data, 'B');
B에서는 render()가 호출되지 못하였기 때문에 state.content [] 값을 그대로 갖고 온다. 하지만 newProps는 추가된 값까지 가져오는 것을 볼 수 있다. 즉, 전자는 배열값을 가져오지만 후자는 변경값을 갖고온다. 

만약 쓸데없는 redering을 막기 위해 shouldComponentUpdate를 사용했고, 원본 값과 변경 값을 비교하여 변경 값이 있을 때만 TOC가 render 된다는 조건을 추가했다고 치자.

이때, state.contents []를 push로서 값을 추가했다면 TOC에서 this.props.data를 했을 때 원본 배열에 값을 추가하였기 때문에 shouldComponentUpdate함수 내에 if문으로 조건을 붙일 수 없다.

그러나 concat()을 사용한다면 원본 값은 두고 그 원본 값을 복제하여 변경 값을 추가한다음 render()하기 때문에 원본값과 변경값을 비교할 수 있는 환경을 만들 수 있다.