<div id="readability-page-1" class="page"><div><figure data-filename="1.jpg" data-origin-width="1684" data-origin-height="2384" width="410" height="NaN" data-ke-mobilestyle="widthContent"><span data-url="https://blog.kakaocdn.net/dn/Z5mx8/btqHGVjXCCC/5UdeNKV2HdFJutNmtugnFk/img.jpg" data-lightbox="lightbox" data-alt=""><img src="https://blog.kakaocdn.net/dn/Z5mx8/btqHGVjXCCC/5UdeNKV2HdFJutNmtugnFk/img.jpg" data-filename="1.jpg" data-origin-width="1684" data-origin-height="2384" width="410" height="NaN" data-ke-mobilestyle="widthContent"></span></figure>

<ul>
<li>원래 오프라인으로 100명정도 뽑아서 한다고 하는데, 이번에는 코로나의 영향으로 온라인으로 진행되었습니다.</li>
<li>거기다가 이번에는 코로나 때문에 띄어 앉아야해서 약 30명 정도 뽑을 생각이시라고 하셨지만, 코로나가 심해져 온라인으로 진행되서 약 400여명의 교육생으로 뽑았다고 하셨습니다.</li>
<li>근데 이 교육을 듣고싶어서 지원한 사람만 1200여명.. 😤 열정적인 사람이 굉장히 많은 거 같다..</li>
<li>이번 교육은 zoom을 이용해서 온라인으로 진행되었고, 강사님은 우아한형제들의 김민태님(웹프론트엔드개발 그룹장)이 진행하셨습니다.</li>
<li>또한, 9월 한달동안 화, 목으로 진행되고 총 8회차로 진행될 예정이고 저도 계속 끝날때마다 블로깅을 할 예정입니다. ✌</li>
</ul>
<h2>🚀 우아한 테크러닝 3기 그 첫 시간 소개</h2>
<ul>
<li>첫 시간이라 그런지 교육적인 부분보다 굉장히 좋은 말씀을 많이 해주셨다.</li>
</ul>
<h3>🎈 우리들의 고민..</h3>
<h4>😥 내가 지금 하고 있는게 맞는 것인가? (내가 지금 잘하고 있나..?)</h4>
<ul>
<li>이 강의를 신청할 때 왜 이 테크러닝을 듣고싶은가에 대한 질문이 있었는데 거기의 대부분의 고민<ul>
<li>개발을 할때 동작은 되고 해결은 되는데 이게 잘하고 있는건지에 대한 의구심이 가장 크다. 때문에 이 테크러닝을 통해서 <strong>네트워킹을 하고싶고 시니어들한테 받는 피드백과 조언들을 원한다.</strong> (코드 품질에 대한 문제, 코드리뷰)</li>
<li><strong>아키텍처나 설계</strong>에 대한 고민.</li>
<li><strong>적정 기술</strong>에 대한 고민으로 react 상태관리를 해야할 때, <code>Mobx</code>를 써야하나, <code>Redux</code>를 사용해야하나에 대한 고민</li>
<li>살재로 면접볼때 개발자들에게 <em>이 기술을 왜 선택했어요?</em> 물어봤을 때, 제대로 고민해서 기술을 선택한 사람들은 굉장히 드물었다.</li>
</ul>
</li>
</ul>
<h4>그래서 그런 것들은 포괄해서 전달하고 싶은 것들은 ❓</h4>
<ul>
<li>도구의 발전<ul>
<li>20~30년 전에는 바닥(예를 들어 Node를 만든다.)부터 만들어 Hello World를 띄우기 이런것들의 고민이였다면, 지금은 도구의 발달로 생산성 향상에 도움을 주는 것들이 많이 생겨났다.</li>
<li>이러한 이유로 고민의 관점이 달라졌다. (예를 들어, 어떤 라이브러리를 쓰지? 어떤 방식으로 만들어지는 알고리즘이 좋을까?, 성능은 어떨까 등..)</li>
<li>그렇기 때문에 요즘 프로그래밍 학습 방법이 도구의 사용방법을 익히는 것이다.</li>
</ul>
</li>
</ul>
<h3>🎈 4주간 진행하면서 자주 들을 키워드</h3>
<figure width="100%" data-origin-width="632" data-origin-height="450" data-ke-mobilestyle="widthContent"><span data-url="https://blog.kakaocdn.net/dn/bJiNXS/btqHK33fnUu/L5oT9j67020h1mr3XV75R1/img.png" data-lightbox="lightbox" data-alt=""><img src="https://blog.kakaocdn.net/dn/bJiNXS/btqHK33fnUu/L5oT9j67020h1mr3XV75R1/img.png" width="100%" data-origin-width="632" data-origin-height="450" data-ke-mobilestyle="widthContent"></span></figure>
<ul>
<li>상태의 관리와 어떻게 다룰 것인가?</li>
<li>환경: 런타임 환경뿐아니라 개발환경에 대한 큰 범주</li>
<li>제품: 실제 서비스에 나갈 제품에 대한 것</li>
<li>미션: 그래서 무엇보다 어떤 도구를 사용하더라도 그 도구가 원천적으로 해결하고자 했던 <strong>미션</strong>을 잘 이해나는 것이 그 도구를 가장 잘 사용하는 방법이다.</li>
<li>상대적: 이런것들이 모두 상대적인것들.. 이해하고 적용하는 것에 따라서 한마디로 정의하기는 에매</li>
</ul>
<h3>🎈 이 강의 목표</h3>
<ul>
<li>각각에 대한 기본기를 알려주고 디테일한 부분은 포인트를 집어주고 나머지는 그 부분에 대해서 계속 학습을 이어가면서 쌓아가고, 이 강의가 시작해서 끝났다고 끝이 아니고 네트워킹을 이어갈 수 있게 만들 수 있게 하고 싶다.</li>
</ul>
<h3>🎈 강의를 하면서 주로 다룰 도구</h3>
<ul>
<li><a href="https://www.typescriptlang.org/play">TypeScript Playground</a> : 4.0이후 굉장히 좋아짐</li>
<li>예제는 <a href="https://codesandbox.io/index2">코드 샌드박스</a>에서 만든다.</li>
<li><a href="https://reactjs.org/">react 공식 문서</a></li>
<li><a href="https://redux.js.org/">redux 공식 문서</a></li>
<li><a href="https://mobx.js.org/README.html">Mobx</a></li>
<li><a href="https://redux-saga.js.org/">Redux-Saga 공식 문서</a></li>
<li>UI 프레임워크로는 <a href="https://blueprintjs.com/">blueprintjs</a></li>
<li>테스팅관점에서 사용 <a href="https://testing-library.com/">Testing-library</a></li>
</ul>
<h2>🚀 TypeScript</h2>
<ul>
<li>Type을 명시하는 것.</li>
<li>타입 추론을 할 수 있는 <strong>타입을 명시하지 않아도</strong> TypeScript가 <strong>알아서 추론</strong>해서 타입을 세팅해준다.</li>
<li><code>let foo = 10;</code></li>
<li>실제로 문제 일어날 때 다른 타입의 값을 넣을 때 오류가 발생</li>
</ul>
<pre><code>// 타입을 명시적으로 적는 방법으로 변수뒤에다 콜론을 하고 뒤에다 적는다. 
let foo : number = 10; foo = false;</code></pre><h3>🎈 명시적인 것과 암묵적인 것</h3>
<ul>
<li>추론은 안쪽에서 일어나기 때문에 암묵적이니까 명시적인 것보다는 읽는 사람한테 전달해주는 정보량이 적다.</li>
<li>몇 십년 전에는 코드가 복잡해도 잘 짜여저 보였지만, 요즘은 난해한 코드보단 명시적이고 읽기 쉬운 코드(코드가 길더라도)를 선호한다.</li>
<li>타입 스펙을 만드는 개발자들도 비슷한 생각을 하고 있고, 또 이것이 요즘의 트랜드.</li>
<li>JavaScript 또한 예전 스펙에서 요즘 나오는 새로운 문법들이 명시적으로 표현을 확장 시키는 것이 보인다.</li>
<li>대표적으로 가변인자 같은 것.</li>
</ul>
<pre><code>// 밖에서 봤을 땐 좋지 않구나. 
// 함수 내부에 인자가 아무것도 없기 때문에 가변인자를 받는지 모른다. 암묵적.. 
function bar() { 
    arguments. 
    return 0; 
}
bar(10,20);</code></pre>
<ul>
<li>그래서 spread operator(스프레드 문법)이 나온것도 이런 이유.</li>
</ul>
<pre><code>function bar(...args) { 
  return 0; 
}
bar(10,20);</code></pre>
<h3>🎈 type alias</h3>
<ul>
<li>원시타입은 일반화되어있기 때문에 다양하게 사용가능하다.</li>
<li>하지만 타입에 의미를 부여하고 싶을 땐 단점이 된다.</li>
<li>그래서 표현력을 넣고 싶을때 <code>type alias</code>가 스펙을 제공한다.</li>
</ul>
<pre><code>// 대입처럼 보이지만 type alias 오른쪽에있는 타입의 별명을 붙여준다. 
type Age = number; 
let age: Age = 10;</code></pre>
<ul>
<li>객체 타입</li>
</ul>
<pre><code>// 객체 type alias 
type Foo = { 
  age: Age; // 세미콜론 
  name: string; 
}

