예전에는 웹 브라우저가 서버에 요청을 하면, 서버에서 완성된 HTML page를 만들어 주는 것이 일반적이었다. 그래서 웹 사이트에서 다른 서버로 요청을 날린다? 하면 개인정보 유출등의 보안적인 행동을 한다고 의심하는 것이 일반적이었다고 한다. 이로인해, 웹 브라우저는 웹 사이트의 요청으로 인해 받은 응답의 서버 도메인이 현재 도메인과 다르면 요청자체를 막아버리는 선택을 하게 된 것이다. 최근에는 웹 사이트에서 할 수 있는 일이 아주 많아졌다. 그러다 보니, 웹 사이트에서 다른 서버로 요청을 보내어 데이터를 받아야 할 수 있는 일도 생겼다. 근데 브라우저 정책상 막혀있으니, 개발자들은 다른 방법을 생각해내었다. 그렇게 나온것이 JSONP이다. html 스크립트 상에서는 다른 도메인에 대한 요청을 하는 것..

웹 브라우저의 구조는 다음과 같다. 1. User Interface : 주소 표시줄, 이전/다음/새로고침 버튼 등의 웹 페이지를 제외하고 사용자와 상호작용하는 사용자 인터페이스 2. Browser Engine : 유저 인터페이스와 렌더링 엔진을 연결하는 브라우저 엔진 3. Rendering Engine : HTML과 CSS를 파싱하여 요청한 웹 페이지를 표시하는 렌더링 엔진 4. Networking : 각종 네트워크 요청을 수행하는 네트워킹 파트 5. Javascript Interpreter : 자바스크립트 코드를 실행하는 인터프리터 (V8) 6. UI Backend : 체크박스나 버튼과 같은 기본적인 위젯을 그려주는 UI 백엔드 파트 7. Data Persistence : localStorage나 Co..

-시크릿 모드에서는 localStorage를 사용하지 못한다. 다라쓰에서는 react-query의 useQuery를 사용하여 user정보를 가져오고 있습니다. 여기서 단점은 react-query들의 정보들은 모두 메모리에 저장되어 있는 것이기 때문에, 새로고침하면 user를 요청하는 동안에는 빈 유저 이미지가 나타난다는 것입니다. 그것을 최대한 방지하기 위해서, 로그인된 상태면 로그인된 유저의 정보를 localStorage에 저장하고 새로고침할때 초기값으로 localStorage 값을 불러와서 먼저 렌더링하도록 했습니다. 물론 로그아웃을 하면, localStorage 정보를 날립니다. 유저 정보같은 경우는 민감한 정보가 없는 부분이라 localStorage에 저장해도 큰 문제가 없다는 판단도 있었습니다...

다라쓰 프로젝트 2개중 하나인, 댓글 모듈의 jest 테스트 커버리지가 평균 70%가 넘었습니다. 구문 커버리지: 82.13% 분기 커버리지: 61.6% 함수 커버리지: 71.17% 라인 커버리지: 82.28% 으로, 평균 74.295%의 커버리지가 나왔습니다. (원래는 16%였습니다 ㅎ) 커버리지가 70%이상이 되면, 그 이상부터는 (좋긴하지만) 유의미한 효과가 없다는 글을 보았기 때문에 목표를 70%로 잡았었는데, 다행히 시간을 갈아넣어서 달성했습니다. 사실, 테스트 파일 1개에 아무 유틸이나 테스트한다면, 유틸 1개만 테스트하는 것이므로 커버리지 100%가 나옵니다.ㅎ 하지만 저는 전체적인 프로그램의 테스트코드를 확인하기 위해서 거의 모든 컴포넌트와, 거의 모든 커스텀 훅에 대해 테스트 코드를 작성..

The `document` global was defined when React was initialized, but is not defined anymore. This can happen in a test environment if a component schedules an update from an asynchronous callback, but the test has already finished running. To solve this, you can either unmount the component at the end of your test (and ensure that any asynchronous operations get canceled in `componentWillUnmount`),..

jest에는 테스트용으로 만들어진 다양한 메서드들이 있다. 그것을 잘알고 적절하게 사용하는 것도 능력인것 같다. localStorage는 Storage 객체로부터 메서드를 상속받기 때문에 __proto__로 접근하여 메서드를 모킹해주어야 하고, throttling같이 시간차로 동작하는 유틸라이브러리는 jest.advanceTimersByTime 메서드를 통해서 가짜로 시간이 흐르게할 수 있다. https://github.com/woowacourse-teams/2021-darass/commit/38e1bd2866f6edbf270c1011fa85e2d561ebc9c5 test: localStorage test 코드 작성 · woowacourse-teams/2021-darass@38e1bd2 Permalink..

심리적인 유리천장을 부수어라. 사실 안되는 이유는 없다. 내가 할 수 있다고 믿고, 그 믿음을 깨지않고 다치고 넘어지는 과정속에서 더욱 성장할 것이다. https://www.youtube.com/watch?v=MdOiIMI0dOg&list=PLYjptegYvghA3uvOqNxyEQEMR2PF3qZfh&index=5&ab_channel=%EC%8A%A4%EC%BC%80%EC%B9%98%EA%B5%BF

jest.spyOn(window.localStorage.__proto__, "getItem"); jest.spyOn(window.localStorage.__proto__, "setItem"); jest.spyOn(window.localStorage.__proto__, "removeItem"); localStorage를 mocking하여 테스트하는 방법은 위와 같다. 일반적으로 localStorage와 sessionStorage는 Storage 객체를 상속받는데, 그 상속받는 메서드를 모킹해줘야한다. 참고로 localStorage와 sessionStorage의 __proto__를 찍어보면 다음과 같다!