kongom2dev

최종발표 영상자료를 직접 찍어 편집까지 해보는 것도 처음이고 프로젝트를 완성해보는 경험도 처음이었다. 부족한 부분은 역시 많지만 이제 시작이기에 더 많은 것을 준비하여 지원하기까지 잘 마무리 해야겠다.

이번주차는 중간발표 후 미비된 부분을 보충하거나 추가로 기능을 시도해보는 주차다. 우리팀은 프론트에서 기술적으로 어필할 수 있는 부분이 부족하여 그부분을 보강하려한다. 지도를 펼쳐 마커로 청약 정보를 나타내는 식으로 표현하려 한다. 그러다 보니 기존에 디자인된 메인페이지와 괴리감이 있으면서도 없으면 허전한 느낌이 났다. 이 부분은 다음주차의 유저테스트를 통해 피드백을 얻어보고자 한다. 실질적으로 유저들은 괴리감을 느끼는지 어떤 뷰를 더 원하는지 파악하고 결정을 지어야 겠다.

백엔드와 데이터 연결을 마무리 짓고 중간발표가 있는 주차다. 보여지는 부분은 디자인대로 그려졌고, 처음에 약속했던 기능들은 다 연결 되었지만 프론트가 어필할 수 있는 부분은 없었다 MVP 단계에서 최소한의 기능만 빠르게 만들어 보고자 내린 결정이다 보니 어쩔 수 없는 부분도 있었다. 남은 3주 동안은 프론트를 통해 더 사용성있는 서비스를 만들기 위한 작업에 집중을 해야 할 듯 하다.

부트캠프를 항해99를 선택했던 결정적인 이유 중 하나는 백엔드 프론트 디자인의 협업할수 있는 기회였다. 우리팀은 경험있는 디자이너 덕에 보통 회사에서 프로젝트가 어떤식으로 진행되는지 알수 있었고 또 그러한 부분을 맞춰가며 간접적으로 실제 업무를 느낄수 있었다 이번주까지 디자인 바탕으로 화면을 그리는것에 집중했다면 다음주는 각 기능을 연결하는 작업을 하게된다. 백엔드와 긴 시간을 보내며 함께 새로운것을 알아가게 될것이 기대된다

이제부터 서비스를 기획부터 만들어 보는 기간이다. 3주간 1차적으로 서비스를 빠르게 만들어보고 이후 사용자의 피드백을 받아보며 서비스를 발전시키는 방향으로 진행 된다. 역시 랜덤으로 팀이 정해지고 주제 또한 없다. 하나부터 열까지 동료들과 이야기를 하며 만들어 나가야 한다. 첫주는 기획과 디자인을 잡는데 많은 시간이 소요되었다. 기획에 따라 데이터는 공공 데이터를 활용해야 하다보니 첫날부터 백엔드는 업무가 있었지만, 프론트는 디자인이 나오지 않은 상황에서 크게 진행하는 부분이 없었다. 와이어 프레임을 보며 사용할 것들을 예상하며, 사전작업만 진행 했다.

저번 주차에서 마찬가지로 로그인과 CRUD에 대한 전반적인 이해도가 부족 했다. 부족한 부분에서 시작한 만큼 경험 하지 못한 부분을 하는 편으로 하길 원했고 같이 팀이었던 팀원분의 배려로 로그인, 회원가입 부터 작업 할 수 있었다. 일단 먼저 동작이 되는 것에 신경을 먼저 썼다. 기본적인 최소단위 컴포넌트 부터 페이지까지 간략하게 먼저 그렸고 회원가입시 유효성 검사와 로그인시 서버로 post 요청 보내는 것까지 하고 나니 이틀이 지나있었다 그 후에 포스트 작성하는 부분을 맡아서 본격적으로 CRUD를 경험하게 되었다. 백에서 만들어 주신 API가 유효한지 테스트를 해보고 포스트 등록 하려 했으나 리덕스의 흐름을 제대로 이해하지 못하다 보니 여러번의 삽질을 통해 겨우겨우 버튼 클릭 시 데이터를 서버로 전송할..