const foo: Foo = {  
  age: 10, // 콤마  
  name: 'kim'  
}</code></pre>
<ul>
<li>결국 최종적인 타입은 Primitive type.</li>
</ul>
<h3>🎈 interface</h3>
<ul>
<li>type alias와 비슷하지만 둘 중에 어떤 상황에서 어떤 것을 사용하는 것이 좋을까? 에 대한 얘기는 추후에 알려준다고 하신다.</li>
</ul>
<pre><code>type Age = number; 

interface Bar { 
  age: Age; 
  name: string; 
} 

const bar: Bar = { 
  age: 10, 
  name: "Kim", 
};</code></pre>
<h3>🎈 에러 검출</h3>
<h4>🔸 타입스크립트 문법 요소에는 크게 두가지가 존재</h4>
<ul>
<li>컴파일 타임에서 작동되는 요소 (type Alias, generic, interface)</li>
<li>런타임까지 가는 경우 에러를 잡는 요소 (JavaScript로 반환되는 요소)<ul>
<li>JavaScript로 개발을 할 때는 에디터 상태에서 나는 오류로 나오는 것은 사실상 런타임에 나오는 에러와 거의 일치하다.</li>
<li>때문에 타입스크립트가 제공하는 benefit은 거의 다 컴파일타임에 제공하는 장점이다.</li>
</ul>
</li>
</ul>
<h2>🚀 TypeScript를 사용한 CRA(Create React App)</h2>
<ul>
<li>CRA는 react app을 가장 빠르게 만드는 방법이다.</li>
</ul>
<pre><code>&gt; yarn create-react-app woowahan --template typescript</code></pre><ul>
<li>이렇게 하면 <code>tsconfig.json</code> 파일과 tsx로 이루어진 cra가 생성된다.</li>
<li><code>tsconfig.json</code> 파일은 typescript 컴파일러 옵션을 설정할 수 있다.</li>
</ul>
<pre><code>import React from 'react'; 
import ReactDOM from 'react-dom'; 

