네이트와의 첫 멘토링!

팀이 바뀌고 처음으로 멘토링을 진행했다. 각자 소개를 하고 앞으로의 방향성에 대해 이야기를 나누었다. 또한 react 학습 질문 2가지를 해서 설명을 들을 수 있었다.
1. state는 const로 선언이 되는데 어떻게 setter를 사용하면 값이 바뀌는지?! 내부 동작 원리가 궁금하다.(추후 포스팅 예정!)

2. update function 규칙
   이것은 추가적으로 공식문서를 읽은 후 완전히 내것으로 만들었다!

   but useState의 내부 소스코드 구조가 궁금해서 뜯어보는 중.. 아마 한달정도 걸리는 여정일 것같다. 시간을 잘 분배해서 틈틈히 뜯어볼 예정! 완료가된다면 포스팅 할 예정이다 ㅎㅎ

메이커준 특강

오늘은 메이커준님과의 특강이 있었던 날! 약 1시간 반 정도 진행을 했고, 많은 인사이트를 얻은 시간이었다 ㅎㅎ 특강은 둥글게 둘러앉아서 진행했는데 편안한 분위기 속에서 많은 질문을 할 수 있어서 좋았다.

1. React 공부가 너무 힘들어요

   소프트웨어를 공부할 때 개념을 개념적으로 공부하고자 하면 너무나 힘들다.

   실제 사용하는 맥락을 만들어야 습득이 훨씬 수월하다.

   • 간단하지만, 쓸 것 같은 사이트를 만들어봐야 활용능력이 높아진다.
   • 모법생 같은 공부법은 개발자 마인드에서 벗어남!
     • ex) 상태를 어떻게 관리하지? 이런식은 안되고

2. 가고싶지 않은 회사에 합격할 경우, 가는게 나을지, 공부를 더 하는게 나을지?

   • 좋은 회사를 고르는 기준?
     • 나에게 잘 맞는 좋은 회사를 고르는 기준
     • 내가 생각하는 것과 인재상이 다르거나 나의 장점을 어필하기 어려운 회사일 수도 있다.
     • 합격 확률을 가장 높이는 것은 내 장점을 강조하는 게 좋다.
       • 채용 시장이 좋지 않다.
     • 완벽한 사용자 경험. 사용자를 위해 어떤 고민을 여겼는지? 등이 채용공고에 잘 들어나있다.
   • 이런 회사는 피하라?
     • 회사나 팀을 리스트업 해보고 그 회사나 팀의 insider들. 사람들을 컨택해봐라
       • 커피챗 필수

3. 내 장점을 살리는 것이 가장 즁요한 것이라고 함. 부트캠프가 지금까지도 굉장히 많았고, 앞으로도 많이 생길텐데, 기술적인 커리큘럼은 비슷할 것이라 생각한다. 예를 들어 각광받는 리액트를 학습한다던가.. 그래서 주니어의 입장에서 기술적 역량은 다들 크게 차이가 나지 않을 것이라 생각하는데, 그 안에서 나만의 차별점을 어떻게 찾을 수 있을지 궁금합니다.

   차별점을 찾는 방식

   개념책 보다는 프로덕트를 만들어라~

   • 사용자가 나 혼자인 것도 좋다. (내가 불편한 것 만들면) 더 자주 유용한 경험을 할 수 있을 것!

   • 웹에 대한 엔지니어링 적인 역량이 뛰어난 경우 - 기술적 문제를 해결하는 엔지니어 (뼈개발자)

   • 최소한의 기술로 좋은 프로덕트를 만드는 경우 - 프로덕트 적인 측면에서 커리어를 쌓기

   • 풀스택 - 서비스가 동작되기 위한 인프라, 백엔드, 기획자 등의 협업을 잘 해나가는 경우

   → 릴리즈 되지 않는 프로덕트를 만들어보지 않으면 3가지 영역 다 경험해보지 못한다.

4. 공부를 할 때 도움을 받는 게 좋을지, 혼자서 끝까지 찾아보는게 좋은지

   • 문제 해결 과정을 효율적으로 해결하기 위해서 여러 도움을 받는게 더 효과적인 것 같다.
   • 왜냐 우리는 아직 너무 모르는 것이 많다.

   나는 문제를 해결할 때 어떻게 문제를 해결해 나가는가? 시퀀스를 찾아보기

