BO의 개발로그

어제 작성한 TIL은 React Virtual DOM의 재조정(Reconsiliation)에 대한 내용으로 React가 보다 더 효과적으로 DOM을 갱신하기 위해서 채택하고 있는 내부 방식에 대해 정리하였다. 11/14 TIL | 리액트 Virtual DOM의 재조정(Reconsiliation) React는 선언적 API를 제공하기 때문에 갱신이 될 때마다 매번 무엇이 바뀌었는지를 걱정할 필요가 없다. 이게 뭔 소릴까? 이를 이해하기 위해선 Virtual DOM이 무엇인지 먼저 알아야 한다. 💡 Virtual D bohyunkang.tistory.com 홀맨님께서 이 TIL을 보시고는 코멘트 달아주셨는데 내용은 아래와 같다. 요약하자면 Virtual DOM가 수반하는 오버헤드가 상당하기 때문에 요새는 V..

React는 선언적 API를 제공하기 때문에 갱신이 될 때마다 매번 무엇이 바뀌었는지를 걱정할 필요가 없다. 이게 뭔 소릴까? 이를 이해하기 위해선 Virtual DOM이 무엇인지 먼저 알아야 한다. 💡 Virtual DOM 말 그대로 가상의 DOM이다. 브라우저에 실제로 보여지는 DOM이 아닌 메모리에 가상으로 존재하는 DOM으로 ReactDOM과 같은 라이브러리에 의해 “실제” DOM과 동기화하는 프로그래밍 개념이다. 리액트는 상태가 업데이트되면, 업데이트가 필요한 곳의 UI를 Virtual DOM을 통해서 렌더링하고, 그러고 나서 실제 브라우저에 보여지고 있는 DOM과 비교를 한 후, 차이가 있는 곳을 감지하여 이를 실제 DOM에 패치시켜준다. ⇒ 이 과정을 재조정(Reconciliation)이라고..

Flux 패턴은 MVC 패턴의 단점을 보안하기 위해 만든 페이스북에서 발표한 디자인 패턴으로 React, Redux의 디자인 패턴이기도 한다(참고로 이러한 Flux 패턴에 영감을 받아 Vue에서는 Vuex를 만들어 활용함). 먼저 MVC 패턴이 어떤 것인지 알아보자. MVC는 Model View Controller의 약자로, Model은 "무엇을 할지"에 대해 내부 비지니스 로직을 처리하고, View는 "무엇을 보여줄지" 유저에게 보여줄 화면을 처리하고, Controller는 유저의 요청을 받아서 "어떻게 처리할지" Model에 요청하는 구조의 디자인 패턴이다. 하지만 이러한 MVC 패턴이 갖고 있던 가장 큰 단점은 바로 양방향 데이터 흐름이다. 특히 Model이 업데이트되면 View가 이걸 화면에 반영..

12주차였던 이번 주는 React와 Jest를 활용하여 Todo App과 마카오페이 웹 페이지를 만들었다. 11/12 TIL | 나만의 메뉴 만들어보기. 어제까지 작성한 퀘스트 과제는 React로 마카오페이를 만들고, 나만의 메뉴를 추가하는 것이었다. 이번에는 Jest로 React 테스트를 써서 테스트 커버리지 100%까지 도전하는 것을 목표로 했는데 막상 bohyunkang.tistory.com 작업 측면에서 개인적으로 만족스럽지 못한 한 주였는데, 이번 주에 칭찬할 점과 반성할 점을 적어보자면 아래와 같다. - 칭찬할 점: 밀리지 않고 과제를 잘 마무리한 점 - 반성할 점: 개인적인 이유로 작업에만 몰두하지 못한 점, 과제 커버리지 100프로 챙기지 못한 점 그래서 다가오는 13주차 주간 학습 기간에..