// 인터페이스 
interface AppProps { 
  title: string; 
  color: string; 
} 

// 타입 정의 
// 상태 : 시간의 흐름에 따라서 변화하는 것 
// 현재 상태는 불변 
function App(props: AppProps){ 
  return ( 
    &lt;h1&gt;{props.title}&lt;/h1&gt; 
  ) 
}

// 버추얼 돔의 랜더를 이용 
// 두개의 인자 
// render 최상위에서만 실행 
// 단일 버추얼 돔 
ReactDOM.render( 
  // 첫번째 인자 리액트 컴포넌트를 DOM으로 변경한 다음에 두번째 인자 HTML 컨테이너에 붙쳐넣는다. 
  // StrictMode =&gt; 경고해주는 안내해주는 개발툴에서 제공하는 툴 
  &lt;React.StrictMode&gt; 
      &lt;App title="Tech Hello?" color="blue"/&gt; 
  &lt;/React.StrictMode&gt;, 
  // 돔으로 변경후 root 컴포넌트에 붙친다. 
  document.getElementById('root') 
);</code></pre>
<h3>🎈 Babel에서의 JSX transpiler</h3>
<ul>
<li>Babel 안에 있는 JSX transpiler가 오른쪽처럼 변환해준다.</li>
<li>그렇기 때문에 안썻다고 생각해도 리액트 컴포넌트는 항상 리액트 패키지 import를 시켜야한다.</li>
<li>그 이유는 리액트 패키지는 변환된 다음에 쓰기 때문에 변환하기 전에 반드시 포함해준다.</li>
<li>JSX는 결국 CreateElement라고 하는 리액트가 제공한 함수를 좀 더 편하게 만들어놓은 (마치 HTML 태깅하듯이) 구조일 뿐이다.</li>
</ul>
<figure width="100%" data-origin-width="1513" data-origin-height="310" data-ke-mobilestyle="widthContent"><span data-url="https://blog.kakaocdn.net/dn/cmZl8x/btqHJqqxcK9/Q7QWUFBA41lU1tRitsvz7K/img.png" data-lightbox="lightbox" data-alt=""><img src="https://blog.kakaocdn.net/dn/cmZl8x/btqHJqqxcK9/Q7QWUFBA41lU1tRitsvz7K/img.png" width="100%" data-origin-width="1513" data-origin-height="310" data-ke-mobilestyle="widthContent"></span></figure>
<pre><code>// 첫 번째 인자는 HTML 태그처럼 생긴 태크명, 두번째인자는 Property, 세번째 인자는 Child
function App() {
  return /*#__PURE__*/_react.default.createElement("h1", {
    id: "header"
  }, "hello ");
}</code></pre>
<h3>🎈 CRA의 장점과 문제점</h3>
<ul>
<li>장점: 간단하고, 왠만한 것들은 다 세팅되어있다.</li>
<li>단점<ul>
<li>장점 그 외의 모든 것은 단점</li>
<li>CRA가 제공하지 않는 세팅을 할 때 굉장히 까다롭다.</li>
<li>CRA의 유연하지 못한 몇가지들을 이렇게 바꿨으면 좋겠다라고 말을해도 CRA 기여자분들은 보수적이라서 잘 받아주지 않는다.</li>
<li>가장 크리티컬한 문제는 다양한 환경에 대한 대응이 어렵다.(local, product 두가지만 지원)</li>
<li><code>eject</code>를 사용해 설정 파일을 빼서 커스터마이징이 가능하지만, 매우 복잡하고 하지말라고 권고를 하고 있다.</li>
</ul>
</li>
</ul>
<h2>🚀 상태관리</h2>
<h3>🎈 Flux</h3>
<ul>
<li>제일 먼저 나온 approach가 flux 아키텍처🎈</li>
</ul>
<h3>🎈 Redux</h3>
<ul>
<li>redux는 flux를 조금 더 정형화하고 더 쓰기 편하고 simple하게 제공되는 라이브러리</li>
</ul>
<h3>🎈 Mobx</h3>
<ul>
<li>Mobx는 redux의 대채품보다는 완전히 상태를 관리하는 페러다임을 바꿔버린 다른 방식이다.</li>
<li>상태도 다르고 상태를 바라보는 관점도다르다.</li>
<li>처음에 쓰면 굉장히 편하지만, 단순한 것은 단순한 형태를 취하는 이유가 있다.</li>
<li>단순한 형태를 가지면 그걸 만든 사람이 원하는 형태도 결과물을 가이드하기 쉽기 때문이다.</li>
</ul>
<h2>🚀 첫번째 시간 수강 후기</h2>
<ul>
<li>일단 강의하시는 김민태님께서 굉장히 친절하게 알려주셨고 그에 따라 배울점이 많다고 느꼈습니다.</li>
<li>중간에 쉬는 시간이 두번정도 있었지만 그 시간 마저도 질문에 답변을 해주는 QnA 시간을 가졌습니다.</li>
<li>react를 공부를 하면서 뭔가 잘 못 공부하고 있다는 생각이 들었고 그에 따라서 자극을 많이 받았던 기회였습니다.</li>
<li>교육생들 또한 정말 열정적이고 배우고자하는 의지?가 많아서 벌써 슬랙방도 파졌고 이번 기회에 네트워킹이 잘되서 스터디를 할 수 있는 기회가 생겼으면 좋겠습니다.</li>
<li>앞으로 남은 교육기간도 기대가 되고 집중해서 들을려고 노력해야겠습니다.. 😤</li>
</ul>
<h2>🚀 주니어들한테 해주고 싶은 말(김민태 님께서..)</h2>
<ul>
<li>주니어들이 시니어와 비교했을 때 압도적으로 유리한 부분은 <strong>시간</strong></li>
<li>이 시간이 있다는 benefit을 충분히 활용해서 초조하게 여러가지 공부를 하는 거 보다는 시간이 충분히 있으니 여유를 가지고 했으면 좋겠다.</li>
<li>이 시간으로 여러 정보를 습득할 수 있는데 이걸 방해하는 것이 초조한 생각이다.</li>
<li>이런 생각이 시간이 지날수록 자기 자신을 많이 힘들고 지치게 한다.</li>
<li>때문에 <strong>마라톤을 시작했다 생각하고 여유를 가져라!</strong></li>
</ul>