5. 이런 사람이 전문성을 가진 엔지니어가 되더라! 어떤 특징이 있는가?

   • 잘하는 주니어 개발자일 수록 생각보다 다른 사람들에게 도움 요청을 잘한다.
   • 덩어리로 되어있는 요구사항을 잘 쪼개는 능력. 문제 해결의 우선순위를 잘 수립하는 사람
     • 하지만, 혼자서 수립하기는 힘들며 많이 물어봐야한다.
   • 요구사항을 잘 분석하는 엔지니어의 특징은? - 기획자, 디자이너와 친하다 ㅋㅋㅋ
     • 잘되고 있어도, 잘 안되고 있어도 항상 소통하면서 그들에게 진행사항을 공유하라
   • 현실세계의 문제는 불확실성이 높기 때문에 메타 인지가 중요하기 때문에 소프트 기술이 중요하다

6. 지치지 않고 공부하는 방법?

   같이하면 안지침

7. 프로젝트 버그가 너무 사소한 것 밖에 안나오는데, 프로젝트를 관철하는 특별한 문제해결을 경험하기 위해서는 어떤 준비가 필요할지?

   • 그래서 사용자가 있는 프로젝트가 중요하다.
   • 사용자의 피드백을 받으면서 그걸 잘 풀어내고 빠르게 다시 좋게 만드는 것이 중요한 역량이다.

8. 한달 전에 적었던 글을 다시 보면 인사이트를 얻을 수 있다.

   • 모르는 것을 정리해 두고, 미래의 나에게 물어보는 방법도 있다.
   • 모르는 것에 대한 지도를 만들기. 실수 데이터베이스 만들기

💡 내가 어떤 가치를 만들어내고 어떤 문제를 해결할 수 있는 사람인가?

1. 삽질하다가 “결국 내가 해결하려는 것은 뭐지?”라는질문을 다시 하기!!!!

   • 목표가 추상적이고, 너무 크면 힘들다. 쪼개기가 가장 중요. 어떤 validation을 해야하는 것인지 인지를 하면서 삽질하기

2. 영어 ..ㅋㅋㅋㅋ

   • 항상 영어가 어려운데.. ㅠㅠ 딮엘 얘기를 또 해주셨다 ㅎㅎ 헤헤 ^^
   • 처음으로 영어 보다는 문제해결에 집중하라는 답변을 해주신 멘토분이었다. 다들 영어는 필수 역량이고 어쩔수 없이 공부해야지.. 하셨는데 ㅋㅋㅋ .. 드!디!어! 처음으로 지금은 영어보다는 학습에 집중하라는 답변을 받았다><
   • 물론 성장하는 개발자가 되려면 영어라는 툴을 잘 사용해야한다.ㅎㅎ ^^

3. Devfolio

   • 개발자이 올리는 포트폴리오를 많이 찾을 수 있다(사이드 플젝 많이 찾을 수 있음!)

4. 코딩테스트 문제 정하기

   • 검은색 지대 - 도저히 모르겠다
   • 회색 지대 - 아리까리?!
   • 흰색 지대 - 어떻게 풀수 있는지 시뮬레이션이 되는 문제

• 회색 지대에 있는 문제들을 하루에 한개 or 일주일에 2~3개 정도 풀어본다.
• 같은 문제를 다른 방법으로 2~3번 풀어본다.

오늘의 나는 무엇을 새롭게 배웠나요?

[1] 입력폼 다루기

const handleTitleChange = (e) => {
    setTitle(e.target.value);
  };
<input value={state} onChange={handleTitleChange}></input>

state가 input의 value에 반영되고 handleTitleChange라는 핸들러는 onChange 이벤트가 발생될때마다 실행는데, 그 내부에서는 setter를 호출한다.

이때 onChange prop은는 html 요소의 oninput 이벤트와 같은데, 입력값이 바뀔때 마다 발생하는 이벤트이다. (html의 onchange와는 다르다)

HTML과 다른 점

1. onChange

리액트에선 HTML과 다르게 onChange Prop을 사용하면 입력 값이 바뀔 때마다 핸들러 함수를 실행한다. oninput 이벤트와 같다

1. htmlFor

<label /> 태그에서 사용하는 속성인 for 는 자바스크립트 반복문 키워드인 for 와 겹치기 때문에 리액트에서는 htmlFor 를 사용한다.

onSubmit

html의 form 태그의 기본 동작은 submit 버튼을 눌렀을 때, 입력 폼의 값과 함께 GET request를 보낸다(그리고 새로고침)

Controlled Component

** state가 input의 value에 반영되고

→ 이러한 방식을 Controlled Component라고 한다

• 인풋의 value값을 리액트에서 지정
• 리액트에서 사용하는 값과 실제 인풋 값이 항상 일치하기 때문에 동작를 예측하기 쉽고 input값을 여러군데에서 쉽게 바꿀수 있는 장점이 있어 권장된다.
• 비제어 컴포넌트를 사용하는 경우도 있는데, 대보적으로 File Input이 있다.
  • 인풋 태그의 value 속성을 리액트에서 지정하지 않고 사용하는 컴포넌트입니다.

