분류 전체보기

부스트캠프 멤버십 그룹프로젝트 3주차를 마쳤다. 세상에 벌써 3주차가 끝났단말이야? 배운것 이번 주는 코드적인 부분을 많이 학습할 수 있었다. Context API는 상태관리 도구가 아니다. 모든 시작은 Modal에 대한 고민으로부터 시작했다. 요런 고민들을 했었는데, 이런 고민들을 멘토님께 공유드리니, 멘토님께서 이것 뿐만 아니라 모달이 여러개라면 어떻게 할 것이냐는 질문을 던져주셨고, @ebay/nice-modal-react라이브러리를 알려주시며 해당 구조를 한번 살펴보라고 해주셨다. 그래서 무작정 코드를 뜯어보기 시작했는데, 여기서 Context API를 사용해서 모달을 관리하는 것을 확인할 수 있었다. 그런데 상태라기보다는 값 관리를 위해 Modal 고유의 ID를 주입한다던지... 이런식으로 사용..

부스트캠프의 그룹프로젝트 2주차를 마쳤다. 배운것 왜? 를 조금 더 날카롭게 사실 이전까지는 어떤 문제를 해결하는데 현재 상태로는 구현이 불가능하다 싶으면 찾아봤을때 가장 먼저 나오는 라이브러리를 아무 생각없이 다운로드 받아 사용하기 일수였다. 하지만 이번 프로젝트부터는 왜 이 라이브러리를 사용해야하는가? 를 조금 더 고민했다. 왜 이 라이브러리를 사용해야하는가? 를 고민해야하는 이유는 여러가지를 되짚어보며 명확히 할 수 있기 때문이다. 1. 우리가 하고자 하는 것은 무엇인가? 2. 현재 우리가 겪고 있는 문제는 무엇인가? 3. 우리가 겪는 문제의 본질은 무엇인가? 4. 그 문제의 본질을 이 라이브러리가 해결해 줄 수 있는가? 5. 이 라이브러리보다 더 여러 가지 기준에서 더 나은 라이브러리는 없는가? ..

부스트캠프의 그룹프로젝트 1주차를 마쳤다. 배운 것 프로젝트를 관리하는법 지금까지 나는 여러 프로젝트를 했지만, 뭔가 체계적으로 한다기보다는 오늘은 요걸 해보자! 라고 즉흥적으로 정해서 하기 일수였다. 그래서 프로젝트가 생각보다 일찍 끝나거나, 혹은 매우 늘어지기도 했다. 이번 주차에는 그렇지 않기위해서 스크럼 방식을 통해 프로젝트를 관리하는 방법을 학습할 수 있었다. 정말 좋은 방법이고, 앞으로 반드시 이런 방식으로 프로젝트를 관리해야겠다는 다짐을 했다. 스크럼 스크럼은 복잡한 제품을 개발하고, 배포하고, 유지하기위한 프레임워크다. 이걸 여기서 아무리 설명해봤자 감이 오지 않을 것이다. 백로그 백로그란 완료되지 않은 작업 항목들의 리스트나 목록이다. 일종의 팀의 todo list 같은 것이다. 백로그는..

WebRTC를 사용하게 된 이유 화상 공유, 음성 공유가 필요했기때문이다. WebRTC를 사용하면 웹어플리케이션 및 사이트가 별도의 소프트웨어 없이 웹 브라우저에서 음성, 영상, 미디어 , 텍스트, 파일까지 주고받을수 있다. WebRTC란 WebRTC는 Web Real-Time Communications의 약자로 웹상에서 실시간 통신이 가능하게 해주는 기술이다! 기본적으로 WebRTC는 P2P통신에 최적화 되어있다. 1:1 통신상황을 그림으로 표현하면 이런 상태인 것이다. 그런데 이렇게 연결하기란 쉬운일이 아니다. 기본 동작 P2P연결은 초대장을 생각하면 이해하기 쉽다. 서로가 서로에게 초대장을 보내고, 연결을 수락하면 P2P연결을 시작한다. 그런데 어떻게 서로에게 초대장을 보낼 수 있을까? Client..

