오늘은 첫 번째 과제 제출날이다. 오후 2시부터 인턴쉽 강의가 있어서 사실 오늘은 코드수정은 거의 못하고 제출에 집중해서 진행해야 한다. 오늘 해야 할 일은 Readme작성과 배포인데 이 부분은 인턴쉽 강의 끝나고 짧게 회의할 때 인원을 선정했다. 우선적으로 하고 싶은 사람에게 맡기고 없다면 기여도가 적었던 팀원에게 맡기기로 했다. 개인적으로 나는 리드미 작성을 정말 못하기 때문에 다른 팀원분들 중 한 분이 했으면 했다. 정말 다행히도 리드미 작성과 배포 둘 다 하고 싶은 팀원분들이 계셔서 수월하게 배정했다. 그렇게 리드미 작성과 배포가 끝나고 master로 최종 병합한 다음에 master 브랜치를 lock 시켰다. 그리고 과제 제출 페이지에 우리 7팀의 이름을 올렸다. 첫 번째 과제가 공식적으로 끝났다..
프론트엔드 인턴쉽에서 투두리스트 앱을 만드는 과제를 하던 중 UX를 해치는 부분을 발견했다. // 기존 코드 const updateTodoHandler = () => { setIsUpdate(() => true); const newTodo = newTodoRef.current?.value; if (isInputValid(newTodo)) return; onUpdate(todoItem.id, newTodo, todoItem.isCompleted); setIsUpdate(() => false); }; const onUpdateTodo = async (todoId: number, todoText: string, isCompleted: boolean) => { await updateTodo(todoId, tod..
두 번째 회의 때도 역시 이전포스팅 에서도 말했지만 새로운 회의 템플릿을 적용하고 회의를 시작했다. 하지만 생각보다 논의사항에 팀원들이 안건을 적어두지 않아서 길을 살짝 헤매었던 거 같다. 기존에 논의사항을 적어두면 더 효율적인 회의를 진행할 수 있을 거 같아서 많이많이 팀원들에게 강조해야겠다..! 그리고 이번에 새로 도입한 Request For Comments는 비동기적으로 팀원들과 소통하고 싶어서 만든 탬플릿이다. 회의 템플릿중 공유사항 부분에서 각 팀원들에게 현재 진행상황을 브리핑하고 나서 일단 넘어가지만, 그 부분에 대해서 따로 팀원들이 코드를 살펴본 뒤 더 괜찮은 아이디어가 뒤늦게 떠오를 수 있기 때문에 만든 탬플릿인데, 이 탬플릿에 대한 각 섹션을 설명을 하면, Request For Comme..
오늘 오전에 준비한 회의 탬플릿을 들고 작업실로 갔다. 오늘은 어제처럼 생산성이 떨어지는 회의를 하지 않기로 마음을 먹고 좀 더 주도적으로 회의를 이끌어 갔다. 다음은 회의 탬플릿을 기반으로 작성한 회의록이다. ✅ 온도 체크 이** 4 회의 때문에 일찍 나와서 기분이 좋다. 권** 3 김** 3 김** 4 박** 3 우** 이** 3 유** 3 정** 4 조** 3 📢 공유 사항 회의 진행 방식 공유 🗣️ 논의할 주제 날라감... 🤝 의사 결정 사항 PR은 한글로 commit 은 앞에만 맞추고 자유롭게 🔧 Action Items organizations 만들고 초대하기 PR, Issue template, CodeOnwers 추가 RFC 탬플릿 만들어오기 결과 확실히 탬플릿을 가져감으로써 회의의 수준과 생..
인프런에서 토이프로젝트를 새로 하기 위해 인원을 구했는데 그중 한 분이 프런트엔드 인턴쉽이라고 진행하는 이벤트가 있다고 해서 알아봤다. 인턴쉽에서 진행하는 커리큘럼이 너무 필요한 내용이었고 인턴쉽을 모두 수료하면 원티드에서 배지?를 주길래 얼른 신청했다. 일반전형이었기 때문에 과제를 제출해야 했다. 먼저 제출하면 가산점이 추가로 지급된다. 하지만, 4/17에 봐버려 가지고 이틀 만에 만들어보자! 해서 열심히 과제를 했다. 4/19에서 20일로 넘어가기 전에 예상치 못한 버그를 발견해 가지고 열심히 고치다가 20일이 되고도 30분이 더 지나가서 제출했다 ㅜ 그래서 별로 기대를 안 하고 있었는데 다행히 합격했다는 연락을 받았다. 그렇게 4/25, 오늘 첫 수업을 진행했다. 수업은 14:00 ~ 17:40 정..
다음 두 가지 방법으로 상태를 업데이트할 수 있다. const [state1, setState1] = useState({ id: '', name: '', }); const [state2, setState2] = useState({ id: '', name: '', }); setState1({ ...state1, name: e.target.value }); setState2((prevState2) => ({ ...prevState2, name: e.target.value })); 검색을 아무리 많이 해봐도 이 둘의 차이를 명확하게 짚어 주지 않아서 개인 프로젝트로 여러 가지 실험을 해봤다. 거의 동일한 기능이라고 봐도 무방하다. 하지만, 핵심적인 차이점은 이전상태를 고려하지않는다. 즉, 최신 값을 보장할 수..
이번 토이프로젝트로 MBTI 유형을 선택해서 채팅을 할 수 있는 서비스를 구현했다. 서버는 Java, Spring을 사용했고 클라이언트는 React, Typescript를 사용했다. 처음에 버전이 안 맞아서 조금 헤매었었다. "dependencies": { "@stomp/stompjs": "^7.0.0", "react": "^18.2.0", "sockjs-client": "^1.6.1", "typescript": "^4.9.5", }, 보통 라이브러리를 사용하지 않고, 할 수 있다면 구현하는 방식을 해왔는데 웹소켓 라이브러리를 사용하지 않고 단체방, 채팅을 기다리는 방.. 등등 다양한 기능을 구현하는데 어려움이 너무 많을 것 같아서 Stomp 라이브러리를 사용했다. 전체적인 플로우는 다음과 같다. MBT..
1. 하나의 상태만을 위한 렌더링 true일 때만 render하고 false일 땐 render하고 싶지 않을 때, 삼향연사자보다는 &&연산자로 나쁜 예 : import React, { useState } from 'react' export const ConditionalRenderingWhenTrueBad = () => { const [showConditionalText, setShowConditionalText] = useState(false) const handleClick = () => setShowConditionalText(showConditionalText => !showConditionalText) return ( Toggle the text {showConditionalText ? The ..