</div></div>

SaDevelog

Harang

우아한 테크러닝 3기 교육생
원래 오프라인으로 100명정도 뽑아서 한다고 하는데, 이번에는 코로나의 영향으로 온라인으로 진행되었습니다.
거기다가 이번에는 코로나 때문에 띄어 앉아야해서 약 30명 정도 뽑을 생각이시라고 하셨지만, 코로나가 심해져 온라인으로 진행되서 약 400여명의 교육생으로 뽑았다고 하셨습니다.
근데 이 교육을 듣고싶어서 지원한 사람만 1200여명..   열정적인 사람이 굉장히 많은 거 같다..
이번 교육은 zoom을 이용해서 온라인으로 진행되었고, 강사님은 우아한형제들의 김민태님(웹프론트엔드개발 그룹장)이 진행하셨습니다.
또한, 9월 한달동안 화, 목으로 진행되고 총 8회차로 진행될 예정이고 저도 계속 끝날때마다 블로깅을 할 예정입니다. ✌
  우아한 테크러닝 3기 그 첫 시간 소개
첫 시간이라 그런지 교육적인 부분보다 굉장히 좋은 말씀을 많이 해주셨다.
  우리들의 고민..
  내가 지금 하고 있는게 맞는 것인가? (내가 지금 잘하고 있나..?)
