1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

export const useGesture = (func) => {
  const ref = useRef(null)

  useEffect(() => {
    if (ref.current) {
      const hammer = new Hammer(ReactDOM.findDOMNode(ref.current))
      hammer.add(new Hammer.Press({ event: 'longpress', time: 500 }))
      //hammer.get('swipe').set({ direction: Hammer.DIRECTION_ALL })
      hammer.on('swipe', () => func?.())
    }
  }, [ref, func])

  return ref
}

Bind returned ref to desired element using createRef(), useRef(), forwardRef().

(주로 Reference 글들을 번역/요약하는 방식으로 작성되었습니다)

Hoisting 관점에서 var/function/function* vs let/const/class

All declarations are hoisted in JS.

However, var/function/function* are initialized as undefined whereas let/const/class are uninitialized. This means that a ReferenceError exception is thrown when you try to access it before initialization. It will only get initialized when let/const/class statement is evaluated, everything before that is called the temporal dead zone

Reference:
https://stackoverflow.com/questions/31219420/are-variables-declared-with-let-or-const-hoisted

Polyfill이란?

A polyfill is a piece of code (usually Javascript on the Web) used to provide modern functionality on older browsers that do not natively support it.

For example, a polyfill could be used to mimic the functionality of an HTML Canvas element on Microsoft Internet Explorer 7 using a Silverlight plugin, or mimic support for CSS rem units, or text-shadow, or whatever you want.

ex) core-js, babel/polyfill

Reference:
https://blog.bitsrc.io/how-to-write-cross-browser-web-apps-f26f0c5b49cb

Backend for Frontend (BFF)란?

1. Multiple clients with a single general-purpose server

Very simple but hard to maintain monolithic structure as service grows. Adding new features may cause side effects. Builds and tests take forever to run and it takes days to debug test failures.

1. Multiple clients with a microservices architecture

Microservices are greate for scalability and help solve a bunch of problems. Backend teams are typically responsible for a single service and no longer tripping over each other. Individual microservices are lightweight, customizable, decoupled, and readily extensible

However, there are still boundary issues amongst frontend teams. The responsibility of handling multiple clients is still encoded in one or many services. Frontend engineers are struggling to jam multiple use-cases into a single API layer and the customer experience is beginning to suffer.

1. Multiple clients with dedicated backends and a microservices architecture

Because our clients have very different needs. The BFF applications are lightweight translation layers that decouple individual clients from downstream services and server only a single frontend.

Benefits:

• Frontend teams gets ownership of both their client app and its underlying resource consumption layer.
• Mobile team is able to make changes such as payload size and requeset freqency reduction without having to extend and fork APIs developed for web-based use-cases.
• Encapsulation

Reference:
https://medium.com/frontend-at-scale/frontend-architectural-patterns-backend-for-frontend-29679aba886c

SASS / SCSS

CSS의 문법은 배우기 쉽지만 프로젝트가 커짐에 따라 점점 유지보수가 어려워진다. 이러한 CSS의 한계를 보완하기 위해 사용하는 CSS Preprocessor가 SASS이다. SCSS는 SASS의 3번째 버전에서 추가되었는데 SASS의 모든 기능을 지원하면서 CSS구문과 완전히 호환되도록 만들어졌다.

SASS를 사용하면 다음과 같은 기능들을 사용할 수 있다.

• 변수
• 조건문과 반복문
• Import
• Nesting
• Mixin
• Extend/Inhertiance

SASS는 CSS pre-processor로서, SASS자체로 브라우저에 적용하는 것이 아니라 CSS를 확장해서 쉽고 편리하게 쓰기위해 쓰는 스크립팅 언어이기 때문에 컴파일을 하여 CSS로 변환한뒤 적용된다.

Reference:
https://velog.io/@jch9537/CSS-SCSS-SASS
https://jinminkim-50502.medium.com/css-preprocessor-sass-scss-25dc8329f867

(주로 Reference 글들을 번역/요약하는 방식으로 작성되었습니다)

ExpressJS 대신 NestJS를 사용하는 이유

