- 화면 너비 425px 초과인 기기에서의 프로젝트 시현
- 화면 너비 425px 이하인 기기에의 프로젝트 시현
🪂Notion 프로젝트 바로가기
🪂Notion 프로젝트 Github 바로가기
1.Notion 프로젝트 계기
새롭게 뜨는 앱이라는 말에 호기심으로 notion을 사용하기 시작했고, notion을 사용할 수록 notion이 가지는 장점(유연성, 확장성)이 느껴졌고 notion 의 기능,레이아웃등을 공부해 보고 싶어졌다.
2. 준비과정
notion의 레이아웃을 분석하고, state와 component를 어떻게 만들지 생각해 봤다. 그리고 notion처럼 입력이 가능하고 입력 내용을 수정(텍스트 편집기능)할 수 있는 방법을 찾아 봤고 react-contentEditable 라이브러리를 사용하기 했다.
🔎notion 레이아웃 분석과 기획
🔎notion 텍스트 편집 기능 만들때 참고한 블로그 바로가기
3. 배운점들
1) 새롭게 알게된 것들
A.HTMLElement.contentEditable
이전에는 사용자가 텍스트를 편집할 수 있는 방법으로 input이나 textarea tag를 활용하는 것 밖에는 몰랐었는데 notion프로젝트를 하면서 contentEditable속성과 그 사용법을 알게 되었다.
B.HTML을 다른 형식의 파일로 변환
🖱️HTML을 다른 형식의 파일로 변환하는 것에 대해 정리한 페이지로 이동하기
C.Selection객체와 select event
🖱️Selection객체와 select event에 대해 알게된 점을 정리한 페이지로 이동하기
D. 이미지를 파비콘으로 사용하기
🖱️이미지를 파비콘으로 사용하는 방법에 대해 정리한 페이지로 이동하기
E. 마우스 컨트롤/ 터치를 통한 이미지 사이즈 줄이기
🖱️마우스 컨트로를 통한 이미지 사이즈 줄이는 방법에 대해 정리한 페이지로 이동하기
F. jsDoc와 Typescript의 편리성
이번 notion 프로젝트는 오로지 나의 힘만으로 Typescript을 이용한 첫번째 프로젝트이다. 수 많은 속성을 가진 여러 state를 생성하고 변경하고 여러 mouseEvent과 keybordEvent등의 이벤트를 사용해야 했던 이번 프로젝트를 통해 왜 Typescript를 많이 사용하고 선호하는 지 알게 되었다. 아마 많은 오류를 해결하느라 진땀을 뺏었을 것 같다.
여기에 더해 이번 프로젝트에서 새롭게 사용한 것이 jsDoc이다. 우연한 계기로 알게 되었는데 jsDoc로 function,property등에 대한 설명을 붙여놓으니 나중에 오류를 해결하거나 function 등을 다시 사용하게 될 때 parameter가 무엇인지, 해당 함수가 어떤 기능을 하는지등을 빠르게 파악할 수 있어서 해당 매우 유용했다.
G. 모바일 브라우저와 웹 브라우저의 차이
모바일 브라우저와 웹 브라우저의 차이에 대한 글 보러가기
H. Drag and Drop
I.CSS sprite
J. React와 SEO
2) 오류 해결을 통해 알게된 것들
A. react state의 속성의 값이 객체를 원소로하는 배열일때 react state의 불변성
notion 프로젝트에서 state의 속성 값의 타입이 배열이고, 해당 배열을 또 다른 객체들의 집합인 경우가 많았고 특정 원소의 변경을 react가 감지하지 못하는 오류가 발생했었다. 이를 해결하는 과정에서 java script의 메모리 구조와 react의 "불변성"에 대해 더 깊게 공부할 수 있었다.
🔎java script의 메모리 구조와 react의 "불변성" 에 대해 정리한 페이지 바로가기
B. react rendering과 state변경
root state 변경시에 return문에서 데이터를 찾아서 반환하는 것과 userEffect에서 데이터를 찾아서 해당 component의 state를 변경시키는 방식이 서로 다른 결과를 보여주었다. 전자의 경우에는 오류가 일어나지 않았지만 후자의 경우에는 변경된 root state의 값이 아닌 변경 전의 데이터를 활용해 오류가 일어났고 이는 react rendering의 순서와 관련이 있다는 것을 알게 되었다.
🔎react rendering과 state변경에 대해 정리한 페이지로 바로가기
C. tab키를 눌렀을때 커서 이동을 막는 방법
a. tabindex ="-1" 이용하기
b. onKeyDown과 event.preventDefalut()이용하기
onKeyDown 이벤트에서 tab을 눌렀을 경우 event.preventDefalut()을 실행시키면 tab키로 인한 커서 이동을 막을 수 있다.
D. ":empty::after"
:element의 content가 비어있을 경우, placeholder가 보이도록 하는 방법
<div contentEditable={true}
className='contentEditable'
placeholder="type '/' for commmands"
>
{block.contents}
<div/> .contentEditable:empty::after{
content: attr(placeholder);
color: grey;
}E. label을 이용한 input(type="file") 스타일 커스텀 시 유의사항
다음의 코드 처럼 label을 이용해 input(type="file")의 스타일을 커스텀할 수 있다.
<label
htmlFor="imgLoader"
id="imgLoaderBtn"
>
Or upload file
</label>
<input
type="file"
accept='image/jpg , image/jpeg, imgae/png'
name="imgLoader"
id="imgLoader"
onChange={onChangeImgFile}
/>그러나 여기서 주의할 점은 input style의 display값을 none이나 hidden으로 하면 파일을 선택할 수 있는 창은 열리지만 선택된 파일이 화면상에 나오지 않는다. 이런 오류를 해결하기 위해서는 input이 보이되 화면상에는 보이지 않도록 위치를 변경시켜주면 된다.
input{
position:absolute;
width:0;
height: 0;
}F. passive option
3) React 렌더링 최적화
React를 공부하면서 React최적화가 중요하다는 말을 많이 들어봤고 그 방법에 대해서도 알았지만 React 렌더링 최적화에 사용되는 memo,useMemo,useCallback은 자칫하면 메모리가 부담을 주고 성능 저하나 버그를 일으킬 수 있기 때문에 React로 하는 첫 프로젝트 코드를 작성하면서 React를 잘 알지 못하면서 최적화를 같이 진행하는 것이 부담스러웠다.
Notion 프로젝트를 완성하고 이후에 여러 프로젝트를 진행하면서 React가 익숙해지고 간단한 프로젝트에서 React 렌더링 최적화를 진행해 보는 경험을 해 본 뒤에 Notion 프로젝트의 성능을 개선하는 과정에서 React 렌더링 최적화를 진행했다.
| 최적화 단계 | 최적화 진행 상태 | 속도 |
|---|---|---|
| 1단계 | redering 시 React.memo 사용 | 3881ms |
| 2단계 | 일부 컴포넌트에 useCallback를 사용 | 3131ms |
| 3단계 | useMemo, useCallback 등 사용해 모든 컴포넌트 최적화 완료 | 2165ms |
3단계와 1단계를 비교해보면 모든 부분에서 속도가 줄어들었고, 최적화를 진행하면서 오류를 수정하거나 코드를 정리하면서 컴포넌트를 추가했는데 이를 생각하면 js힙 메모리 부분에서도 React 최적화가 성과가 있었고 생각한다.
4. 마무리
예상보다 훨씬 오래 걸린 프로젝트이지만 하기를 잘한 것 같다. 두렵게만 느껴졌단 Typescript에 대해 자심감도 생겼고 react에 대해 내가 얕게 알고 있었던 것고 깨달았고 기존에 사용해보지 않은 다양한 속성과 기능들을 사용해 보는 계기가 되었다.
오류 수정을 반복하면서 무수한 사용자의 실사용 경우의 수가 존재하기에 한번에 완벽한 개발이 힘들다는 것을 알게 되었고 처음에 기획한 것보다 더 많은 기능들과 모바일 버전을 추가하면서 유지 보수가 용이한게 정말 중요하다는 것을 체감하게 되었다.
그리고 단순히 기능을 구현하는 것에서 그치지 않고 성능을 개선하는 과정에서 React 렌더링 최적화, 이미지 최적화, windowing을 진행해보고 React는 SEO에 단점이 있어라고 끝내지 않고 그럼에도 React에서 SEO를 해보는 시도를 해봤다는 점에서 좋았던 프로젝트였다.