이 강의를 신청할 때 왜 이 테크러닝을 듣고싶은가에 대한 질문이 있었는데 거기의 대부분의 고민
개발을 할때 동작은 되고 해결은 되는데 이게 잘하고 있는건지에 대한 의구심이 가장 크다. 때문에 이 테크러닝을 통해서 네트워킹을 하고싶고 시니어들한테 받는 피드백과 조언들을 원한다. (코드 품질에 대한 문제, 코드리뷰)
아키텍처나 설계에 대한 고민.
적정 기술에 대한 고민으로 react 상태관리를 해야할 때, Mobx를 써야하나, Redux를 사용해야하나에 대한 고민
살재로 면접볼때 개발자들에게 이 기술을 왜 선택했어요? 물어봤을 때, 제대로 고민해서 기술을 선택한 사람들은 굉장히 드물었다.
그래서 그런 것들은 포괄해서 전달하고 싶은 것들은 ❓
도구의 발전
20~30년 전에는 바닥(예를 들어 Node를 만든다.)부터 만들어 Hello World를 띄우기 이런것들의 고민이였다면, 지금은 도구의 발달로 생산성 향상에 도움을 주는 것들이 많이 생겨났다.
이러한 이유로 고민의 관점이 달라졌다. (예를 들어, 어떤 라이브러리를 쓰지? 어떤 방식으로 만들어지는 알고리즘이 좋을까?, 성능은 어떨까 등..)
그렇기 때문에 요즘 프로그래밍 학습 방법이 도구의 사용방법을 익히는 것이다.
  4주간 진행하면서 자주 들을 키워드
상태의 관리와 어떻게 다룰 것인가?
환경: 런타임 환경뿐아니라 개발환경에 대한 큰 범주
제품: 실제 서비스에 나갈 제품에 대한 것
미션: 그래서 무엇보다 어떤 도구를 사용하더라도 그 도구가 원천적으로 해결하고자 했던 미션을 잘 이해나는 것이 그 도구를 가장 잘 사용하는 방법이다.
상대적: 이런것들이 모두 상대적인것들.. 이해하고 적용하는 것에 따라서 한마디로 정의하기는 에매
  이 강의 목표
각각에 대한 기본기를 알려주고 디테일한 부분은 포인트를 집어주고 나머지는 그 부분에 대해서 계속 학습을 이어가면서 쌓아가고, 이 강의가 시작해서 끝났다고 끝이 아니고 네트워킹을 이어갈 수 있게 만들 수 있게 하고 싶다.
  강의를 하면서 주로 다룰 도구