ExpressJS는 un-opinionated, minimalistic framework로써, 개발자가 올바른 선택을 할 것이라 믿고 맡긴다. 개발자는 자신이 원하는 tools, technologies, middleware 등을 선택하여 적용할 수 있다. 또 Framework에서 강제하는 구조또한 없다. 이는 개인으로 작업할 때는 높은 자유도를 보장해주지만, 팀으로 작업할 때는 의견충돌을 야기할 수 있으며, 큰 프로젝트에 참여하는 경우 각각의 micro-service team들의 project structure와 tool이 달라 다른 팀으로의 이동을 힘들게 한다.

NestJS는 highly opinionated framework이다. 따라서 NestJS는 개발자들이 특정 tool을 사용하고 특정한 방식으로 코드를 작성하도록 가이드한다. 그리고 이미 controller를 try-catch block으로 감싸놓고, request body를 parse하고, error handler, middleware 등을 이미 다 추가해놓았기때문에 매번 새 프로젝트를 시작할때마다 같은 작업을 반복하지 않아도 된다.

추가적으로 아래와 같은 장점이 있다.

• Typescript by default
• CLI tooling
• TypeORM support
• Microservices (built-in support for GraphQL, WebSockets, gRPC, MQTT, etc)
• Ease of testing

p.s. NestJS는 Express를 base로 사용한다고 한다.

Reference:
https://medium.com/monstar-lab-bangladesh-engineering/why-i-choose-nestjs-over-other-node-js-frameworks-6cdbd083ae67
https://codeburst.io/why-you-should-use-nestjs-for-your-next-project-6a0f6c993be

React Hook을 사용하는 이유

1. Class-based component로 작성할 경우 state를 관리할때 코드가 여기저기 분산되지만 hook을 사용한다면 한군데로 코드가 모아지므로 가독성이 좋아진다. + Refactoring이 쉽다.
   • constructor에서는 state를 선언하고
   • componentDidMount()에서는 초기화를 하고
   • render()혹은 메소드에서 manipulation을 진행
2. 간단한 component (자신의 state가 없고 props만을 사용한다거나)는 주로 functional component로 작성되는데, state를 추가하기 위해 class-based component로 바꾸지 않아도 된다.
3. 헷갈리는 this를 사용할 필요가 없어진다.
4. method binding이 필요가 없다.
5. JS에서는 function이 더 가볍다. Class는 React에서는 불필요한 class의 메소드들을 추가적으로 포함한다.
6. function은 closure를 사용한다. closure는 매우 memory-efficient하다.

Reference:
https://blog.bitsrc.io/why-we-switched-to-react-hooks-48798c42c7f
https://overreacted.io/how-are-function-components-different-from-classes/

브라우저 Rendering 과정

Virtual DOM이 필요한 이유

위의 Rendering과정에서 볼 수 있듯이, 만약 DOM에 변화를 주게된다면, Rendering Tree를 만드는 과정부터 다 다시 계산을 해야된다.
Complex SPA에서는 많은 숫자의 DOM manipulation이 일어나게 되는데 이를 매번 실제 DOM에 변화를 주게된다면 매우 비효율적이다.
따라서 DOM manipulation이 필요할 때, 바로바로 실제 DOM에 변화를 주는 것이 아니라 중간에 Virtual DOM을 두고
이를 변경함으로써 일종의 Buffering을 만드는 것이다. 기존에는 30번의 DOM manipulation이 일어났다면,
이 30번을 Virtual DOM에 우선 반영하고, 30번 변경이 된 최종 결과물을 실제 DOM에 반영함으로써 단 1번만 계산을 수행하면 된다.
이 작업은 render function과 화면에 element를 출력하는 작업 사이에 이뤄지며 이를 reconciliation이라고 한다.

Virtual DOM은 offline DOM(in-memory representation)으로 실제로 rendering되는 것이 아니므로 변경하는 비용이 크지 않다.\

Virtual DOM은 DOM을 추상화 한 자바스크립트 객체를 구성하여 사용한다.
업데이트하는 과정은:

1. 업데이트한 전체 UI를 Virtual DOM에 re-rendering
2. 실제 DOM과 생성된 Virtual DOM을 비교
3. 바뀐 부분만 실제 DOM에 적용