file input은 제어 컴포넌트로 사용하면 error가 생긴다!
file input의 value 속성은 사용자만 직접 바꿀 수 있고, javascript는 빈문자열로만 변경 가능 (즉 초기화는 가능)

ref

원하는 시점에 실제 DOM노드에 접근하고 싶을 때 사용할 수 있는 prop

ref 객체

const inputRef = useRef()
// ...
return <input type="file" onChange={handleChange} ref={inputRef} />;

• console.log(inputRef)를 하게되면 current 프로퍼티가 있고, FileInput을 가리킨다는 것을 알 수 있다.
• DOM노드는 렌더링이 끝났을 때만 존재하기 때문에, ref 객체의 current 값도 화면에 컴포넌트가 렌더링 됐을 때만 존재하는 점을 유의!
  • 조건부 렌더링 등을 했을 때 없을지도 모르니까 if로 예외처리 해줘야함

objectURL 만들기

URL.createObjectURL(file)이라는 함수로 생성 가능 . 반환하는 문자열로 해당파일의 주소처럼 쓸 수 있음

• blob으로 시작하는 임시 생성 주소가 생성됨
• objectURL을 만들면 웹 브라우저는 메모리를 할당하고 파일에 해당하는 주소를 만들어준다.

사이드 이펙트

네트워크 리퀘스트나, 메모리 할당같이 컴포넌트 함수에서 외부의 상태를 변경하는 것을 사이드 이펙트라고 한다. 이를 정리하기 위해 useEffect를 활용한다.

[2] update function 완벽 이해

set functions, like setSomething(nextState)

useState가 반환하는 set 함수를 사용하면 상태를 다른 값으로 업데이트하고 렌더링을 다시 트리거할 수 있다.

다음 상태를 직접 전달하거나 이전 상태에서 계산하는 함수를 전달할 수 있다:

const [name, setName] = useState('Edward');

function handleClick() {  
	setName('Taylor');  // 상태를 직접 전달
	setAge(a => a + 1);  // 이전 상태에서 계산하는 콜백 전달
}

setter의 즉, 파라미터로 nextState(상태가 되길 원하는 값)을 전달하면 된다.

모든 type의 값이 들어갈 수 있지만, 함수(=콜백)가 들어가면 특별한 동작을 하는데, 이를 updater function이라 한다.

함수를 nextState로 전달하면 updater function로 취급된다.

⚠️ updater function 규칙!

이 함수는 순수해야 하고, 보류 중인 state를 유일한 argument로 사용해야 하며, 다음 상태를 반환해야 한다.

React는 updater function을 queue에넣고 컴포넌트를 re-rendering한다. 다음 렌더링 중에 React는 queue에 있는 모든 updater 를 이전 state에 적용하여 다음 state를 계산한다.

①React는 state update를 일괄 처리(batch)한다. ②모든 event handler가 실행된 뒤, set function을 호출한 후에 화면을 update한다. ③이러면 single event 중에 여러번 rerendering이 되는 것을 방지한다.

class Example extends React.Component {
  state = { count: 0 }

  handleClick = () => {
    this.setState({ count: this.state.count + 1 })
    this.setState({ count: this.state.count + 1 })
		console.log(this.state.count)
  }

  render() {
    console.log('render called')
    return (
      <button onClick={this.handleClick}>
        Click me ({this.state.count})
      </button>
    )
  }
}

버튼을 클릭하면 handleClick() 는 다른 count 값으로 setState를 두 번 한다. 하지만 React는 이 두 호출을 ①batch해 한 번의 업데이트에 모두 적용하므로 컴포넌트는 한 번만 다시 렌더링하고 카운트 값은 2가 됩니다. ②이때 console.log로 출력되는 값은 1이다. 그 이유는, state update가 event handler가 모두 실행 된 후 set function을 호출하기 때문이다.

공부하면서 어떤 어려움이 있었나요?

1. 재렌더링 이슈

import { useState, useEffect } from "react";

