Introduce

• 3번째 시간에는 pull request 에 대해 살펴보았다. (각각의 pr 에 대한 설명도 함께!)

첫번째 PR

Content 1

• 코드 샌드 박스를 이용해서 Draft.js 를 구현

Feedback

• 본인이 구현하는 것을 소개하는 시간에 비슷한 유형의 실수를 주니어가 많이 한다. 바로 본인의 맥락으로 설명하는 것이다. 본인이 다 구현을 하였기 때문에 핵심적인 부분만 설명한다. 하지만 공유를 받는 입장에서 (시니어, 동료)는 해당 내용을 쫓아올 수 없다. 따라서 기본적인 셋업이 있어야 하고, 어떤 걸 알아보고, 이걸 사용해서 구현을 했다. 등의 맥락에 대한 설명의 전제가 없다면 사람들은 전혀 못따라갈 것이다.
• 상대는 똑같은 것을 하지 않았기 때문이 이와 같이 커뮤니케이션 하면 굉장히 좋지 않다. 같이 듣고 있는 동료나 상사들이 크게 관심이 없고 마음에 들지 않다고 하면, 별다른 피드백을 주지 않을 수도 있다. 이때 가장 손해는 발표한 사람이다.
• 내가 노력한 만큼, 그것들을 다른 사람에게 전달하는 기술이 필요하다. 특별하기보다는 전제를 잘 깔고, 그것들을 하나씩 살펴본다고 하면 자연스럽게 따라가기 쉬울 것이고 청자들의 질문도 많아질 것이다.

Content 2

• Draft.js 는 일종의 함수를 가져와서 조합해서 사용한다기 보다는 객체들로 컨텐츠들이 구성되어 있고, 인스턴스 메서드나 스테틱을 사용해서 구성된 컨텐츠들을 바꿔나가는 프레임 워크이다.
• Editor  컴포넌트 하나만으로 에디팅 기능을 사용할 수 있었다.
• 블럭에 아무것도 없을 때 대시 입력하면 unordered list, 1.이 입력되면 ordered list
• 1.을 했을 때 1.을 삭제해줘야 하는데 이 부분을 고치지 못함
• 구글 로그인: GoogleAuth 연동 react-google-login 를 사용함

Feedback

• 구글 로그인 oauth 가 무엇인지 모른다. 그래서 다시 설명을 부탁드린다. ouath 란 무엇인지 실제 어떤 식으로 로그인이 되는 건지 설명해주면 좋을 것 같다.

💫

학습법

• 많은 분들이 실수하는 부분 중에 하나이다. 요즘 인터뷰를 많이 보기도 하고, 주니어 분들이 많이 하는 실수 중 하나이다. 지금 당장은 구현이 목적이 아니다. 어떤 식으로 구현하고 기술을 어떤 식으로 잘 학습 하는지 다양한 의견을 교환하는 게 목적이다. 지금은 실제로 뭔가 만드는 데만 포커스를 갖고 있는 느낌이 든다.
• 앞의 전제가 없다면 무엇을 하든 똑같다. 시니어가 혹은 면접관이 물어봤다, "그 기술을 왜 사용했어요?" → "그냥 썼어요" 라는 대답의 형태는 성장에 방해된다. 하는 김에 익히는 게 좋은데 그것을 놓쳐서 지나가 버리면 너무 아깝다. 시간을 효과적으로 사용하는 학습 방법을 선택해야 한다.

설명법

• "~~ 한 부분에 대해서 들었다." 실제로 구현한 부분인데도 불구하고.. "~~ 느낌이였다.", "~~ 신기했다." 등의 단어를 많이 사용한다. 이는 엔지니어가 사용할 만한 단어가 아니다. 하지만 신기하게도 많은 분들이 사용한다. "js 의 클로저에 대해 설명해주세요" → "~~~ 라고 들었습니다" 이렇게 답변한다면 실제로 안해봤다는 식의 느낌을 준다. 즉 안좋은 말하기 습관이다. 이런 부분들을 의식하고 고치려는 노력을 해야 한다.
• 경쟁력을 키우기 위해서는 그런 작은 습관을 걷어내자!

프로토타입