Reference:
https://hashnode.com/post/the-one-thing-that-no-one-properly-explains-about-react-why-virtual-dom-cisczhfj41bmssp53mvfwmgrq
https://brunch.co.kr/@eight-two-five/14

Class-based component의 constructor에서 super()를 호출하는 이유

Javascript는 언어적 제약사항으로서 생성자에서 super를 호출하기 전에는 this를 사용할 수 없다.\

props를 접근하기 위해 this.props를 사용하게 되는데, 이 this.props는 사용자가 정의한 component가 상속받고 있는 React.Component에 정의되어있다. super()는 자신의 부모의 생성자를 호출하는 것인데, React.Component의 생성자가 super(props)로 넘겨준 props를 자신의 this.prop에 초기화하는 것이고, 이 이후부터 사용자가 정의한 component에서도 this.props를 통해 부모인 React.Component의 this.props를 접근할 수 있게 되는 것이다.\

하지만 React에서는 super(props)를 통해 props를 전달하지 않고, super()만 호출하더라도 this.props를 통해 접근할 수 있는데, 이는 React가 컴포넌트의 생성자 호출 이후 해당 객체에 props속성을 세팅해주기 때문이다.

1
2

const instance = new YourComponent(props);
instance.props = props;

내부적으로 위와같이 처리가 되기 때문에 사용자가 실수로 props를 누락하더라도 정상적으로 작동한다.

Reference:
https://min9nim.github.io/2018/12/super-props/

리스트의 Key에 index를 사용하면 안되는 이유

key는 React가 DOM element들을 식별하기 위해 사용한다. 따라서 만약 리스트의 중간에 element를 추가하거나 삭제했지만 key가 이전과 같이 유지되는 경우 React는 DOM이 변화하지 않은 것으로 인식하고 그대로 보여준다.

예시:

1
2
3

key: 0 item: a
key: 1 item: b
key: 2 item: c

index 1의 값이 b에서 z로 바뀌어도 index를 key로 사용하기 때문에 key는 그대로이다.

1
2
3

key: 0 item: a
key: 1 item: z
key: 2 item: c

React는 DOM element가 바뀌지 않은것으로 판단한다.

1
2
3

key: 0 item: c
key: 1 item: a
key: 2 item: b

또 순서가 바뀌더라도 key는 똑같기때문에 반영되지 않는다.

아래의 3가지 조건이 모두 만족될 경우는 index를 key로 사용해도 안전하다고 한다:

1. the list and items are static - they are not computed and do not change
2. the items in the list have no ids
3. the list is never reordered or filtered

Reference:
https://robinpokorny.medium.com/index-as-a-key-is-an-anti-pattern-e0349aece318

언제 useCallback()과 useMemo()를 사용하여야 하는가?

Reference:
https://kentcdodds.com/blog/usememo-and-usecallback

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

.container {
    /* 3개의 행을 각각 100px로 만들겠다 */
    grid-template-rows: repeat(3, 100px); 
    /* 3개의 열을 각각 3등분해서 만들겠다(flex-grow:1과 같음) */
    grid-template-columns: repeat(3, 1fr); 
    /* 명시적으로 정의한 행과 열을 넘어갔을 때(암시적) 어떻게 배치할지*/
    grid-auto-flow: row;

    /* 그리드 컨텐츠의 수직 정렬을 설정*/
    align-content: center; /* row를 어떻게 정렬할지 */
    align-items: center;   /* 하나의 row안에서 어떻게 정렬할지 */
    /* 그리드 컨텐츠의 수평 정렬을 설정*/
    justify-content: center; /* column을 어떻게 정렬할지 */
    justify-items: center;   /* 하나의 column안에서 어떻게 정렬할지 */
    /* align-content와 justify-content에 동시적용됨 */
    place-content: center;


}


.item:nth-child(1) {
    /* CSS의 index는 0이 아닌 1부터 시작한다 */
    grid-row-start: 1;
    grid-row-end: 3;

    grid-column-start: 2;
    grid-column-end: 4;

    /* 끝나는 위치가 4이고, 길이를 2로 지정. 즉, 2~4까지를 너비로 가짐 */
    grid-column-start: span 2;
    grid-column-end: 4;
}

Reference: https://heropy.blog/2019/08/17/css-grid/