TypeScript Playground : 4.0이후 굉장히 좋아짐
예제는 코드 샌드박스에서 만든다.
react 공식 문서
redux 공식 문서
Mobx
Redux-Saga 공식 문서
UI 프레임워크로는 blueprintjs
테스팅관점에서 사용 Testing-library
  TypeScript
Type을 명시하는 것.
타입 추론을 할 수 있는 타입을 명시하지 않아도 TypeScript가 알아서 추론해서 타입을 세팅해준다.
let foo = 10;
실제로 문제 일어날 때 다른 타입의 값을 넣을 때 오류가 발생
// 타입을 명시적으로 적는 방법으로 변수뒤에다 콜론을 하고 뒤에다 적는다. 
let foo : number = 10; foo = false;
  명시적인 것과 암묵적인 것
추론은 안쪽에서 일어나기 때문에 암묵적이니까 명시적인 것보다는 읽는 사람한테 전달해주는 정보량이 적다.
몇 십년 전에는 코드가 복잡해도 잘 짜여저 보였지만, 요즘은 난해한 코드보단 명시적이고 읽기 쉬운 코드(코드가 길더라도)를 선호한다.
타입 스펙을 만드는 개발자들도 비슷한 생각을 하고 있고, 또 이것이 요즘의 트랜드.
JavaScript 또한 예전 스펙에서 요즘 나오는 새로운 문법들이 명시적으로 표현을 확장 시키는 것이 보인다.
대표적으로 가변인자 같은 것.
// 밖에서 봤을 땐 좋지 않구나. 
// 함수 내부에 인자가 아무것도 없기 때문에 가변인자를 받는지 모른다. 암묵적.. 
function bar() { 
    arguments. 
    return 0; 
}
bar(10,20);
그래서 spread operator(스프레드 문법)이 나온것도 이런 이유.
function bar(...args) { 
  return 0; 
}
bar(10,20);
  type alias
원시타입은 일반화되어있기 때문에 다양하게 사용가능하다.
하지만 타입에 의미를 부여하고 싶을 땐 단점이 된다.
그래서 표현력을 넣고 싶을때 type alias가 스펙을 제공한다.
// 대입처럼 보이지만 type alias 오른쪽에있는 타입의 별명을 붙여준다. 
type Age = number; 
let age: Age = 10;
객체 타입
// 객체 type alias 
type Foo = { 
  age: Age; // 세미콜론 
  name: string; 
}
const foo: Foo = {  
  age: 10, // 콤마  
  name: 'kim'  
}
결국 최종적인 타입은 Primitive type.
  interface
type alias와 비슷하지만 둘 중에 어떤 상황에서 어떤 것을 사용하는 것이 좋을까? 에 대한 얘기는 추후에 알려준다고 하신다.
type Age = number; 
interface Bar { 
  age: Age; 
  name: string; 
} 
const bar: Bar = { 
  age: 10, 
  name: "Kim", 
};
  에러 검출
  타입스크립트 문법 요소에는 크게 두가지가 존재
컴파일 타임에서 작동되는 요소 (type Alias, generic, interface)
런타임까지 가는 경우 에러를 잡는 요소 (JavaScript로 반환되는 요소)
JavaScript로 개발을 할 때는 에디터 상태에서 나는 오류로 나오는 것은 사실상 런타임에 나오는 에러와 거의 일치하다.
때문에 타입스크립트가 제공하는 benefit은 거의 다 컴파일타임에 제공하는 장점이다.
  TypeScript를 사용한 CRA(Create React App)
CRA는 react app을 가장 빠르게 만드는 방법이다.
> yarn create-react-app woowahan --template typescript
이렇게 하면 tsconfig.json 파일과 tsx로 이루어진 cra가 생성된다.
tsconfig.json 파일은 typescript 컴파일러 옵션을 설정할 수 있다.
import React from 'react'; 
import ReactDOM from 'react-dom'; 
// 인터페이스 
interface AppProps { 
  title: string; 
  color: string; 
} 
// 타입 정의 
// 상태 : 시간의 흐름에 따라서 변화하는 것 
// 현재 상태는 불변 
function App(props: AppProps){ 
  return ( 
    <h1>{props.title}</h1> 
  ) 
}
// 버추얼 돔의 랜더를 이용 
// 두개의 인자 
// render 최상위에서만 실행 
// 단일 버추얼 돔 
ReactDOM.render( 
  // 첫번째 인자 리액트 컴포넌트를 DOM으로 변경한 다음에 두번째 인자 HTML 컨테이너에 붙쳐넣는다. 
  // StrictMode => 경고해주는 안내해주는 개발툴에서 제공하는 툴 
  <React.StrictMode> 
      <App title="Tech Hello?" color="blue"/> 
  </React.StrictMode>, 
  // 돔으로 변경후 root 컴포넌트에 붙친다. 
  document.getElementById('root') 
);
  Babel에서의 JSX transpiler