• 프로토 타입의 목적이 무엇일까? 맥락을 쫓아가다보면 어느 순간 정말 엉뚱한 일을 하고 있을 수도 있다.
• 구현방향성? → 이미 정해져 있다.
• 기술 비용이 얼마나 들지 산정하는 것 , 리스크를 확인해야 비용을 산출할 수 있다. (비용은 사람과 시간 등을 뜻한다.) ~ 부분 때문에 까다롭다면 구현 비용이 높은 것이다. 리스크를 확인하기 위한 게 프로토 타입의 목적인 것 같다. 프로토 타입을 하였을 때 리스크로 보이는 것을 찾아보는 것도 중요하다. 어떤 부분이 리스크 처럼 보이는가? "start-ordered-list", "start-unordered-list" 등 , keybindFn에서 갑자기 리턴을 하는데, 또 handleKeyCommand 입력으로 들어온대! 이 두개만으로도 핸드 쉐이크가 들어가느냐, 아니면 또 다른 함수에서도 핸드 쉐이크가 들어가느냐? 이게 상당한 리스크들로 보인다. 기능이 많아질 수록 각각의 커맨드들이 늘어날 것처럼 보인다. 이 코드에서는 룰이 매니징 가능하게 보이지 않았다. 에디터가 작동하는 데 있어서 로직이 늘어날 수록 복잡도가 늘어날 것 같다. 도대체 어디서 뭐가 꼬였는지 찾기 힘들 것 같다.
• 짧은 부분에서도 이런 구조가 눈에 띈다면... 구현방법 확인하기 전에 이 코드를 보자마자 커멘드들이 얼마나 복잡해질지, 더 많은지? 이를 확인하고 이 두개만 서로 주고받는 거라면 이 두개만 모양을 정제하면 된다. 그렇지 않으면 그것에 맞춰 대책을 세워야 한다. 코드 상으로만 보면 크리티컬 하게 보인다. 형식을 이넘이나 타입스크립트 타입? 으로 한다해도 .. 흐름 제어가 힘들어보이는 구조 같다. 그게 없다면 리스크가 커질 것 같다. 복잡도 함께 늘어날 것 같다.

Content 3

• handleKeyCommand
• startList

Feedback

• 이게 맞나요? 저게 맞나요? 계속 내용 확인을 해야 한다. 실제 기획자나 디자이너 비지니스, 프론트, 서버 개발자 등에서도 굉장히 자주 있는 일이다. 맥락 상 공감대가 이루어지지 않는 단어로 이야기 하면 문제가 생긴다.
  1. 서로 다른 이야기를 했다가 지금 보면 엉뚱한 걸 하고 있다.
  2. 전혀 못 알아들어서 이뜻인가요? 저 뜻인가요?
     → 명확한 워딩으로 커뮤니테이션을 하는 것이 굉장히 중요하다. 공감대를 이루는 작업 후에 컨센셔스를 이뤄야 한다.
• handleKeyCommand 둘중에 하나면 핸들링을 리턴한다. startList 에서, handleKeyCommand 함수 입장에서는 결국 startList 호출하는 조건에만 관심이 있을 뿐인데, 이곳의 세부 동작, 실제 하는 역할이 밖에 나올 일이 있을까 라는 생각이 들었다. "start-ordered-list" 라는 케이스를 넘겨주고 있다. 실제 복잡하지 않은데 복잡해 보이는 구성처럼 보인다. 자기가 할일이 아닌데 들고 있으면 문제가 된다. 이렇게 보니까 이것을 깔끔하게 할 수 있는 패턴이 보인다.
• command 가 n개가 있고, 한쪽에는 실행할 함수를 갖고 있다. key-value 셋을 하나 만들어 놓으면 코드셋 자체를 없앨 수 있다. 커멘드만 컨피그레이션으로 쭉 해놓으면 ... 좀 더 명확하게 볼 수 있는 코드 구조가 나올 수 있다. if 로직을 다 제거할 수 있다. 안쪽에 있는 로직이 빠져있어서 비지니스 로직을 주는 것 같은 착시를 주는 것이다. 이런 부분들을 조절하면 될 것 같다.

두번째 PR

Content 1

