부트캠프 29, 30일차 (React State & Props)

오늘의 생각

대망의 State 와 Props를 배웠다. 

 

이 부분은 이전에 독학해서 미리 알고 있는 것이 정말 다행이라고 생각했다. 덕분에 이전에 배우면서 중요하다고 생각했던 부분을 다시 짚으면서 공부할 수 있었고 state와 props를 좀 더 편하게 사용할 수 있었다. 본격적으로 state와 props를 쓰니 역시 리액트의 강점을 새삼 느낄 수 있었다.

 

페어 프로그래밍에서는 그동안 배웠던 기초적인 리액트 기술들(Router, Component)을 다시 활용해 볼 수 있어서 기존에 배웠던 개념을 명확히 할 수 있는 좋은 기회였다. 

 

그렇다고 마냥 순탄하지는 않았다. 과제는 주어진 템플릿이 있기 때문에 양식에 맞춰 코드를 작성하고 구현해야 하는데, 이 부분에서 큰 어려움을 겪었다. 템플릿은 잘 이해하고 이행하였기 때문에 초반의 기초적인 기능 구현에는 전혀 어려움이 없었지만, 주어진 더미 데이터(배열 안 객체)를 구조 분해 할당(Destructuring)해 게시물을 보여주는 부분에서 템플릿의 특성을 이해하지 못해 큰 어려움을 겪었다.

 

 

 

이미 1개의 메세지가 예시를 통해 잘 구현이 되었기 때문에 오늘 배웠던 props를 활용해 더미데이터(dummyTweets라는 배열)을 활용하면 될 것 같았다.

 

이에 따라

<Tweet tweet = {dummyTweets[0]} />;

에서 props "tweet"을 배열의 요소 중 하나를 받는 것이 아닌 전체 배열을 받을 수 있는 props "tweets"로 바꿔 

<Tweet tweets = {dummyTweets} />;

코드를 작성했다. 

 

 

이후 해당 컴포넌트에서는 이제 하나의 요소가 아닌 더미 데이터 전체의 배열을 받는 것이므로 .map 메서드를 활용해 배열 안의 모든 요소를 순회하고 해당 요소를 자료에 맞게 사용한 뒤 반환하도록 작성했다.

 

 

이에 따라

const Tweet = ({ tweet }) => { return ( 내부 데이터 i.e. <img src={tweet.picture} />) } 

에서 순회를 통해 각 요소를 반환할 수 있도록

const Tweet = ({ tweets }) => { return tweets.map((tweet) => {return ( 내부 데이터 i.e. <img src={tweet.picture} />) }

로 바꾸었다.

 

 

전체적인 기능 구현이 잘 되었기 때문엔 만족했는데 문제점이 발생했다.

 

 

바로 테스트를 통과하지 못한다는 점이었다.

 

기능적으로 문제는 없었지만 템플릿, 즉 코드스테이츠에서 원하던 답이 아니었다. 처음에는 납득이 잘 되지 않았다. 기능은 잘 구현됐는데 굳이 고쳐야되나? 라는 생각도 들었다.

 

하지만 최근 "클린 코드" 책을 읽으면서 생각을 달리할 수 있었다.

 

만약 내가 지금 회사에 다니고 있다면, 해당 코드가 생산성을 올리는 일인지 떨어뜨리는 일인지 고민해보았다.

 

테스트를 실패했다는 소리는 즉, 회사가 원하는 코드와 맞지 않는 일이라는 얘기였다. 물론 "클린 코드" 책에서는 장인 정신을 가져야하고, 회사에 생산성을 높일 수 있는 코드를 제시해야 한다고 했다. 하지만 회사에 더 높은 생산성의 코드를 작성하기 위해서는 먼저 회사가 어떤 코드를 원하고 있는지 알아야할 필요성도 있다고 느꼈다. 

 

따라서 테스트를 통과하기 위해 페어 분과 이야기를 나누며 구조를 수정했다.

 

먼저 테스트가 요구하고 예상하는 값이 무엇인지 알아보았다. 명확하게 모든 테스트 코드를 이해하진 못했지만, 기존의 Tweet 컴포넌트가 받고 있는 props를 변경하면 안 된다는 것을 알게 되었다. 

 

이에 따라 기존 구조

<Tweet tweets = {dummyTweets} />;

 

에서

{tweets.map((item) => {return <Tweet tweet={item} key={item.id} />;})}

로 수정했다. 이를 통해 기존 props를 변경하지 않은 채 .map 메서들 활용해 더미데이터(배열) 안 각 요소를 순회하고 주어진 양식에 맞게 코드를 작성할 수 있었다.

 

 

테스트도 기분 좋게 통과했다.

 

마지막으로 "왜 이런 식으로 작성하는 것을 코드스테이츠가 원했을까?" 라는 의문을 던져 보았다. 이에 따라 몇 가지 가능성을 내 나름대로 정의해 보았다.

 

1. 기존에 구성된 파일 구조(Structure) 상 <Tweet> 컴포넌트는 게시물 1개 만을 담는 개별 컴포넌트에 맞춰 구성이 되었기 때문에 본래의 목적을 해치면 안된다.
2. 이후 추가적인 기능을 고려했을 때 기존 더미 데이터는 변동이 없고 데이터를 담고 있는 새로운 state에 맞게 논리구조를 작성할 때 더 용이하다.
3. 코드스테이츠가 원했던 방식으로 진행했을 시 기대했던 변경점만 있고 예상치 못했던 변경점에서 오는 에러를 막을 수 있기 때문이다.

 

여러 가지 가능성이 있지만, 모두 타당하다고 생각했다. 결론적으로 새롭게 작성한 논리 구조가 더 생산성을 높이고 회사(코드스테이츠)의 기대에 반하지 않았기 때문이다.

---

오늘의 키워드

State, Props, useState, 이벤트 처리 함수Event Handler, Controlled Componenet, 하향식(top-down) 데이터 흐름

 

---

오늘의 학습내용

• State와 Props의 정의 및 특징, 그리고 차이
• state hook(useState)의 사용법과 주의점
• React에서 이벤트 처리 함수를 쓸 때 주의해야할 것들
• Controlled Component의 정의 및 사용법
• 리액트 데이터 흐름과 하향식 흐름의 정의

 

---

어려웠던 keyword / 활용한 질문

 

Q. 왜 Props가 immutable한 데이터인지 리액트 데이터 흐름을 통해 설명해주세요

 

A. Props는 부모 컴포넌트(상위 컴포넌트)로부터 전달받은 값이기 때문에 읽기 전용 객체로 설정되어 있어 바꿀 수 없습니다. 이는 리액트 데이터 흐름이 하향식(top-down), 즉 상위 컴포넌트로부터 하위 컴포넌트로 전해지는 단방향 데이터 흐름이기 때문입니다. 따라서 Props의 값을 변경하고 싶다면 State 값을 useState 메소드에서 정의된 상태 변경 함수를 호출해 변경해야 합니다.