Babel 안에 있는 JSX transpiler가 오른쪽처럼 변환해준다.
그렇기 때문에 안썻다고 생각해도 리액트 컴포넌트는 항상 리액트 패키지 import를 시켜야한다.
그 이유는 리액트 패키지는 변환된 다음에 쓰기 때문에 변환하기 전에 반드시 포함해준다.
JSX는 결국 CreateElement라고 하는 리액트가 제공한 함수를 좀 더 편하게 만들어놓은 (마치 HTML 태깅하듯이) 구조일 뿐이다.
// 첫 번째 인자는 HTML 태그처럼 생긴 태크명, 두번째인자는 Property, 세번째 인자는 Child
function App() {
  return /*#__PURE__*/_react.default.createElement("h1", {
    id: "header"
  }, "hello ");
}
  CRA의 장점과 문제점
장점: 간단하고, 왠만한 것들은 다 세팅되어있다.
단점
장점 그 외의 모든 것은 단점
CRA가 제공하지 않는 세팅을 할 때 굉장히 까다롭다.
CRA의 유연하지 못한 몇가지들을 이렇게 바꿨으면 좋겠다라고 말을해도 CRA 기여자분들은 보수적이라서 잘 받아주지 않는다.
가장 크리티컬한 문제는 다양한 환경에 대한 대응이 어렵다.(local, product 두가지만 지원)
eject를 사용해 설정 파일을 빼서 커스터마이징이 가능하지만, 매우 복잡하고 하지말라고 권고를 하고 있다.
  상태관리
  Flux
제일 먼저 나온 approach가 flux 아키텍처 
  Redux
redux는 flux를 조금 더 정형화하고 더 쓰기 편하고 simple하게 제공되는 라이브러리
  Mobx
Mobx는 redux의 대채품보다는 완전히 상태를 관리하는 페러다임을 바꿔버린 다른 방식이다.
상태도 다르고 상태를 바라보는 관점도다르다.
처음에 쓰면 굉장히 편하지만, 단순한 것은 단순한 형태를 취하는 이유가 있다.
단순한 형태를 가지면 그걸 만든 사람이 원하는 형태도 결과물을 가이드하기 쉽기 때문이다.
  첫번째 시간 수강 후기
일단 강의하시는 김민태님께서 굉장히 친절하게 알려주셨고 그에 따라 배울점이 많다고 느꼈습니다.
중간에 쉬는 시간이 두번정도 있었지만 그 시간 마저도 질문에 답변을 해주는 QnA 시간을 가졌습니다.
react를 공부를 하면서 뭔가 잘 못 공부하고 있다는 생각이 들었고 그에 따라서 자극을 많이 받았던 기회였습니다.
교육생들 또한 정말 열정적이고 배우고자하는 의지?가 많아서 벌써 슬랙방도 파졌고 이번 기회에 네트워킹이 잘되서 스터디를 할 수 있는 기회가 생겼으면 좋겠습니다.
앞으로 남은 교육기간도 기대가 되고 집중해서 들을려고 노력해야겠습니다..  
  주니어들한테 해주고 싶은 말(김민태 님께서..)
주니어들이 시니어와 비교했을 때 압도적으로 유리한 부분은 시간
이 시간이 있다는 benefit을 충분히 활용해서 초조하게 여러가지 공부를 하는 거 보다는 시간이 충분히 있으니 여유를 가지고 했으면 좋겠다.
이 시간으로 여러 정보를 습득할 수 있는데 이걸 방해하는 것이 초조한 생각이다.
이런 생각이 시간이 지날수록 자기 자신을 많이 힘들고 지치게 한다.
때문에 마라톤을 시작했다 생각하고 여유를 가져라!

✔ 우아한 테크러닝 3기: React & TypeScript 1회차

댓글