• Oauth 직접 페이스북 아이디와, 비밀번호를 알아야 하는데, 안전하지 않기 때문에 아이디 패스워드 정보 대신 access token을 갖고 필요한 정보를 요청하고 받을 수 있는 것으로 이해했다. 구글 로그인을 구현하다가 실패해서 react-google-login 을 사용했다. 서버로 tokenId, email, image 정보를 넘겼다. 서버에서는 이메일로 조회를 해서, 이메일이 없으면 새로 생성해서 이메일을 id 로 하는 것을 ....
• 네이버에서는 node.js 나 java 등의 백엔드에서 요청해야지 결과값을 준다. access 토큰을 서버로 넘겨서 받고, 사용자 이메일, 이름을 가져오는 작업을 했다.
• react-router-dom을 사용해서 로그인을 했을 때는 loginPage, 로그인을 했을 때는 Editor를 가게 했다.

Feedback, QA

• 엔지니어링에서는 반드시 이유가 있어야 한다!!!!!!!!!!!

• 김민태님:타입스크립트의 타입은 런타입이 아닌 컴파일 타입을 작성하는 것이다. 런타임의 다른 속성이 들어온다고 해도 이미 타입스크립트가 아니기 때문에 걱정할 필요가 없다. any를 사용하면 이유가 없어진다.

• Q. 두개 로그인의 차이점?

• Q. react-google-login 오피셜 패키지인가?
  https://www.npmjs.com/package/react-google-login

• Q. 정상적으로 로그인 된 건 어떻게 확인?

• Q. props 의 history ? 사용하고 있는 history 만 넣어놓으면 된다.

• Q. 소셜 로그인으로 얻은 token은 서버에서도 관리하시나요?
  → 김민태님: 일반적으로 소셜 로그인으로 얻은 token은 저장을 해야 한다. 저장하지 않으면 매번 저장해야 하기 때문이다. 토크에도 다 유효기간이 있다. token 과 관련해서 복잡한 구성을 갖고 있는 게 많다. oauth 제공하는 것마나다 다르다. refresh token, access token .. 등 여러개 많다. 토큰이 너무 오랫동안 살아나면 문제가 있음!

세번째 PR

Content 1

• google login 백엔드로 처리
• passport 사용, 돌때마다 serialize를 해줘서 세션에다가는 Id 만 넣어준다.

Feedback, QA

• 직접 구현하면 passport 보다 더 간단할 수 있다. 추상화 층이 복잡하기 때문에 그 추상화 층을 따라가야 한다. 몇개의 콜백 url 과 관리하는 것? 특별하게 복잡하진 않을 것이다.

• 백엔드에서 인증, 클라이언트 인증 → 보안적 이슈도 있지만, 클라이언트 인증은 단점은 react-router 를 계속 들고다녀야 한다는 것이다. 백엔드 단에서 미리 작동하기 전에 url을 체크하고 있기 때문이다. 즉 클라이언트 앱을 훨씬 더 깔끔하게 만들 수 있을 것이다. 추가적으로 현재 방식이 팝업 방식이 아니다 보니까 사용자 경험이 나을 것 같다. 팝업이 떴을 때 막히는 경우도 있기 때문에 여러가지 측면에서 백엔드 단에서 oauth를 붙이는 게 장점이 많은 것 같다.

• Q. 프론트에만 구글 로그인으로 구현하시는 분들은 시크릿키 어떻게 관리? 시크릿 키는 서비스 사용자들이나 다른 사람들에게 노출 되면 안되는데 어떻게 관리하고 있을까요?
  → 클라이언트에서는 secreat key 를 사용하지 않고, client_id와 scope 만 사용한다.

• 웬만한 서비스들은 네이버, 구글, 카카오 로그인 등을 많이 지원한다. 클라이언트 개발할 때는 oauth 개발은 필수적으로 거쳐가는 관문이다. (사용자 입장에서는 편하므로) oauth 관련해서는 필수적으로 지식을 갖고 있어야 한다!

nest.js를 사용한 PR 

Content 1

• oauth 만 nest 로 전달해서 진행
• https://velog.io/@whdud132/1.-NestJS-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0
• 파일 구조 - React
• Documentation | NestJS - A progressive Node.js framework
• NestJS 빠르게 배우기 01

Feedback, QA

