일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
- 접근 제한 라우팅
- CI/CD
- socket.io
- S3
- Redux
- 스파르타코딩클럽
- 채팅방
- setstate
- Preview
- Github Actions
- rendering
- 브라우저 렌더링
- qwe
- routing
- 7기
- 라우팅
- 배포
- route
- 개발
- 동기
- useEffect
- FileReader
- 미리보기
- 후기
- 비동기
- previousState
- react
- imagePreview
- 항해99
- updater
- Today
- Total
목록2022/07 (21)
삐옹
문제 소속된 워크스페이스 목록을 조회하는 요청과 내가 받은 초대장 목록을 조회하는 요청(GET요청 x2)이 2개의 useEffect 안에서 실행되고 있다. 전역 state를 이용해 같은 slice의 다른 키 값으로 업데이트 요청을 보내는데 소속된 워크스페이스 목록의 값을 잘 불러왔다가, 또 어떤 때는 값이 들어왔다가 다시 초기값으로 돌아가는 상황. Redux로 저장한 배열의 값이 여러번의 렌더링을 거친다. 초깃값 -> 업데이트 -> 초깃값 or 초깃값 -> 업데이트 패턴으로 리렌더링 할 때마다 들어오는 값이 달라짐 그래서 어떤 때는 배열 값이 비어있어서 에러가 뜨고 또 어떤 때는 잘 읽어온다. 예) 첫 렌더링 - arr = Array(0) / 두 번째 렌더링 - arr = Array(3 ) / 세 번째 ..
상황 워크스페이스를 누르면 해당 워크스페이스의 이름을 가져와 화면에 뿌리고 새로고침 했을 때도 유지되게끔 하기 문제 const [workSpaceName, setWorkSpaceName] = useState(""); // 2 useEffect(() => { localStorage.setItem("workspace", workSpaceName); // 3 }, [workSpaceName]); ... return ( ... workspaceList.map( ... return { setOpenDropdown(false); setWorkSpaceName(item.split("+")[1]); // 1 }} > ...) ... ) li태그 클릭 -> state 업데이트 -> ls(local storage)에 저장..
나만 이럴까 어느덧 프로젝트를 시작한지 벌써 1달이 되었다. 실력은 정체된 느낌으로 마구잡이로 하고있다는 생각이 많이 드는 요즘이다. 아무래도 백엔드 팀원들의 속도를 맞춰주고픈 조급함과 부담감때문에 팔다리는 바쁘게 움직이지만 앞으로 한 발짝도 나아가고 있지 못 하는 사람이 된 느낌이다. 이럴때일 수록 조급함을 내려놓고 좀더 여유를 갖고 가는게 맞는걸까. 결국엔 발표날이 끝이 아니니까. 그러면서도 한편으론 발표날 꽤나 완성도있는 작품을 보여주고 싶은 욕심에 또다시 조바심이 드는건 어쩔 수 없다. 여유를 갖고 후회 없이 열심히 하는게 답인가보다. 내일은꼭...! 워크스페이스 유무, 워크스페이스 선택 유무에 따라 다른 화면을 보여주는 과정이 요 며칠 나를 미치게하고 있다. 이게되면 저게 안되고, 저게되면 이게..
로그인을 어떻게 유지하고 있냐는 멘토님의 기본적인 질문에 답하지 못 했다. 정말 창피하다.. 한참 전에 로컬스토리지에 로그인 유저 정보를 담아 그 정보의 유무로 App.js에서 라우팅을 해줬었는데, 그 후 로그인, 회원가입 부분에서 큰 코드 수정이 있었다. 리덕스에 상태관리를 했던 것 같기도 했는데.. 내가 써놓고 내가 기억도 못 한다니 참 답답했다. 멘토님도 그 부분을 캐치하시고 처음부터 로직이 명확하게 짜여지지 않은게 문제라고 하셨다. 로그인을 하고나서 새로고침을 했을 때 그 상태를 저장하는 로직이 보이지 않는데, 지금 어떻게 로그인 유지를 하고있나요? 머리를 세게 맞은 느낌이었다. 아파.. 그래서 로그인을 하는 플로우와 방법을 명확하게 다시 정리해본다.
상황 로그인을 하고나서 workspace 배열 내에 데이터 유무에 따라 처음 로그인한 사람(뉴비)과 기존 유저에게 다른 화면을 보여주어야 한다. 생각 할 것 앱의 상태에 따른 state 관리가 핵심이다. workspace 배열 내에 데이터 유무에 따라 유저의 상태를 어떻게 표현 할 것인지 명시한다. (앱의 상태를 나타내는 state를 만든다.) 로그인 일 때와 아닐 때를 구분한다 뉴비인지 아닌지 판단하는 상태를 만들기 로딩 중 일 떄와 아닐 때 를 구분하는 상태만들기.(스피너를 위함! 난 꼭 스피너를 넣어야겠음!) +) 로그인 상태 유지하기 순서대로 코드로 살펴보기 상황 별 유저의 상태 // App.js // 정리해보면 유저의 상태는 3가지로 나뉜다 // 워크스페이가 있는지 없는지 판단 중일 떄 -> "..
상황 채팅 목록에서 팀원의 프로필을 클릭 시 채팅 방으로의 join과 leave 이벤트가 모두 이루어져야했다. 문제 클릭했을 때 join과 leave가 하나의 함수 안에서 함께 쓸 수 있는가? (어떻게 떠남과 들어옴을 같이하지..?) 함께 쓰일 수 있다면 어떤 제한을 걸어주어야 하는걸까? 해결 역시 스택오버플로우 너무너무 좋은 인사이트를 얻었다.! moveRoom 이라는 함수를 만들어서 이동 전의 방이름 from과 이동 후의 방이름 to을 인자로 받아서 leave이벤트와 join이벤트에 담아 보내주면 되는 것 이었다. 그런데! 맨 처음 입장을 하게되면 oldRoom 이라는건 당연히 없다 그 상태에서 분명 에러가 날 것이라며 혼자 쉐도우 복싱을 해댔는데, 결론은 없어도 아무 문제없었다. // 입장 + 퇴장..
무엇이 문제인가? 서버로부터 데이터 리스트를 받아와 성공 처리로 3가지 카테고리로 나누어 각각의 state에 갱신했다. 그러면 각각의 저장된 state값을 화면에 map을 돌려 뿌려주면 되는 상황. 문제가 발생한 이유는 무엇인가? useEffect에 의해 첫 마운트 후 데이터 리스트를 받아와 map안에 switch문을 돌려 미리 만들어놓은 각 카테고리 state 별로 갱신해주었다. 데이터 리스트에는 내가 생성한 23개의 데이터가 분명 쌓여있는데.. 새로 고침을 눌러도 분명 잘 남아있는데.. 각 카테고리 state에는 가장 최근에 추가한 데이터 단 한개만 들어온다. 그래서 화면에는 초라하게도 1개의 데이터만이 보인다. 시도해 본 것 데이터 생성 후 새로고침하면 데이터 갯수가 1개 추가되어 있는가? ✅ 데이..
어떤 문제점을 겪었는가? POST 요청으로 게시글을 추가하고, useEffect를 이용해 게시글 목록을 가져오는 GET 요청에서 무한 요청이 걸렸다. 좀더 두면 노트북이 터져버릴 것 같아 서둘러 브라우저를 닫아버렸다. 왜 이런 문제가 발생했는가? POST요청 const [allBoard, setAllBoard] = useState([]); ... // board 생성 const handleSubmit = (e) => { e.preventDefault(); axios({ method: "post", url: "http://54.180.29.68/api/post", data: data, headers: { Authorization: `Bearer ${getItemFromLs("myToken")}`, }, }..
항상 자신과 팀을 돌아보기 소통의 중요성은 늘 깨닫고 있었지만 깨닫고만 있던게 문제였다. 해결을 위해 발벗고 뛰어야 했었다. 그러나 그러지 않았던 결과는 생각지 못 했던 좌절감들을 맛 보여주었다. 하지만 이런 좌절감 또한 내 성장의 밑거름이라 믿는다! 이 실패를 밑거름 삼아 동료들에게 긍정적인 에너지와 영감을 주는 사람이 꼭 되고싶다. MVP 3주 동안 코드 짜는데만 열중하다가 지금와 생각해보니 내가 뭘 한거지? 싶은 생각이 먼저 들었다. 왠만하면 바쁘더라도 순간순간 바로 정리를 하는 습관을 들이고 안된다면 메모에 자세히 적어놓자. ps) 항해 동기 중 엘리트 자리르 꿰차고 계신 지은님께 트러블 슈팅을 언제 하시냐 여쭤보니. 해결방법을 찾아서 머리를 탁! 칠때 바로 작성을 한다고 하신다. ㅋㅋㅋㅋㅋㅋㅋㅋ..
뒤도 안돌아보고 프로젝트를 진행한지 어언 3주차.. 시간에 비해 한건 많이 없는 것 같지만 이쯤되니 생각났다. 언제까지 http:localhost:3000을 보고만 있어야할까. 야레야레.. 나 말야.. 이런거 지긋지긋 하.다.고 . 당연한 말이지만 localhost에서만 작동하는 서비스는 서비스로서 전혀 의미가 없다. 솔직히 배포하면 CI / CD 를 또 하라는데 난 그게 뭐고 왜 해야하는지도 잘 모른다. 알아보는 김에 S3로 배포하는 이유도 정확히 알아볼까한다. 정말 가벼운 마음으로 S3, CI/CD, CI/CD를 도와주는 툴들, Github actions 에 관해 정리해본다! S3 Simple Static Storage. 웹사이트를 배포할 경우 기반이 되는 HTML파일- 거의 예외없이 index.ht..