#파일명- 대문자/ 패키지명- 소문자
#문서 형태로 주석을 빽빽하게 쓸 때가 있음. 그럴 때는 작성자를 'author'라고 부른다. 상대에게 제대로 읽혀야 한다는 점이 중요하다.
#미사용 import, console.log, debugger를 모두 빼고 PR 올릴 것.
#page-> 메뉴에 들어가는 데이터셋 / 다른 파일로 빼서 import 해서 사용하는 게 관리하기 용이함.
#상위 컴포넌트일수록 실제적인 역할보다 하위 컴포넌트의 관리에 초점을 맞춰야 한다.
#분기를 태울 때(ex 라우터 잡기) 어느 정도의 수준에서 나눠지고 관리되어야 할지 고민을 해야 한다. (헤더에 대한 분기는 header 파일에서 한다.) 너무 많은 기능이 상위 컴포넌트의 역할이 되면 안 된다.
#on, off 기능을 함수로 연결할 때(한줄만 있을 때)는 인라인으로 처리하는 게 가독성도 좋고 코드 줄도 줄어든다.
#자주 변하는 부분과 자주 변하지 않는 부분을 나눠서 작업하는 것도 중요한 기준이 된다.
ex) 라우터와 레이아웃 / 레이아웃은 아주 수정이 드물게 이뤄지는 쪽이고 라우터는 아주 자주 바뀌는 쪽이다.
#컴포넌트 시작부터 끝까지 50줄을 넘기면 보기 힘들어진다.
-> 따라서 그 이상이 되면 적당히 나눠야 한다.
-> 단일 책임 원칙
#필요한 걸 만드는 것도 중요하지만, 안 쓰는 걸 지우는 것도 중요하다.
#최대한 적은 코드로, 효율이 좋게.
#import에서 { }를 안 붙이는 건 export default일 때만이다. 이 외의 것들은 { } 안에 적어야 한다.
#common -> 재사용될 여지가 있는 컴포넌트들만 모아놔야 한다. 사실 쉽게 나오는 항목은 아니다. (그렇다고 들입다 모아놓으면 common 폴더가 가장 많아지는 안 좋은 코드가 됨.)
#기업/기관? -> 기관에서 기부를 하는 경우도 많이 있었음. (경찰서, 소방서 등) 이들이 자신을 기업이라고 인식할까?
#form 길이 제한/ 빈 칸 체크/ 연락처 정규식(추가하기)
#css -> px 전부 rem으로 변환할 것.
#(url) company-register -> company/register
##적절한 항목 나누기는 권한 체크, DB 확인, 카테고리 묶기 등에 필요하다.
#formInfo에 데이터가 없을 때는 버튼이 비활성화 되어야 하기 때문에 if문을 걸어서 조건을 하나 더 추가한다.
#onBlur()의 단점-> 에러가 있는 상태로 제대로 입력하면 버튼이 활성화되지 않음
해결책 -> 1) 각 항목에 중복체크 버튼을 만들어서 확인을 누르도록 유도한다. (그럼 onBlur()는 해결되니까!)
2) onChange()로 바꾼다.
#file uproad를 할 때는 파일 자체가 올라가게 할 수 있음. ref를 걸고?? imagecropper?? input이 2개 있어야 한다. 그리고 숨겨진 input에 ref를 건다. <input type=file>
#파일 업로드는 쉽지 않은 작업에 속한다.
#서버에 파일을 처리하는 api가 따로 있기 때문에 파일 따로, body 따로 올려야 한다.
#파일은 다른 header를 사용한다. (mulipart/form-data)로 보내야 한다.
#body를 먼저 날리고, 해당 저장값의 id로 파일을 저장하거나 반대로 파일을 먼저 저장하고 해당 파일의 url을 body에 추가하여 날리거나 하면 된다. (.then 사용)
#const form = new formData()을 사용하여 form.append("file", f.rawfile")
#form.append로 들어가는 값은 debugger로 보이지 않음.
#history.replace('url') -> 정확한 기능을 알고 사용할 것. 단순한 페이지 전환에는 잘 사용하지 않음.
#material UI에서 paper, card를 레이아웃 잡는데 많이 쓴다.