• Q. 클래스를 쓰는 게 익숙해보이는데 ..?
  → 하나의 모듈? 지금은 모듈이 여러가지로 나뉘게 되니까 클래스로 나눠서 어떤 클래스 이하에 무엇을 할지, 추상화를 해놓으면 편할까 싶어 활용하게 되었다.
  → 김민태님: 단독으로 패키지로 사용해서 그것을 끌어다가 사용하는 게 좋지 않을까? 모노레포의 형태? 깃의 서브 모듈과 같은 형태!
  모노레포 : 다양한 모듈을 여러개의 레포지터리로 관리하지 않고, 하나의 레포지토리로 관리하는 것을 의미한다.
  출처: https://geonlee.tistory.com/147 [빠리의 택시 운전사]

• Q. index.ts, utils.ts ?????
  → 폴더를 만들어서 index.ts 를 하는 방식을 더 선호한다 그 이하에서 파일을 나누고 싶을 때/파일이었다가 폴더로 만들어야 하는 등의 번거로운 느낌이 들었다. 모듈 디렉토리 이하에서 추가해서 만들면 되므로 이런 구성을 선호한다.

• 김민태님: 순수 바닐라스크립트보다는 자연스럽게 코드들이 길어지는 경향이 늘어나긴 것 같다. 뭐가 좋을까? 너무 길어도 좋지만, 적정 수준의 디스크립션을 선호하는 게 좋지 않을까 싶다.

• Q. import 와 같은 것을 사용할 때 이름의 클래스를 사용할 일이 생기면 앞에 패키지 명이 길게 붙어야 해서 최대한 유니크한 이름을 지으려고 해요 ...
  → good...

• Q. 클래스 잘 쓰고 싶은데 그런 사고 방식 어떻게 기를 수 있을까?
  → 인터페이스를 매우 중요하게 생각한다. 외부에서 이 클래스를 어떻게 활용할지 고민한다.
  → 김민태님: 많이 해보는 게 답이다.

• Q. async, await  구문이 아닌 then 을 사용하는 이유가 있으신가요?
  → 상황에 따라서 다르다. 구조에 따라
  → promise  구문이 시각적으로 논리가 구분돼서 더 읽기 편하다.
  → then 구문으로도 충분히 가능할 것 같다.

• 김민태님: 프론트 엔드 개발자들이 클래스를 안쓰는 경향성이 짙다. 클래스를 아예 하나도 사용하지 않고도 개발이 가능한데, 그게 옳은지는 잘 모르겠다. 클래스를 이용해서 모델링, 추상화를 잘할 수 있다. UI 자체를 클래스로 레고 블록처럼 조립하는 시도를 할 수도 있다. 사실 리액트로 개발하면 인스턴스를 만들 일이 거의 없다. 인스턴스 객체를 본적이 없는데 클래스를 어떻게..? 하지만 소프트웨어 엔지니어라면 언제까지나 리액트만 사용할 수는 없다!

Slate를 사용한 PR 

• Slate 는 json 형식으로 관리하는 것 같다. 슬레이어트에 대해 찾아봤는데, 타입보다는 url 을 사용? children 배열 안에 있는 것만 관심이 있다.
• slate  구조를 봤을 때 원칙은....? plugins
• withImages  가 플러그인? 개별 요소들을 플러그인 주입해서 만든다.
• https://codesandbox.io/s/slate-plugins-playground-v1-forked-3qge9

Todo

• 두개의 레포!
• 베이스 시작은 mini notion 을 사용했음
• 두가지 케이스를 취향 껏 선택하면 갈 것 같다. 서버사이드 렌더링과 클래스

목표

• slate.js 기본 팝업 UI
  • selected 를 하면 스타일 가이드 UI가 뜨는데 .. 그런 식의 UI?
  • 정확히 어떤 것?....
• 리포 UI 연동
• 무료 DB 서베이 해서 붙여보기!
• 지금은 프로토타입을 했지만, 노션의 한 페이지, 타이틀, 내용 분리
  • 프로덕션 구조를 가질 수 있도록 고민해서 작업해보기.
• 기존 PR 베이스로 공유하거나 연습해보기. 질의응답할 것도 나오기 때문

기본적으로 같이 시작해도 된다, 공부가 끝나서 다음 것을 한다는 것은 학습의 속도만 늦추는 것이다. 동시에 하고 꾸준히 연마해야 한다. 기본적으로 공부만 한다고 해서 자바스크립트 학습은 완성시킬 수 없다. 그 다음 챕터로 넘어가는 건 말이 안된다. 자바스크립트가 어렵다고 생각해도 같이 동시에 하면서 뛰어들면 좋을 것 같다.