2023/09/11(월)
- Planning Meeting (10시 ~ 12시)
- Portfolio - 과정중심 사고기법(강의) (12시 ~ 13시)
- 1차 프로젝트(weread) 시작
- 저번 주말 작업 => UI 적용 (모든 페이지)
- 초기 세팅 및 페이지 css 보충 수정
- 회원 가입 시 중복 확인(이메일, 닉네임) 후 disabled처리와 비밀번호, 비밀번호 확인 input이 같으면 회원가입 버튼 활성화
2023/09/12(화)
- Planning Meeting (10시 ~ 10시30분)
- 컴포넌트 재사용(강의) (10시30분 ~ 12시)
- 1차 프로젝트
- 로그인 테스트 완료
- 글 목록 가져오기 (Mock데이터로 가져오기는 완료) -> backend와 테스트 필요
- 회원가입 테스트 완료
- 회원가입 : 각 컴포넌트의 값을 state로 관리, 전화번호는 객체로 (국제번호+번호)관리 및 숫자길이, 3,4자리 수마다 - 붙여주는 정규식
2023/09/13(수)
- Planning Meeting (11시 ~ 11시30분)(with 멘토)
- 1차 프로젝트
- 글 작성 테스트 완료
- 글 목록에서 localStorage에 있는 아이디 값이 같은 글만 삭제 수정 버튼 보이게
2023/09/14(목)
- 1차 프로젝트
- 글 목록(backend)와 연결 테스트 및 목록 가져오기 완료
- 글 쓰기 완료
- 글 상세페이지 완료
- 글 삭제 완료
2023/09/15(금)
- 1차 프로젝트
- 댓글 수정 및 삭제 완료
- 프로젝트 마무리 및 회고 - 개발자의 회고록 작성법 강의(15시 ~ 16시30분)
- 개발을 왜 하게 되었는지
- 이번 프로젝트 기간에 대해서 - Product + ing(16시 ~ 18시)
- Product(제품 관점) : 제품을 고객의 관점, 제품의 목적, 제품을 개발자의 관점, 제품의 매출발생 원리
- End-user (사용자 관점):사용자가 왜 우리제품을 사용하고 있는지, 사용자의 동선 파악(제품속에서)
- Tech (기술 관점) : 사용하고있는 기술스택과 버전, 회사의 비즈니스 로직, 기획과 설계에 대해서, 기술구현이 효율적으로 구현되었는가, 코드의 확장성과 유지보수성, 프로그래밍 전략
한 주 마무리
프로젝트 회고
1일차 - 내 성격 자체가 간당간당한 일정을 싫어하는 탓에 주말에 UI를 다 그려놨다. 필수 구현 요소보다 더 많은 요소를 구현하고 싶은 마음에 조급해 졌나 보다..
2일차 - 백엔드와 통신이 늦어져서 글 목록 페이지를 mock데이터를 사용하여 불러왔다. 아직까지는 강의에서 배운 내용을 사용하기 때문에 어려움은 없었지만 같은 팀원 프론트엔드분께서 selectBox를 동적으로 가져오는 부분에서 state를 사용하지 않고 가져와서 혼자서 다시 코드를 짜기보다는 팀원이 짜놓은 로직을 사용하는 방향으로 문제를 해결했다. (아직은 서로 배우고, 각자 파트가 정해져 있으므로 침범하지 않으려 했다.)(selectbox에 onchange를 사용해서 value 값을 가져오는 부분에서 value 값은 가져오는데 select 박스가 바뀌지 않는 문제였다. 그래서 onchange를 없애고 회원가입 버튼을 눌렀을 때, id 값을 통해서 value를 가져오는 방향으로 진행하였다.)
3일차 - 오늘 일정이 게시글쓰기, 게시글 목록 불러오기를 완료하는 줄 알았으나 백엔드 담당 팀원이 로직만 완성하고 먼저 집에 가서 남은 다른 팀원과 맞춰보는 중 더 필요한 로직이 필요해서 백엔드 코드를 수정하여 사용했는데 팀원과 상의 없이 수정한 행동으로 인하여 약간의 트러블이 있었다. 아마도 소통의 부족이 원인이었던 거 같다. 프론트엔드와 백엔드가 나눠져 있다 보니깐 프론트는 프론트끼리 소통하는 경우가 많았지만 앞으로는 더 많은 소통으로 이런 일이 발생하지 않도록 해야겠다.
4일차 - 코드 리뷰시간에 멘토님의 피드백을 통해 내가 짠 코드가 실행하는데 문제는 없지만 더욱 더 간결화하고 짧게, 알아보기 쉽게 짤 수 있다는 것을 알았다. 코드를 간결화 하는 방법(es6 문법, 객체 구조분해 할당 등)을 기술블로그에 정리해봐야겠다.
5일차 - 생각했던 기능까지는 아니더라도 필수 구현사항에 몇 개의 추가 구현사항까지 완료하는데 성공했다. 다른 기능도 추가하고 싶었던 욕심이 있었지만 그래도 위코드에서의 첫 팀프로젝트는 나름 성공한 거 같아 뿌듯하다. 돌아보자면 어느정도 불화(?)도 있었고 부족한 부분도 있었지만 소스코드 상에서의 부족한 부분은 천천히 수정 해 나가면 될 거 같고, 팀원과의 불화는 어느정도 프로젝트를 진행하는 과정에서 생기는 소소한 부분이라고 생각한다. 주말에는 어느정도 나를 돌아보는 시간도 가져보고 내가 부족한 부분도 돌아봐야겠다.
주말동안 나를 돌아보고 다음주 2차 프로젝트는 보다 개선된 점으로 진행하길 바란다.
궁금했던 점
- selectbox를 javascript에서 동적으로 만들고 관리 했을 시 , 재 rendering 될 때, 또 다시 동적으로 만들어서 select박스의 값을 바꿔도(on change) value는 바뀌어도 화면상에서 값이 바뀌진 않았다. 이유는 리렌더링 때문에 다시 selectbox를 그려주는 이유 때문인거 같은데 그렇다면 input에 글을 작성해도 onchange에 usestate를 사용하면 input박스도 재 렌더링 되면 값이 초기화 되야하는거 아닌가 …?
chatGPT : React는 Controlled Components 패턴을 통해 input 요소의 값을 React state와 동기화시키고, 가상 DOM을 사용하여 변경된 부분만 업데이트하여 이전 값이 유지됩니다. 이것이 React가 컴포넌트를 다시 렌더링할 때도 input 값이 초기화되지 않는 이유입니다.
- Controlled Components 패턴: Controlled Components 패턴은 React에서 input 요소의 값을 React state와 동기화시키는 방법이다. 이 패턴을 사용하면 input 요소의 값이 React state에 의해 제어된다. onChange 핸들러를 통해 input 요소의 값이 변경될 때마다 해당 값을 React state에 업데이트하면, 이 값을 다시 input 요소의 value 속성에 반영한다. 따라서 리렌더링이 발생해도 React는 항상 React state의 값을 input 요소에 설정하여 이전 값이 유지된다.
- 가상 DOM (Virtual DOM): React는 가상 DOM을 사용하여 실제 DOM과 효율적으로 상호작용한다. 리렌더링이 발생하면 React는 가상 DOM을 사용하여 이전 실제 DOM과 비교하고 변경된 부분만 업데이트한다. 이것은 브라우저에 실제 DOM 업데이트를 최소화하고 성능을 향상시킨다. 그리고 Controlled Components 패턴을 사용하는 경우, React는 input 요소의 value 속성을 변경하면서 이전 값과 새 값 간의 차이를 가상 DOM에서 업데이트하게 된다. 이로써 이전 값이 유지되면서 리렌더링이 발생합니다.
- 글 목록에서 삭제 시 데이터를 다시 불러오는게 맞는지(새로고침이나 fetch문을 다시 돌린다..?) 아니면 프론트엔드 자체에서 초기에 받은 데이터(state)에서 삭제하면 되는건지...
A(멘토) : 개발자의 몫이다 ~ (무슨 방법이던 돌아가면 상관없다 단, 사용자의 편의를 고려해서)
