기록하고 싶은 것들

프로젝트 배포에 들어가기 전에, 최종테스트를 하며 질문의 view 숫자가 미친듯이 올라가는 것을 발견했다. API를 통해서 question의 정보를 받아올 때마다, 질문의 viewCount가 증가하는 구조인데 질문 수정, 타임라인 페이지를 이동한 때마다, API를 통해서 question의 정보를 받아오기 때문에 view의 속도가 빠르게 증가하였다. Question 페이지와 editQuestion, Timeline 페이지는 별개의 페이지이기 때문에, props로 정보를 전달하지 못하여 그냥 서버에서 정보를 받아오는 식으로 해결하였다. 서버의 정보를 받는대신, 기존의 방식을 활용하는 방법은 내 생각으로는 2가지가 있었다. 1. 전역 상태 관리 2. Link태그로 props 전달하기 1번의 방식을 사용하는 것..

Eslint를 설정한 뒤, 설정없이 사용하던 환경에 비해서 제약이 많이 생겼다. 예를 들어 buttton의 타입을 정하지 않으면 에러가 생기거나, 아래의 예시처럼 span 요소에 onClick 이벤트를 적용시키면 오류가 발생하였다. 찾아보니 이것은 eslint의 rule에 의한 에러여서 조건과 해결방법을 조사하였다. 아래는 eslint의 제약 조건과 해결 방법들이다. 비대화형 요소의 클릭 핸들러는 최소 하나의 키보드 리스너가 필요하다. 그 이유는 마우스를 사용할 수 없는 사람들이 키보드를 쓸 수 있게 함이다. onKeyUp, onKeyDown, onKeyPress 이벤트를 할당 해당 엘리먼트를 button으로 바꿈 모든 브라우저와 스크린리더들이 대화형 요소(interactive element)를 이용 가..

오늘은 기존 작성했던 UI에 간단한 기능들을 추가하였다. 현재로서는 아직 백엔드쪽 구축이 덜 되서 json-server를 이용하여 간단하게 글의 정보를 받아오는 정도만 구현했다. components/CommentBox 댓글을 작성하고 제출 시, 알림 버튼을 누르면 댓글이 작성되는 기능을 추가하였다. 댓글의 남은 글자 수도 하단에 위치해 두었다. // Comment 출력시 사용되는 컴포넌트 function CommentBox({ commentList }) { const [isWrite, setIsWrite] = useState(false); const [comments, setComments] = useState([]); const [newComment, setNewComment] = useState(''..

오늘은 프로젝트의 요구사항에 따른 화면 정의서를 제작해보았다. 내가 맡은 페이지는 마이페이지(profile),유저페이지(profile),질문 작성 페이지, 헤더였다. 마이페이지(profile) 유저페이지(profile) 질문 작성 페이지 헤더 직접 화면의 기능들을 명시화하고 구체화하니 실제 프로젝트를 진행할 때, 어떤 점을 중요시하고 구현해야할지가 대략적으로 보이는 시간이었다.

오늘은 프리 프로젝트의 UI 컨셉을 정하는 회의를 하였다. 우선 백엔드 파트와의 협의에서 기한안에 구성하지 못할 것 같은 기능들에 대해서는 과감하게 없애거나, 수정하였다. 회의 내용은 반응형 구현, 메인 컬러, 컨셉, 폰트 사이즈 등 공통적으로 정해야할 우선순위들에 대해서 정했다. 반응형은 기능 구현이 끝난 이후에, 후순위로 미루어 졌고, 아래 처럼 기본적인 설정을 마쳤다. 이후 각자 맡은 부분을 피그마로 구현하였는데, 나는 Nav, Header의 제작을 맡았다. 추가적으로 시간이 남아서 질문 상세 페이지의 구현을 도왔다. 아래는 구현한 페이지들의 목록이다.