CORS란? 교차 출처 리소스 공유 정책 출처가 다른곳의 자원에 접근할 수 있도록 브라우저에 권한을 부여하는 정책 브라우저의 현재 주소와 API의 도메인이 일치해야 데이터에 접근 가능 불일치 시 CORS 에러 발생 ⇒ 이에 따른 CORS의 설정 필요 json-server로 만든 서버엔 모든 도메인을 허용하는 CORS 규칙이 적용되어 있음 특정한 도메인만 허용을 해야 할 것 (Open API 만드는 것이 아니라면..) 프론트에선 Proxy(웹팩개발서버에서 제공)를 통해 이문제를 해결 할 수 있음 물론, 백엔드에서 해결하는 방법도 있다. package.json 에서 "proxy": "http://localhost:4000" 코드 추가 https://react.vlpt.us/redux-middleware/09..

같이 일하기 좋은 개발자 현재의 문제를 코드로 해결할 수 있는 능력은 기본 더 기민하게 문제 해결 하기 위한 협업능력 다른면을 볼 수 있는 열려있는 자세 리액트와 전역 상태 관리 리액트는 컴포넌트 형태로 구성되어 있다. 데이터를 변경하고자 할때 props 형태로 컴포넌트간에 데이터를 주고 받는다. 컴포넌트가 많아질 수록 props형태로 데이터를 주고 받는 것에 많은 불편이 따른다. 이런 상황에서 Redux와 같은 상태관리 프로그램이 나타났다. https://www.stevy.dev/react-state-management-guide CSS 라이브러리와 리액트 Sass 별도의 문법변수, 믹스인 개념이 있음 코드의 가독성과 재활용성이 높음 ⇒ 유지보수가 쉬움 Sass 문법으로 작성한 파일은 별도의 빌드단계를..

초기 리액트 클래스형 라이프사이클 정리 내용 현재 이 개념을 이해하기 위해 많은 시간을 쓸 필요 없음 React 생명주기 메서드 ( LifeCycle Method ), only 클래스형 컴포넌트 kongom2.notion.site 초기 리액트는 클래스형 컴포넌트에서만 라이프사이클과 State 관리가 가능했었다. 함수형 컴포넌트는 지원되지 않다보니 클래스형의 부수적인 형태로 UI를 표현하는데에만 그쳤었다. 클래스형 컴포넌트는 다양한 컴포넌트를 만들 수 있었으나 코드가 복잡한 단점이 있었고, 함수형 컴포넌트는 코드가 간결했지만, 제한된 컴포넌트만 만들 수 밖에 없는 단점이 있었다. 함수형 컴포넌트의 장점을 그대로 두고 단점을 보안해 만든 리액트 16.8버전 부터는 모든 컴포넌트를 함수형으로 만들 수 있게 되..

파이어베이스와 연동하는 작업 중 파이어 스토어의 데이터를 불러오는 미들웨어를 만드는 과정에서 아무리 콘솔을 찍어봐도 데이터가 없는 걸로 떴다. 파이어 베이스에 프로젝트를 만들었고, 콜렉션과 필드값에 각각 데이터를 넣었는데도 답이 안나오는 상황에서 강의를 이리저리 돌려보며 고민을 수차례 하던 중 혹시 프로젝트가 두개가 생성되서 그런가 해서 전체 프로젝트를 열어보니 떡하니 똑같은 프로젝트가 두개가 있었다. 기억을 되집어 보니 먼저 프로젝트 하나를 만들었었고 배포하는 과정에서 새로 똑같은 이름으로 프로젝트를 만들어 배포해버리는 과정에서 두개가 생성되었다... 어이없는 이유로 하루의 반을 이것 때문에 골머리를 앓았지만 그만큼 어이없는 실수를 했다는 점을 반성하며 이런 똑같은 일이 일어나지 않도록 해야겠다.