솔적솔적

너는 if문을 왜 그렇게 써?그리고 중첩된 else if, 왜 좋지 못한 코드를 쓰는거야?switch문을 사용할 생각은 없는거야? 여기에서 아, 내가 급하게 기능 구현만하려했었다라는 반성 연이어,협업 시 팀원의 분노게이지를 상승시키지않을만한 좋은 코드란 것에 대해서 돌이키며 유념하고자 정리하는 글이다. 소프트웨어에서 기본 원칙이나 클린 코드 등 책들을 읽으며 알았던 좋은 코드에대해서 정리해보면, 코드를 읽는 사람이 쉽게 이해할 수 있어야하는 “가독성” ⇒ 변수명, 함수명, 들여쓰기, 구조가 직관적이어야한다Readability ⇒ 읽기 쉬운가? 코드 수정이나 기능 추가 시 다른 부분에 영향을 최소화해야하는 “유지 보수성”Maintainability ⇒ 고치기 쉬운가? 중복 코드 제거, 모듈화, ..

오늘의 글은window.location.reload()가 위험할 수 있는 이유와,React 프로젝트에서의 더 좋은 새로고침 전략에 대해서 정리해보고자한다. 버튼 클릭 시 “새로고침”이 필요하다는 요구사항을 종종 만납니다. 흔히 떠올리는 건 바로window.location.reload();하지만, 구현하면서 항상 생각해야한다.이 코드가 우리 프로젝트에 적합한 코드인가? 왜 섣부른 전체 리로드가 위험할까 🤔상태 손실이 되어도 괜찮은가: 메모리 기반 상태(React state, Zustand 등 사용 시) 전부 초기화된다.현재 참여 중인 프로젝트는 i18n을 적용해 한국어/일본어 다국어 선택 기능을 제공하고 있는데,단순히 window.location.reload()를 사용하면 이 상태들도 모두 초기화..

웹에서 '로그인 상태 유지' 또는 '자동 로그인' 기능을 구현할 때어느 저장소에 무엇을 두느냐는 보안, 편의성 균형의 문제다. 1편에서 저장소 종류와 특성을 정리했다면2편에서는 공격 벡터인 XXS/CSRF를 기준으로 실전 방어법과설계 패턴을 이리저리 생각하고 구글링한 결과를 정리해볼 예정이다. (*이건 그저 구현하며 저의 생각을 정리하는 내용이지 정답은 아닙니다.)- Access Token, Refresh Token 같은 것은가능한 클라이언트쪽에서 JS접근 불가한 HttpOnly 쿠키 + Secure + SameSite 설정으로 관리하는 것으로하는 것이 좋다생각한다.- Access Token은 가능한 **메모리(짧은 수명)**에서 관리하고 필요 시 refresh cookie로 재발급한다.- 비민감..

자동로그인, 로그인 상태 유지 기능을 구현할 때 고민했던 문제이다. 브라우저 저장소를 어떤 걸 적용할 지 결정할 때,아, 나 로컬스토리지 써봤으니까 그거 써야겠다~라는 생각은? 않하느니만 못하다~git에 푸시 전에 불안하잖아~정말 이 선택이 맞는지~ HTTP의 기본 특성부터먼저, 서버와 클라이언트가서로 소통할 때 지켜야할 규약인 HTTP, HTTP는1. 클라이언트가 request를 보내고2. 서버가 클라이언트한테 받은 request대한 response를 보내고 접속을 종료한다.(통신 끝) 이는 인증에 쓰이는 상태정보를 유지하지 않는 무상태(Stateless) 프로토콜, 비연결성, 무상태성 특징이 있다.이 특징(비지속적인 통신 연결)때문에 자원 낭비가 줄어드는 것은 장점이지만통신을 할 때마다 다시 요청해서..