export default function App() {
  const [count, setCount] = useState(0);

  const handleOneCount = () => {
    setCount(1);
  };
  const handleZeroCount = () => {
    setCount(0);
  };

  console.log(count);

  return (
    <div className="App">
      <h2>{count}</h2>
      <button onClick={handleOneCount}>1로 만들기</button>
      <button onClick={handleZeroCount}>0으로 만들기</button>
    </div>
  );

이 코드를 실행했을 때, 1로 만들기 버튼이나 0으로 만들기 버튼을 연속으로 클릭하면 console.log(count)가 2번 발생하고, 3번째 부터는 출력이 안되는 이슈가 발생했다.

즉, 처음 값을 0으로 해뒀고, 최초 렌더링때는 당연히 0이 콘솔이 찍힌다. 그 후, 0으로 만들기를 누르면 state가 변하지 않아서 콘솔에 아무런 변화가 없다.
다음으로 1로 만들기 버튼을 한번 누르면 state가 변하고 렌더링이 발생한다. 이때 console도 실행이 되어서 1이 출력된다. ⛔ 문제는 이곳!
한번 더 1로 만들기를 눌렀을 때, state가 변하지 않았는데 또 1이 출력된다. 그런데, 또 한번 1로 만들기을 누르면(즉 2번 이상 누르면) 콘솔이 실행되지 않는다.(즉 출력이 없다)

이유를 찾기 위해 많은 구글링을 했고, "React console twice"와 같은 키워드로 찾아보았는데 많은 사람들이 추측한 것은

<strict mode 가 원인이다> 였다.
→ strict 모드는 예정된 사이드 이펙트를 방지하는데 매우 도움이 된다

<React.StrictMode>
    <App />
  </React.StrictMode>

이 부분의 wrapping을 주석처리하면 strict mode가 아니게 되어서 다시 1번만 출력된다.

직접 실험결과, 이건 아예 클릭 1번에 2번 출력이 되는 것. 다른 경우이다.

이 가설을 증명하면서 이런저런 자료를 습득한 결과, rendering과 running이 다름을 꼭 인지해야한다는 것을 알게 되었다.

나의 의문은 "클릭을 1회하고, 또 1회했을 때 state가 바뀌지 않으면 렌더링이 일어나지 않아서 2번째때는 콘솔이 찍히면 안되는 것 아닌가?!" 였는데, 이 명제 자체가 잘못된 것이었다.

funtional component 에서 리턴전에 console.log()를 넣으면 리렌더링 시에 콘솔이 찍힌다는 맞는 말이지만, 콘솔로그가 찍히면 component 가 리렌더링이 된것은 아니라는 말이다. 즉, 컴포넌트가 running되면 console.log()는 찍히는 것이다.

그렇다면, 컴포넌트 running 과 rendering의 차이는?

• 실행(running)은 컴포넌트와 연관된 메서드 및 함수나 훅의 실행을 의미한다.
• 렌더링은 컴포넌트의 시각적 출력을 생성하는 프로세스를 의미한다. 이는 Virtual DOM에 의해 비교되며 state에 변화가 있었을 때 리렌더링이 된다.

그러면 running은 언제 발생하는데?
여기서 막혔다.. 왜 2번째 클릭때는 state가 안변했으면서 콘솔이 찍히면서, 3번째 이상 클릭시 콘솔이 안찍힐까.. 더 찾아보고 알게되면 포스팅하겠다.

2. useState의 setter 분석..

소스 코드 분석을 아직 ing 중이다.
새롭게 알게된 점은
리액트 패키지에는 리액트 컴포넌트를 정의하는 데 필요한 기능만 포함되어 있따는 점! 일반적으로 웹용 react-dom 또는 네이티브 환경용 react-native와 같은 React 렌더러와 함께 사용된다고 readme에 나와있다.

따라서 useState가 정의된 소스코드를 타고 타고 타고..

마지막 도착지가 ReactCurrentDispatcher.js 인데, 객체 하나를 반환하는 것으로 끝이 났다.

즉, 여기까지는 별 내용 없이dispatcher라는 것에서 받아온 Hooks를 실행한다. 그 과정에서 해당 호출이 유효한지 검증하는 정도와 type 추론을 위한 type 주입 정도 로직이 있다!

따라서 훅 내부 동작을 알기 위해서는 Reconciler를 뜯어봐야 함을 깨달은 하루였다!

참고로 이 블로그를 보면서 분석 중이다. but React 16버전 기준이라 18버전인 현재와는 살짝의 차이가 있다.(물론 useState 부분의 기능적으로 다른 점은 없지만, 추상화가 더 많이 진행되어있다. 그래서 더 분석하기 까다로움 ..ㅋ)

내일의 나는 무엇을 공부해야 할까요?

• 리액트 데이터 다루기 완강
  • 생각보다 진도가 안나가고있다. 이유는 공식문서를 완독하고 싶은 나의 욕심 때문..?! 내일은 꼭 한번 훑고 추가적으로 문서를 읽는 것으로 방법을 바꾸고자한다.
• level3 알고리즘 1문제