요약 1. 스코프는 변와 함수의 유효범위이다. 2. 코드 내에서 변수와 함수의 이름이 충돌하지 않도록 도와준다. 3. 스코프에는 프로그램 전체에서 접근 가능한 전역 스코프와 해당 코드블록이나 함수 내부에서만 접근가능한 지역스코프 두가지 유형이 있다. 설명 스코프란? 식별자의 유효 범위입니다. 모든 변수, 함수, 클래스 등의 이름을 의미하는 식별자는 자신이 선언된 위치에 의해 다른 코드가 자신을 참조할 수 있는지에 대한 범위가 결정됩니다. 왜 필요한가요? 식별자는 어떤 값을 식별할 수 있는 고유한 이름으로 하나의 값은 유일한 식별자와 연결되어야 합니다. 스코프가 없다면, 즉 유효범위가 없다면 매번 새로운 식별자를 만들어야하는 번거로움이 있고 까먹고 앞서 사용한 식별자를 사용시 충돌이 일어날 수 있습니다. ..
설치 1. eslint npm install eslint --save-dev 2. prettier npm install prettier --save-dev 3. eslint-config-prettier - eslint는 linting 하고 prettier는 formatting을 한다. - eslint에 코드를 formatting관련 rule이 일부 포함되어있다. - 이 rule들이 prettier와 다른 설정을 가지고 있으면 설정 충돌이 발생한다. - eslint에서 formatting 관련 rule들을 해제해주는 eslint plugin npm install eslint-config-prettier --save-dev 4. husky - 패키지를 설치해도 작업자가 사용안하면 소용이 없다. - 개인이 확..
React.js 앱이 localhost에서 정상 작동하나 Netlify 배포 후 url 창에 경로를 직접 적어주면 위 이미지와 같은 오류페이지를 볼 수 있었습니다. trobleshooting tips 페이지에 따르면 오류의 원인은 CRA같은 SPA은 각 경로별로 별도의 html 페이지를 받아오는 것이 아니라 JavaScript를 통해 네비게이션을 처리하며 필요한 데이터만을 가져와서 새로운 내용을 화면에 업데이트 합니다. 이런 네비게이션 과정은 브라우저의 url이 변하더라도 실제 페이지 전환이 일어나지 않는 특징을 가지고 있습니다. 그래서 서버(netlify)는 route를 처리하는 방법을 알 수 없으므로 서버에 올바른 리다이렉션 규칙이 없으면 사용자가 특정 경로로 직접 접근했을 때 페이지가 정상적으로 표..
메인프로젝트에서 react-query를 사용해 유저정보를 get요청으로 받아 RTK 전역 상태로 저장해서 사용을 했었습니다. 받은 유저정보 데이터는 staleTime 즉 데이터의 신선도가 0이었기 때문에 계속해서 유저의 정보를 요청하는 api가 계속해서 호출이 되었습니다. 유저정보의 변경이 잦지 않기 때문에 이는 불필요한 호출이라고 판단했고 react-query가 캐싱기능을 제공하는데 RTK로 데이터를 캐싱할 이유가 없었습니다. 비동기 데이터를 리덕스가 관리하는 것이 적합하지 않은 이유는 아래 참고한 블로그에서 dispatch 시점... 에 관하여 설명이 잘 되어있습니다. 그래서 유저정보가 쓰이는 컴포넌트들을 보아하니 1. 헤더 (프로필사진, 닉네임) 2. 메인 글목록페이지 (유저 지역) 3. 마이페이지..
https://letsmomo.netlify.app/ MOMO letsmomo.netlify.app https://github.com/codestates-seb/seb44_main_001 GitHub - codestates-seb/seb44_main_001 Contribute to codestates-seb/seb44_main_001 development by creating an account on GitHub. github.com 디자인과 기능이 정해져 있던 프리프로젝트와 달리 기획부터 디자인, 배포까지 만들어나가는 메인프로젝트가 끝이 났습니다. 아쉬운 점이 많지만 그래도 구현한 기능들은 큰 에러 없이 제대로 동작하며 백엔드와의 데이터연결과 배포에 성공했다는 점에서 스스로 박수를 쳐주고 싶네요. 제가..
프리프로젝트 일지를 매일 작성하고 싶었지만 티스토리 400 에러 이슈 때문에 무려 2주일 만에 블로그에 접속을 했습니다. 아무래도 쿠키가 많이 쌓인 탓에 일어난 에러인 것 같아 크롬 설정에 들어가 티스토리 쿠키를 싹 삭제 해준 후 정상 접속이 되었습니다. 불과 몇 주전에도 이런 일이 있었는데 또 일어나다니 내 탓? 니탓? 모르겠네요. 아무튼 다사다난했던 프리프로젝트가 이번주 화요일에 끝이 났습니다. 결과부터 말하면 서버와의 연결은 실패했습니다. 자세한 이야기들을 앞으로 써내려가 보겠습니다. 팀장이 되었다. 팀 프로젝트라곤 토이플젝이 전부인 제가 팀장이 되었습니다. 3초의 정적을 못참고 마이크를 킨 결과로요. 랜덤으로 배정된 프론트엔드 두 분 백엔드 세 분도 모두 팀 프로젝트 경험이 없었기에 있는 경험 없..
✅ 오늘 한 일 ✔️ 폴더구조 정리 원래는 컴포넌트폴더에 컴포넌트 줄세우려고 했는데 막상 코드를 짜다보니까 어느정도 길어지면 쪼개는 버릇때문에 파일이 점점 많아지기 시작했습니다.. 나중에 쓸 공용 컴포넌트들도 폴더링을 시켜놔야 나중에 쉽게 찾아 쓰겠죠? 처음 회의때는 이렇게까지 할 필요 없지 않을까 했는데 결국엔 이렇게 되어버렸습니다. 혼자 할땐 몰라도 다른사람들과 프로젝트할때는 폴더링을 꼭 해야하겠습니다. ✔️ 글로벌 스타일 스타일 컴포넌트로 설정 style/GlobalStyle.jsx import { createGlobalStyle } from 'styled-components'; const GlobalStyle = createGlobalStyle` :root{ --color-black : rgb(3..
✅ 오늘 한 일 ✔️ 이슈 탭 관리 원래 작업 진행사항은 노션에 기록하기로 했었습니다. 대체크인 상담을 하면서도 깃허브 이슈 탭 사용은 선택사항이라고 하셨어서 유어클래스로 실습해본게 다인 이 낯선 기능은 최대한 지양(피하고..) 싶었는데요 회의를 거치면서 이슈 탭 만큼 명시적인 작업내용을 효율적으로 확인 할 수 있는 툴을 찾지 못했고 팀원들도 사용에 모두 동의해서 한번 사용해 보기로 했습니다! 막상 만들어보니 탬플릿 만들어두기만하면 사용하기 쉬워서 만족하며 사용중입니다. 역시 무섭다고 냅다 피하기보다는 일단 한번 도전해보는게 좋습니다. 이슈 템플릿 1. 버그 report 2. 기능 request → 지금 개발단계에서는 아무래도 2를 많이 사용할것 같고 나중에 테스트를 거치며 1이 많이 쓰일것 같습니다. ..
✅ 오늘 한 일 1. 백엔드분들과 함께 사용자 요구사항 정의서 작성 - 각 페이지에 있는 기능들을 나열해보고 기능 설명과 프론트, 백엔드의 요구사항, 구현 우선 순위를 작성했습니다. - 회의 전 생각보다 각자 전날 회의 하고 나서 정한 기능 구현 범위가 거의 비슷했습니다. 물론 이견이 있기도 했는데 그 때마다 상태 팀을 충분히 설득해야할 근거를 가지고 있어야 할 것 같습니다. 의견차를 좁히지 못하면 구현 우선순위를 아래로두어 두 팀 모두 만족할 만한 결과를 내었습니다. - 사실 저는 서버, 데이터에 거의 문외한이었습니다. Pre-project 직전까지 Next.js로 SSR를 하는 게시판 프로젝트를 하면서 데이터의 요청과 응답하는 코드를 직접 작성해보고 Mongodb로 데이터 베이스까지 관리해본 경험이 ..
✅ 오늘 한 것 1. 프론트엔드팀 회의 - 피그마로 스택오버플로우 기능과 컴포넌트를 뜯어보면서 구조 파악 - 기능구현 가능 범위 파악 - 라이브러리 채택 2. 대체크인 - 팀장으로써 백엔드와 어떻게 소통해야하는지 걱정이 되는데 추상적으로만 와닿아서 상담 신청. - 프리플젝의 의미 백엔드랑 api 얼마나 잘 주고 받는지, 필요한거 잘 요청하고 잘 전달받고 그런거 많이 깨지고 왜 깨졌는지 이해하면서 기록 잘 해두기 - 프로젝트는 최대한 클린코드로 작성하고 하나라도 완벽하게 만드는것이 중요 - 라이브러리사용은 이유가 있는게 좋다 ✅ 해야할 것 - 백엔드와 내일 사용자 요구 정의서 작성하면서 절충안 만들기 - 상태관리 툴정하기