네이버 부스트캠프의 멤버십 스프린트 과정을 마쳤다. 멤버십 스프린트 과정을 돌아보니 결국 1주차, 개발자 특강에서 배운 것들(문제에 접근하는법, 성장을 위한 발판)을 나만의 방법으로 구체화하는 과정이었던 것 같다. 다시 1주차에서 배운 것을 돌아보자. 아래 과정은 내가 1주차에 특강을 듣고 회고에 정리한 내용을 가져온 것이다. 문제에 접근하는 것 1. 문제는 무엇인가? 문제가 일어나는 현상을 명확하게 정의한다. 이것이 가장 처음에 이뤄져야할 단계이다. 2. 정말 문제인가? 기대한 현상과 실제 현상을 비교해보고, 어떤부분이 기대한 것과 다른지 파악한다. 3. 가설을 세운다. 이론적 접근을 통해 가설을 세우고, 실제 실천하여 확인해보는 과정을 거친다. 4. 무한 반복 계속해서 추론, 실천 과정을 반복한다. ..

본 게시글의 코드는 리액트 16버전을 기준으로 하고있습니다. 이전 게시글에서 reconciler 패키지의 rednerWithHooks함수를 찾았고, 거기서 훅을 주입한다는 것을 알게되었다. 그럼 실제 코드를 확인하며 어떻게 훅을 주입하고 있는지 확인해보자. renderWithHooks 우선 함수의 인자들을 확인해보자. current와 workInProgress, Component, props, refOrContext, nextRenderExpirationTime을 받아서 사용한다. 자... 하나씩보자. 일단 current와 workInProgress는 넘어가자. Component는 실행시켜야할 함수를 말한다. (ReactElement의 tag 프로퍼티) props는 ReactElement의 props를 ..

본 게시글의 코드는 리액트 16버전을 기준으로 하고있습니다. 이 글을 쓰게된 계기 이전 게시글까지 리액트처럼 동작하는 코드를 작성해보았다. 그런데 이전 게시글에서 만든 useState는 한가지 치명적인 문제가 있다. useState를 쓰는 컴포넌트가 조건부 렌더링이 되는 경우, states배열이 망가진다는 것이다. const Component1=()=>{ const [inner,setInner]=useState("컴포넌트1입니다!"); return {inner}; } const Component2=()=>{ const [inner,setInner]=useState("컴포넌트2입니다!"); return {inner}; } const App=()=>{ const [state,setState]=useState..

이 글을 읽기에 앞서 이 게시글은 리액트처럼 동작 하는 코드를 작성해보는 것이지 리액트와 100% 동일한 코드를 작성하려 하는 것이 아닙니다. 기존의 리렌더 기존의 리렌더링(사실 리렌더가 아니고 다른걸 렌더하는 거지만)은 명시적으로 다른 element를 넘겨서 업데이트 하는 형태였다. import App from './components/App'; import React from './core/React'; import { Change } from './components/Change'; const app = document.getElementById('root'); const prev = App(); React.render(prev, app); setTimeout(() => React.updateDOM..

이 글을 읽기에 앞서 이 게시글은 리액트처럼 동작 하는 코드를 작성해보는 것이지 리액트와 100% 동일한 코드를 작성하려 하는 것이 아닙니다. 이전게시글에서 render와 rerender를 구현했다....만 너무 성능이 안좋을 것 같으니 개선을 해보고자 한다. 참고로 아래의 diffing알고리즘은 이 블로그 글의 코드를 기반으로 작성, 개선되었다. 기존의 DOM요소 변경은 특정 DOM요소를 DOM API를 통해 가져와서 그 부분만 업데이트하는 형태이다. 이런 형태를 지금의 render방식에 적용할수는 없을까? 할수있다! 바로 기존의 element객체를 활용하는 것이다. 우리는 element객체를 DOM요소로 변경했다. 따라서 element객체의 중첩구조와 DOM요소의 중첩구조는 완벽하게 동일하다. 따라서..

이 글을 읽기에 앞서 이 게시글은 리액트처럼 동작 하는 코드를 작성해보는 것이지 리액트와 100% 동일한 코드를 작성하려 하는 것이 아닙니다. 이전게시글을 통해 JSX요소를 객체형태로 변환하는 것 까지 진행했다. 이제 JSX 컴포넌트는 tagName, props객체, children배열을 가진 객체로 관리된다. 그럼 이제 이걸 DOM api를 사용해서 객체를 DOM요소로 변환시키자. makeDOM /** * @param {object} element createElement로 만들어진 요소 * @param {string} element.tagName 요소의 태그 이름 * @param {object} element.props 요소의 속성 객체 * @param {Array|undefined} element...