안녕하세요! 그로스로그 입니다!😊 🌱
무엇을 할지만큼이나 무엇을 하지 않을지가 중요할 때가 있습니다. 2기 9회차 세 편입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
2기 9회차, 2025년 1월입니다. 이번 회차에는 건너뛰는 일을 다룬 세 편이 모였어요. 화면을 안 그리고, 계산을 안 하고, 문제를 안 풀기로 정하는 이야기입니다.
01
🧩 웹페이지 만들기 #2
임준혁 님
Vue.js 공식 문서를 따라가며 만든 실습 기록입니다. 화면 캡처가 서른 장 넘게 붙어 있어요.
반응형 데이터에서 시작해
methods, nextTick, debounce, created·unmounted, computed, 클래스 바인딩까지 한 편에 다 담았습니다.방식이 일정해요. 공식 문서에서 코드를 복사 → 내 프로젝트에 붙여넣고 수정 → 화면에서 확인 → 알게 된 것을 인용구로 정리.
1·2회차에서도 이분의 기록을 소개해드렸습니다. 「웹페이지 만들기 #1」의 이어지는 편이에요. 첫 줄이 그렇게 시작합니다. "저번에 작성했던 기록을 이어서 남긴다."
조금 더 들어가 보면
⏱️ 버튼을 눌렀더니 두 칸씩 움직였다
이 글에서 가장 좋은 대목은 이상한 걸 발견하고 원인을 찾는 부분입니다.
increase에 들어간 nextTick 코드 때문이다.그리고 왜 그런지를 정리해뒀어요.
nextTick는 원래 동작이 갱신된 이후 취할 동작을 정의한다. 동작 간격은 1/60초가 기본값으로써 이 웹화면의 plus 버튼 클릭 시 사실은 두 수가 1/60초 간격으로 변경되고 있다."사실은"이라는 표현이 정확합니다. 눈으로 보면 2가 한 번에 오르는 것 같은데, 실제로는 1이 두 번 오른 것이거든요. 화면 갱신 주기보다 빨라서 중간 상태가 안 보일 뿐입니다.
nextTick이 왜 필요한 문법인지도 여기서 드러납니다. Vue는 값이 바뀔 때마다 화면을 바로 고치지 않아요. 한 박자 모았다가 한꺼번에 반영합니다. 그래서 값을 바꾼 직후에 화면을 읽으면 아직 옛날 값이죠.
nextTick은 "화면이 실제로 갱신된 다음에 이걸 해라"를 예약하는 도구입니다. 새 높이를 재거나 새로 생긴 요소에 포커스를 줄 때 쓰는 것이고요.
직접 만들지 않은 현상을 관찰하고 원인을 코드에서 찾아낸 기록이라, 문서 따라 하기에서 한 걸음 나간 대목입니다.
🚦 연타를 한 번으로 모으기
debounce를 다룬 부분도 설명이 간결합니다.
debounce는 여러 기능들을 입력할 경우 일정 시간 동안의 지연을 통해 그 사이에 입력된 기능들을 한번에 반영되도록 하는 함수이다.그리고 화면에서 확인한 결과를 적었습니다.
"덮어씌우는 식으로"가 debounce의 동작을 정확히 짚은 표현입니다.
이게 실무에서 쓰이는 자리가 검색창이에요. 글자 하나 칠 때마다 서버에 물어보면 요청이 열 번 나가는데, debounce를 걸면 타이핑이 멈춘 뒤 한 번만 나갑니다. 중간의 아홉 번은 건너뛰는 거죠.
앞의 nextTick과 방향이 반대라는 점이 재미있습니다. nextTick은 갱신 뒤로 미루는 것이고, debounce는 갱신 자체를 건너뛰는 것입니다. 둘 다 "지금 바로"를 피하는 도구인데 목적이 다릅니다.
🧷 왜 created에서 만드는가
debounce를 적용하고 나서 코드를 한 번 더 손봅니다. 그 이유가 인용구로 적혀 있어요.
debounce 함수가 적용된 기능들의 인스턴스가 서로 다를 경우 간섭 방지를 위해 created를 사용해 각 기능들을 독립적으로 유지한다.unmounted를 통해 함수의 시행 이후 기존의 이벤트가 계속 동작하는 것을 방지한다.이 두 줄이 이 글에서 가장 실무적인 대목입니다.
첫 줄부터 보면요. debounce는 안에 타이머를 하나 들고 있습니다. 그런데 methods에 바로 적어두면 그 컴포넌트를 여러 개 띄웠을 때 타이머 하나를 나눠 쓰게 돼요. A 화면에서 버튼을 누르면 B 화면의 대기가 취소되는 일이 생깁니다.
created에서 만들면 컴포넌트마다 자기 타이머를 하나씩 갖습니다. 서로 간섭하지 않죠.
둘째 줄은 뒷정리 이야기입니다. 1초 뒤에 실행되기로 예약해뒀는데 그 사이 화면을 닫으면, 이미 사라진 컴포넌트를 건드리려는 코드가 남아 있어요. unmounted에서 취소해야 하는 이유입니다.
만드는 자리와 치우는 자리를 짝으로 적어둔 것이 좋습니다. 예약하는 코드는 늘 취소하는 코드가 짝으로 필요하거든요.
🧮 다시 계산하지 않기
후반부는 computed입니다. 문서의 "Computed Caching vs. Methods" 부분을 가져와 확인했어요.
computed와 methods는 화면에 쓰면 결과가 같습니다. 그런데 computed는 결과를 기억해둡니다. 재료가 되는 값이 안 바뀌었으면 다시 계산하지 않고 저장해둔 답을 줘요. methods는 화면을 그릴 때마다 매번 실행되고요.
여기서도 건너뛰기입니다. 같은 답이 나올 계산을 반복하지 않는 것요.
그리고 Writable Computed로 넘어가면서 짚은 대목이 있습니다.
get은 이전에 존재하던 값을 그대로 이용하기에 새로운 값의 업데이트가 불가능하다.computed는 기본적으로 읽기 전용입니다. 다른 값들로부터 만들어낸 결과니까요. 그래서 화면에서 그 값을 직접 고치려 하면 안 먹힙니다. set을 함께 적어야 비로소 쓸 수 있게 되고요.
글은 여기서도 순서대로 갔습니다. get만 있는 버전을 먼저 만들어 "기본값만 고정적으로 표기되고 있다"를 확인하고, 그다음에 고쳤어요.
📝 원문에서는 이렇게 기록합니다
이 글의 형식이 독특합니다. 캡처 → 한 줄 설명 → 구분선이 서른 번 넘게 반복돼요.
그리고 새로 알게 된 규칙은 인용구로 따로 뺐습니다. null과 undefined의 차이, nextTick의 동작, debounce의 정의, v-bind 생략 가능 같은 것들요.
msg의 속성값 null의 경우 데이터는 존재하지만 특정하지 않은 상태를 의미하며, undefined는 데이터 자체가 존재하지 않는 상태이다.본문은 "무엇을 했는지", 인용구는 "무엇을 알았는지"로 나뉘어 있습니다.
실습 기록에서 이 구분이 꽤 유용합니다. 나중에 다시 볼 때 인용구만 훑으면 배운 것이 모입니다. 캡처를 다 넘겨볼 필요가 없어요.
마지막의 클래스 바인딩 부분에서도 같은 정리가 나옵니다.
data에서 객체 바인딩을 사용하여 코드의 복잡성을 줄이고 추후 코드 수정 시의 편의성을 높였다.클래스 이름을 하나씩 조건에 매다는 대신, 객체 하나로 묶어 여러 속성의 켜짐·꺼짐을 관리하는 방식입니다. 7회차에서 소개해드린 이주희 님의 state 합치기와 발상이 같아요. 흩어진 것을 객체 하나로 모으는 것요.
큐레이터 노트
공식 문서를 그대로 따라간 기록이라는 점에서 고른 글입니다.
이런 기록은 과소평가되기 쉽습니다. 문서에 있는 내용이니까요. 그런데 문서를 읽는 것과 내 프로젝트에 붙여넣고 화면이 뜨는 걸 확인하는 것은 다른 일입니다.
특히 nextTick 대목이 그렇습니다. 문서만 읽으면 "다음 갱신 이후에 실행"이라는 설명이 지나가는데, 직접 붙여보니 숫자가 두 칸씩 오르는 게 보였고 거기서 원인을 찾았어요. 붙여봐야 나오는 질문입니다.
그리고 created·unmounted 부분. 문서를 순서대로 따라가지 않으면 "왜 여기서 만드는가"를 지나칠 수 있는 대목인데, 이유를 인용구로 남겼습니다.
캡처가 서른 장 넘는 기록은 쓰는 데 품이 많이 듭니다. 한 단계마다 화면을 찍고 설명을 붙였다는 것 자체가 꼼꼼함의 증거예요.
02
👀 조건부 렌더링
이주희 님
리액트에서 무엇을 그리고 무엇을 안 그릴지 정하는 방법을 정리한 글입니다.
&&, ||, 삼항 연산자를 각각 코드로 보여주고, 리액트가 아무것도 그리지 않는 값 여섯 가지를 목록으로 정리했어요.그리고 마지막이 이 글의 핵심입니다.
&& 앞에 숫자를 놓으면 생기는 함정을 코드 두 벌로 짚었어요.3·4·7·8회차에서도 이분의 리액트 기록을 소개해드렸습니다. 8회차의 State 정리에서 showMore && ...가 나왔는데, 그 문법을 이번에 정면으로 다룹니다.
조금 더 들어가 보면
🔀 세 가지 방법
먼저 세 가지를 나란히 놓습니다.
{show && <p>보인다 👀</p>} // true면 그린다
{hide || <p>보인다 👀</p>} // false면 그린다
{toggle ? <p>✅</p> : <p>❎</p>} // 참·거짓에 따라 다르게
셋의 쓰임이 정확히 갈려 있습니다.
&& — show 값이 true 이면 렌더링 하고, false 이면 렌더링 하지 않습니다.|| — hide 값이 true 이면 렌더링 하지 않고, false 이면 렌더링 합니다.삼항 연산자 — 참, 거짓일 경우에 다르게 렌더링해줄 수 있습니다.
&&와 ||가 정반대라는 걸 변수 이름으로도 보여줬습니다. 하나는 show, 하나는 hide요. 같은 이름을 쓰고 조건만 뒤집는 것보다 훨씬 읽기 쉽습니다.
이 문법이 동작하는 원리는 자바스크립트의 단축 평가입니다. false && 무엇은 뒤를 볼 필요 없이 false가 되고, true || 무엇은 뒤를 볼 필요 없이 true가 되죠. 그래서 조건이 안 맞으면 JSX 자체가 만들어지지 않습니다.
🚫 리액트가 안 그리는 값들
그다음이 목록입니다. 이 여섯 가지는 화면에 아무것도 안 나옵니다.
{null} {undefined} {true} {false} {''} {[]}
true가 여기 있다는 게 중요합니다.
false가 안 그려지는 건 예상할 수 있어요. 그런데 true도 안 그려집니다. 그래서 &&가 조건부 렌더링에 쓰일 수 있는 거예요. 조건이 거짓이면 false가 남고, 리액트가 그걸 조용히 무시하니까요.
빈 배열 []도 눈여겨볼 만합니다. 목록을 그릴 때 items.map(...)을 쓰는데, 항목이 하나도 없으면 빈 배열이 됩니다. 에러 없이 그냥 아무것도 안 나와요. 5회차 큐레이션에서 짚었던 "비어 있을 때 안내가 없으면 고장처럼 보인다"는 이야기와 이어지는 지점입니다.
그리고 대비되는 목록이 붙습니다.
{0} {1} // 각각 0과 1이 그려진다
숫자는 그려집니다. 0도요. 이게 다음 대목의 복선입니다.
🕳️ 0이 만드는 함정
이 글의 결론에 해당하는 부분입니다.
const [num, setNum] = useState(0);
// ...
{num && <p>num이 0 보다 크다!</p>}
글이 먼저 잘못된 예상을 적어둡니다.
num 값이 0일 때는 false 로 계산되니까 뒤의 값을 계산하지 않기 때문에 아무것도 렌더링 하지 않는 코드 같습니다."~같습니다"로 적은 게 정확합니다. 그렇게 보이지만 아니거든요.
두 단계가 겹친 함정입니다.
먼저 자바스크립트에서 0 && 무엇은 뒤를 안 보고 0을 그대로 돌려줍니다. false가 아니라 0이에요. 단축 평가는 불리언을 만드는 게 아니라 앞의 값을 그대로 내보내는 문법이거든요.
그리고 리액트는 false는 안 그리지만 0은 그립니다. 그래서 화면 구석에 숫자 0이 덩그러니 남습니다.
에러가 안 나니까 더 찾기 어렵습니다. 목록이 비었을 때 화면에 0 하나가 떠 있는 걸 보고 어디서 온 건지 한참 헤매는 일이 실제로 생겨요.
해법도 간단히 적혀 있습니다.
{(num > 0) && <p>num이 0 보다 크다!</p>}
비교 연산을 한 번 거치면 결과가 true나 false가 됩니다. 그리고 그 둘은 리액트가 안 그리죠.
true 나 false 값은 리액트에서 렌더링 하지 않기 때문이죠!앞에서 정리한 목록이 여기서 해법의 근거가 됩니다. 목록을 먼저 놓고 함정을 나중에 꺼낸 순서가 잘 짜여 있어요.
📝 원문에서는 이렇게 닫습니다
마지막 한 줄이 이 글의 성격을 보여줍니다.
"함께 알아두시면"이라고 적었습니다.
앞선 회차에서 소개해드린 이분의 글들은 대부분 코드 두 벌과 짧은 주석이었어요. 자기가 다시 볼 노트에 가까웠습니다. 그런데 이 글은 읽는 사람에게 말을 겁니다.
주제가 그렇게 만든 것 같아요. 문법 정리는 나만 알면 되는데, 함정은 남에게 알려주고 싶어지니까요.
큐레이터 노트
틀리는 코드를 주인공으로 삼은 게 이 글을 고른 이유입니다.
조건부 렌더링을 설명하는 글은 많습니다. &&, ||, 삼항 연산자를 나열하면 끝나죠. 그런데 그것만 알면 0 함정에 그대로 걸립니다. 문법을 몰라서가 아니라 두 규칙이 겹치는 자리를 몰라서 걸리는 거예요.
이 글은 그 자리를 정확히 겨눴습니다. 그리고 순서가 좋아요. 문법 셋 → 안 그려지는 값 목록 → 그려지는 숫자 → 함정 → 해법. 함정을 설명할 재료를 앞에서 미리 다 깔아뒀습니다.
8회차 큐레이션에서 이분의 State 글을 두고 "안 되는 코드를 먼저 올렸다"고 적었는데, 이번엔 되는 것처럼 보이는데 안 되는 코드입니다. 한 단계 더 어려운 자리를 다뤘어요.
03
📚 컴퓨터과학과 3학년 2학기 리뷰
김영진 님
한 학기를 마치고 쓴 복기 글입니다.
앞부분은 학습 방법이에요. 지난 학기에 힘들었던 점을 짚고, 이번 학기에 무엇을 바꿨는지 적었습니다.
뒷부분은 과목별 후기입니다. 여섯 과목 각각에 대해 무엇을 어떻게 준비했는지 남겼어요.
그리고 곳곳에 "이건 안 했다"가 적혀 있습니다.
7회차에서 이분의 트리 총정리를 소개해드렸습니다. 그 노트가 나온 학기의 기록이 이 글이에요.
조금 더 들어가 보면
📅 앞당겨 들었는데 결국 진도율로
글이 지난 학기의 문제부터 짚고 시작합니다.
바꾼 게 둘입니다.
개강하자마자 강의를 듣기시작해서 시험기간에 밤새는 일을 없도록 하고자했다
그리고 실제로 어떻게 됐는지가 이어집니다.
100분짜리 강의가 많기에 그럴수밖에...
계획대로 안 된 부분을 그대로 적었습니다.
복기 글에서 이게 드뭅니다. 보통은 성공한 방법만 남기거든요. 그런데 앞서가려던 계획이 중간에 평균으로 돌아왔다는 기록이 다음 학기에 더 쓸모 있습니다. 계획을 세울 때 그만큼을 미리 빼놓을 수 있으니까요.
이유도 함께 적었어요. 강의 하나가 100분이면 앞서가는 데 드는 시간이 그만큼 커집니다. "의지가 부족해서"가 아니라 "강의 길이 때문에"로 원인을 잡은 게 정확합니다.
🎯 기출을 먼저 푼다
방법 이야기의 핵심이 이 대목입니다.
내가 준비가 덜된 과목은 한번 전체적으로 기출을 먼저 푸는 방법을 익히고 공부를 시작하게되어 훨씬 수월하고 부담이 덜했다.
두 번째 문장이 순서를 뒤집은 대목입니다.
보통은 공부를 다 하고 기출을 풉니다. 실력을 확인하는 용도로요. 그런데 여기서는 준비가 덜 된 과목일수록 기출을 먼저 봤습니다.
이게 왜 효과가 있을까요. 교재를 처음부터 읽으면 무엇이 중요한지 모르는 채로 다 외우려 하게 됩니다. 분량은 많고 기준은 없으니 부담만 커지죠.
기출을 먼저 보면 어느 정도 깊이까지 물어보는지가 보입니다. 그 기준이 생긴 다음에 교재를 읽으면 읽는 속도가 달라져요. 글이 "부담이 덜했다"고 적은 게 그 뜻입니다.
7회차에서 소개해드린 트리 총정리도 이 방식과 이어집니다. 정의는 한 줄, 삽입·삭제 절차는 통째로 적었던 그 노트요. 무엇을 자세히 적을지 정하려면 어떻게 물어보는지를 먼저 알아야 합니다.
✂️ 안 하기로 정한 것들
이 글에는 "안 했다"가 여러 번 나옵니다.
다행히 국비교육시절에 JSP를 많이 다뤄보았어서 (…) 실습쪽 강의는 듣지 않았다
알고리즘 설명하는부분은 대충 들었고 책보고 익히든지 다른 자료구조책을 참고했다
그리고 가장 분명한 대목이 이겁니다.
출제될 가능성도 적고, 한 문제를 위해서 투자하는 시간이 너무 많다고 생각되었고
버린 이유가 두 개 적혀 있습니다. 나올 확률이 낮다는 것, 그리고 그 한 문제에 드는 시간이 크다는 것요.
이건 그냥 포기가 아니라 계산입니다. 같은 시간에 다른 문제를 몇 개 풀 수 있는지를 재본 거예요.
이 판단이 가능하려면 두 가지를 알아야 합니다. 전체 분량이 얼마인지, 그리고 어디서 얼마나 나오는지요. 기출을 먼저 푸는 습관이 그 정보를 만들어줍니다. 앞의 방법과 뒤의 판단이 이어져 있어요.
앞의 두 글과 겹치는 지점이기도 합니다. debounce가 중간 입력을 건너뛰고, computed가 같은 계산을 건너뛰고, (num > 0)이 0일 때를 건너뜁니다. 모두 "안 해도 되는 것"을 골라내는 일이에요.
🤝 가르치면서 공부하기
방법 이야기의 마지막이 함께 공부한 경험입니다.
"가르치기 위해"가 핵심입니다.
혼자 공부하면 "알 것 같다"에서 멈추기 쉽습니다. 그런데 남에게 설명하려면 어디가 비어 있는지가 바로 드러나요. 설명하다 말문이 막히는 자리가 곧 모르는 자리니까요.
그리고 이 문장이 7회차의 트리 총정리와도 이어집니다. 설명을 걷어내고 정의와 절차만 남긴 노트를 만들 수 있으려면, 그전에 설명을 해본 적이 있어야 하거든요.
📝 원문에서는 이렇게 씁니다
과목별 후기의 형식이 일정합니다. 각 과목마다 왜 들었는지 → 어떻게 준비했는지 → 무엇을 조심할지요.
쿠키, 세션, 웹서버 등 웹의 기본에 대해서 배울 수 있어서 (…) 코딩은 직접해보면서 익혀야한다
"왜 들었는지"가 앞에 붙어 있는 게 이 후기의 특징입니다.
과목 후기는 보통 난이도와 학점 이야기로 흐르는데, 여기서는 선택한 이유가 먼저 나옵니다. 그러니까 읽는 사람이 자기 상황에 대볼 수 있어요. 목적이 다르면 같은 과목도 다르게 준비해야 하니까요.
그리고 선수 과목 조언이 반복됩니다.
C를 배운 후에 배우길 강추한다. C 코드를 읽지 못하면(포인터, 구조체..) 만점받긴 힘들거다.
두 과목에 같은 조언을 붙였습니다. 순서를 잘못 잡으면 고생한다는 것요. 시간표를 짜는 사람에게 바로 쓰이는 정보입니다.
마지막 문단도 담백합니다.
학우들과 같이 공부했던게 참 도움이 많이 되었던 것 같다. 참여 열심히해준 분들께 감사합니다
큐레이터 노트
한 학기를 통째로 복기한 글이라 골랐습니다.
성장일지에는 그날그날의 기록이 많이 올라옵니다. 오늘 배운 문법, 오늘 만든 기능이요. 그런데 한 구간을 마치고 뒤를 돌아보는 글은 드뭅니다.
이 글이 그걸 합니다. 그리고 회고에서 흔한 다짐형 문장이 거의 없어요. 바꾼 방법과 그 결과가 사실로 적혀 있습니다. 앞서가려 했지만 평균으로 돌아왔다는 것까지요.
무엇보다 "안 했다"가 여러 번 나오는 게 이 글의 값어치입니다. 공부 기록에서 안 한 일을 적기는 쉽지 않습니다. 덜 한 것처럼 보이니까요. 그런데 한정된 시간에 무엇을 뺐는지가 실제로는 가장 재현 가능한 정보입니다.
7회차의 트리 총정리와 이 글을 함께 놓으면 한 학기가 보입니다. 공부하면서 만든 노트와, 끝나고 쓴 복기요.
💡 세 편을 겹쳐 읽으며
세 글이 있는 자리가 전혀 다릅니다. Vue 실습 화면, 리액트 문법 정리, 한 학기 복기요.
그런데 셋 다 하지 않기로 정하는 이야기를 합니다.
건너뛰기에도 종류가 있다
무엇을 건너뛰는지가 셋 다 다릅니다.
임준혁 님의 debounce는 중간 입력을 건너뜁니다. 연타한 열 번 중 마지막 하나만 반영해요. 나머지 아홉 번은 사라지는 게 아니라 덮어씌워집니다.
같은 글의 computed는 같은 계산을 건너뜁니다. 답이 달라질 이유가 없으면 저장해둔 걸 그대로 줘요.
이주희 님의 조건부 렌더링은 그리는 일 자체를 건너뜁니다. 조건이 안 맞으면 JSX가 아예 만들어지지 않죠.
김영진 님은 문제를 건너뜁니다. 나올 확률과 드는 시간을 재보고 몇 개를 버렸어요.
"안 해도 되는 것"과 "지금 안 해도 되는 것"이 섞여 있습니다. debounce는 미루는 쪽이고, computed와 조건부 렌더링은 아예 안 하는 쪽이에요.
건너뛰려면 기준이 있어야 한다
그런데 세 글 모두 건너뛰기 전에 무언가를 먼저 알아둡니다.
computed가 다시 계산하지 않으려면 무엇에 의존하는지를 Vue가 알고 있어야 합니다. 재료가 바뀌었는지 봐야 건너뛸지 정할 수 있으니까요.
(num > 0) &&가 안전한 이유도 true·false는 안 그려진다는 규칙을 알기 때문입니다. 목록을 모르면 왜 이렇게 고쳐야 하는지 알 수 없어요.
김영진 님이 문제를 버릴 수 있었던 것도 기출을 먼저 봐서 출제 범위를 알았기 때문입니다. 범위를 모르면 무엇을 버려도 되는지 판단할 수 없죠.
건너뛰기는 게으름이 아니라 정보에서 나옵니다. 무엇이 중요한지 알아야 나머지를 뺄 수 있습니다.
안 한 것을 적어두기
세 글의 형식에서도 공통점이 하나 보입니다. 안 되는 경우, 안 한 일을 기록에 남겼다는 것.
임준혁 님은 get만 있는 computed가 "기본값만 고정적으로 표기되고 있다"를 확인하고 넘어갔습니다. 고친 코드만 올려도 됐을 텐데요.
이주희 님은 0이 화면에 남는 코드를 통째로 올렸습니다.
김영진 님은 교과서를 안 읽었다고, 실습 강의를 안 들었다고, 시간 많이 드는 문제는 버렸다고 적었습니다.
성공한 방법만 적힌 기록은 재현이 안 됩니다. 같은 시간 안에 그 일을 하려면 무엇을 뺐는지가 함께 있어야 하니까요.
이번 회차에서 가져갈 것
1. 화면이 이상하면 원인을 코드에서 찾아보기.
"숫자가 두 칸씩 오른다"에서 nextTick을 찾아낸 방식입니다. 눈에 보이는 현상과 코드의 어느 줄이 연결되는지를 짚어두면 그 문법이 오래 남습니다.
2. 예약하는 코드에는 취소하는 코드를 짝으로 두기.
debounce를 created에서 만들었으면 unmounted에서 정리해야 합니다. 화면이 사라진 뒤에 실행되는 코드는 조용히 문제를 만듭니다.
3. && 앞에는 숫자를 놓지 않기.
0 && ...은 false가 아니라 0을 돌려주고, 리액트는 0을 화면에 그립니다. (num > 0) &&처럼 비교를 한 번 거치세요.
4. 준비가 덜 된 것일수록 기출을 먼저 보기.
무엇을 어느 깊이로 묻는지 알고 나면 교재를 읽는 속도가 달라집니다. 다 알고 나서 확인하는 순서보다 부담이 적습니다.
5. 버릴 것을 정할 때는 두 가지를 재기.
나올 확률과, 거기 드는 시간요. 둘 다 재봐야 버리는 게 계산이 되고, 안 재면 그냥 포기가 됩니다.
2기 9회차는 2025년 1월이었습니다. 한 학기를 끝내고 다음을 준비하던 시기예요.
Vue 실습과 리액트 문법과 학기 복기라는 서로 다른 자리에서, 세 분이 나란히 덜어내는 법을 기록했습니다. 새해 첫 회차라 그랬을까요.
좋은 글 남겨주신 임준혁 님, 이주희 님, 김영진 님께 감사드립니다. 그리고 2기를 함께 채워주신 모든 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.