< 목차 >
1. 내가 구현한 페이지 및 기능
2. [Error] missing in props validation
- props의 타입 검증 방법
3. 깨달은 핵심 포인트
(1) Merge
(2) 기획 및 설계, 와이어프레임의 중요성
(3) 완성된 코드를 다른 데에도 저장해두자
4. 금일 소감
1. 내가 구현한 페이지 및 기능
총 세 페이지를 맡았다. My Page, Detail Page, Write Page다.
CRUD랑, 이미지 업로드, 로그인 된 정보를 가지고 글을 다르게 보여주는 기능 등을 구현하였다. 메인 페이지랑 마이 페이지가 연결되는 부분이 있다 보니 기능의 일부는 안 되는 것도 있었다. 원래 더 일찍 주말에 Merge 해서 기능 완벽히 완성시키고 필수 기능 마무리 작업까지 끝냈어야 했는데 이번에 팀원 한 분과 나, 이렇게 2명이서 다 하려다 보니 필수 기능 구현 자체도 빡빡하게 한 감이 있다..
이미지 연결이 생각보다 어려웠다.
프로필에만 이미지 연결하면 되고 게시글에는 꼭 연결하지 않아도 괜찮았는데 프로필에 연결할 수 있으면 게시글에도 연결할 수 있겠다 싶어서 일단 넣었다. 저장도 잘 되는데 아직 전역 상태로 하지 않아서 이미지를 불러오는 부분이 안 됐다.
당장 내일 정오까지 시연 영상과 코드를 제출해야 해서 새벽까지 계속 해서 완성시켜야 한다. 그리고 Redux로 리팩토링 작업도 해야 해서 오늘도 늦게까지 작업하겠다 싶다.
위 페이지와 기능을 구현하며 여러 에러가 뜨고, 또 새로운 정보를 알게 되었다. 그 내용들은 다음과 같다.
2. [Error] missing in props validation
posts is missing in props validation 에러는 React에서 prop-types를 사용할 때 발생하는 경고다.
이 경고는 컴포넌트에 전달된 props의 타입을 prop-types를 사용해 명시적으로 검증하지 않았을 때 나타난다. 이를 해결하기 위해서는 prop-types 라이브러리를 사용하여 해당 컴포넌트에 전달되는 props의 타입을 검증해야 한다.
prop-types를 사용하면 컴포넌트에 전달되는 props의 타입이 예상대로인지 검증할 수 있어서, 타입 불일치로 인한 버그를 미리 방지할 수 있다.
props의 타입 검증 방법
(1) 터미널에서 아래와 같이 prop-types 라이브러리를 설치한다.
npm install prop-types
(2) 해당 컴포넌트에 prop-types를 적용하여 props의 타입을 검증한다.
import PropTypes from 'prop-types';
// 기존의 import 문과 다른 코드들...
const DetailPage = ({ posts, setPosts }) => {
// 컴포넌트 로직...
};
// 여기에 prop-types 정의 추가
DetailPage.propTypes = {
posts: PropTypes.array.isRequired, // posts는 배열이며, 필수적으로 전달되어야 함을 의미
setPosts: PropTypes.func.isRequired, // setPosts는 함수이며, 필수적으로 전달되어야 함을 의미
};
export default DetailPage;
3. 깨달은 핵심 포인트
(1) Merge
Router, Firebase, Styled-component, Redux 등 초기 세팅 작업할 때 main뿐 아니라 dev Branch에도 Push 해두자. 편의성을 위해서도 dev Branch에서 Merge 한 다음에 테스트 할 때 모든 게 다 잘 적용되는지 보기 위해서도 dev에도 똑같은 초기 설정과 값을 적용해두는 게 중요하다고 느꼈다.
(2) 기획 및 설계, 와이어프레임의 중요성
구현 사항이 많으니 사람 마음이라는 게 다급해져 일단 시작하거나 아니면 회피 성향으로 시작을 미루게 되는 등의 모습이 보이는데, 이번 프로젝트를 하며 느낀 것은 이런 건 다 중요한 게 아니라는 것이다.
중요한 건,
- 전체적인 필수 구현 사항을 파악하고
- 무엇을 만들어야 하고
- 어떻게 해야 하는지
- 그러려면 무엇을 해야 하는지
등을 종합적으로 파악해서 기획을 촘촘하고 섬세하게 하는 것이 정말정말 중요하다고 느꼈다. 이 기획과 설계 단계에서 방향을 잘못 잡았거나 프로젝트에 대한 이해가 잘 안 되면 구현하는 단계에서 애를 꽤나 먹게 될 것 같다. 그래서 프로젝트, 기능, 기능을 구현하려면 어떤 것을 해야 하는지에 대한 이해가 필수적이라고 느꼈다.
또, 귀찮든 어쩌든 간에 와이어프레임을 최대한 구체적으로 만들어두는 것은 무척이나 중요하다. 감이 잘 안 오더라도 일단 만들어두고 구현하는 과정에서 자세한 부분의 살을 덧붙여가는 것이 옳은 방향이라고 생각했다. 물론 한 번에 정확한 방법과 방향으로 하는 게 베스트다.
(3) 완성된 코드를 다른 데에도 저장해두자
혹시 모르니까 Merge할 때 날아갈 수 있는 가능성을 염두에 두고, 본인이 작업했던 Branch에 Commit 하는 것 말고도 다른 레포지토리 같은 걸 만들어서 코드를 따로 저장해두자.. 정말 혹시 모르니까 여기저기에 마치 보험들 듯이 저장해두는 것은 정말 좋은 습관이자 안전한 행위인 것 같다. 나를 위해서도, 팀원을 위해서도.
4. 금일 소감
당장 내일이 시연 영상 제출이라 조마조마한 마음이 좀 크다. Merge를 하니 예상은 했지만 기능이 정상적으로 작동되지 않는 것이 있어서 그거 수정하고 에러 디버깅하고 다 되면 Redux로 리팩토링하는 작업해야 한다. 할 게 많고 기한도 급해서 얼른얼른 하고 시연 영상 기획도 빠르게 할 생각이다.
저번 팀 프로젝트는 4명 분량 3명이서 하고, 이번에는 2명이서 했다. 다음 팀 프로젝트는 나 혼자서 하는 거 아니겠지?... 혼자 하는 게 많아서 얻는 것도 꽤 있기야 하지만 나도 다른 팀들처럼 서로서로 모르는 부분 알려주고 도움 주고 하는 팀 플레이 해보고 싶은 마음이 좀 있다,,,,, 아무튼 남은 작업도 파이팅
'[Front-end] 개발자 공부' 카테고리의 다른 글
[개발 공부 38일차] 프로젝트 발표 완료 | 협업 시스템 정리 (4) | 2024.02.15 |
---|---|
[개발 공부 37일차] 프로젝트 완성! 발표 직전날 (1) | 2024.02.15 |
[개발 공부 35일차] Devtiny | CRUD, 이미지 업로드 구현 (1) | 2024.02.13 |
[개발 공부 34일차] To-do List 구현 (2) | 2024.02.08 |
[개발 공부 33일차] Counter 구현 (1) | 2024.02.06 |