어제까지 작성한 퀘스트 과제는 React로 마카오페이를 만들고, 나만의 메뉴를 추가하는 것이었다. 이번에는 Jest로 React 테스트를 써서 테스트 커버리지 100%까지 도전하는 것을 목표로 했는데 막상 useState를 사용하는 쪽은 테스트가 어려워 100프로 다 챙기지는 못하였다. 무튼! 그렇게 내가 추가한 나만의 메뉴 기능은 디지털 시계와 송금 일지로 아래 화면과 같다! 송금 기능을 통해 송금이 이뤄지면 송금 일지 드롭다운 박스에서도 확인할 수 있어 등록할 수 있다. 디지털시계는 송금 일지만 넣기에 너무 빈약한 거 같아 함께 넣어봄 ㅎㅎ.. 무튼 이번 과제는 전역적으로 상태 관리를 하고 있지 않아 새로고침되면 내용들이 다 사라졌는데, 13주차 강의부터는 전역 상태 관리를 하기 때문에 이 문제는 해..

현재 코딩 도장에서 같이 공부하고 있는 1기분들은 포트폴리오 주간이라 나의 두 달 뒤 미래를 미리 보고 있다. 두 달은 금방 지나가므로 원론적인 내용들은 미리 정리해놓는 게 좋을 거 같아 아샬님의 특강을 통해서 알게 된 유저 스토리 작성법을 알아보고자 한다. 우선 유저 스토리에 대한 정의를 알아보기 전에 이에 관련된 용어부터 정리해보자. - 이니셔티브(Initiative) or 테마(Theme): 서비스나 제품에서 큰 덩어리로 볼 수 있는 부분을 의미한다. 여러 개의 에픽으로 구성된 단위를 뜻하며, 여러 팀으로부터 진행된 Epic이 취합되어 이룰 수 있는 넓은 의미의 목표(Goal)를 의미한다. - 에픽(Epic): 완료하기까지 다소 오랜 시간이 걸리거나 몇 번의 스프린트가 요구되는 큰 업무 덩어리를 말..

어제오늘 아샬님이 1기분들의 포트폴리오 코드 리뷰 겸 리팩터링을 해주시러 코딩 도장에 오셨다. 오셔서 엄청나게 좋은 말씀을 많이 해주고 가셨는데.. 기억이 조금이라도 더 생생할 때 한번 정리해보고자 한다. 1. 기능에는 가치를 드러내야 한다. 단순히 기능만 나열하면 안 된다. 이 기능을 통해 사용자에게 어떤 것을 제공할 수 있는지, 또 사용자는 이 기능을 통해 어떤 것을 얻을 수 있는지에 대한 가치가 명확해야 한다.(As-I-So 기법 활용) 기능은 영원하지만 화면은 일시적이다. 화면에 집착하지 말자. 2. 규칙을 만들게 되면 우연에 따라가게 된다. 프로그래밍에는 정답이 없다. 이 경우에는 이 설계가 맞고, 저 경우에는 저 설계가 맞다. 근데 규칙을 만들어 버리면 설계에 대한 고민이 전혀 진행되지 않게 ..

해시 함수는 지난주에 읽었던 읽고 있는 암호화 서적에서 접하게 되어 지난번 암호화 방식 TIL에서 하지 못했던 해시 암호화 방식을 포함해서 해시 함수에 대해 정리해보려고 한다! 우선 해시 함수(짧게는 그냥 해시)는 임의의 길이를 갖는 임의의 데이터를 고정된 길이의 데이터로 매핑하는 단방향 함수를 말한다. 즉, 아무리 큰 숫자를 넣더라도 정해진 크기의 숫자가 나오는 함수이다. 해수 함수에 대해서 알아둬야 할 특징은 아래와 같이 3가지가 있다. 1. 해시 함수는 동일한 입력값(input)에 대한 동일한 출력 값(output)을 갖고 있다. => 즉, 입력값이 바뀌지 않으면 출력값도 바뀌지 않는다. 2. 입력값이 하나만 변경되어도 이에 대한 출력값은 완전히 달라진다.(쇄도 효과) 3. 항상 같은 방향, 즉 한..