byeoung.log

[React] 스켈레톤 UI를 잘 작성해보자.

Mon, 13 Jan 2025 13:20:45 GMT

개요

웹 애플리케이션에서 데이터 로딩은 불가피한 요소이다. 이러한 상황에서 스켈레톤 UI는 사용자 경험을 크게 개선할 수 있는 중요한 디자인 패턴이다.

현재의 문제점

현재 애플리케이션은 모든 페이지에서 동일한 로딩 컴포넌트를 사용하고 있다. 이는 다음과 같은 한계를 가지고 있다.

사용자가 로드될 콘텐츠의 구조를 예측할 수 없음
페이지별 특성을 반영하지 못하는 획일적인 로딩 표시
콘텐츠 로드 완료 시 갑작스러운 레이아웃 변화

스켈레톤 UI를 통한 개선

스켈레톤 UI는 실제 콘텐츠가 표시될 영역의 구조를 미리 보여주는 방식이다. 이는 마치 건물의 뼈대를 먼저 세우는 것과 같은 원리로, 다음과 같은 이점을 제공한다.

페이지의 최종 레이아웃을 미리 파악 가능
더 자연스러운 로딩 경험 제공
사용자의 체감 로딩 시간 감소

어떤 기준으로 컴포넌트를 수정할까?

위에서 언급한대로 스켈레톤 UI는 뼈대를 보여주는 UI이다.

따라서 뼈대가 되는 컴포넌트들을 외부 컴포넌트로 따로 제작하고 Props를 활용하여 스켈레톤 UI인지 실제로 컨텐츠를 보여주는 UI인지 구분하려고 한다.

뼈대 컴포넌트 분리하기

위 화면의 스켈레톤을 제작한다면 그림처럼 뼈대를 잡을 수 있을 것이다.

가장 큰 뼈대는 ClassItem 이라는 컴포넌트로 이미 분리되어 있다. 그렇다면 ClassItem 컴포넌트의 Props를 추가하여 스켈레톤일 때와 아닐 때의 UI를 바꿔주면 될 것 같다.

문제점

위의 방식대로 구현을 하던 중 문제점을 발견했다.

우선 ClassItem의 기존 Props는 아래와 같다.

interface ClassItemProps {
  quizList: Quiz;
  index: number;
}

변경된 Props는 아래와 같다.

interface ClassItemProps {
  varient: 'skeleton' | 'content';
  quizList?: Quiz;
  index?: number;
}

문제점은 바로 quizList? 에서 나타난다.

optional props이기 때문에 quizList의 타입은 Quiz | undefined로 잡히게 되어 quizList를 활용하는 부분에서 타입에러가 발생한다.

해결책

위 문제의 해결책으로 Union 타입과 타입 단언을 사용했다.

이게 최선의 해결책인지는 모르겠으나 위와 같은 방식을 활용하기 위한 임시 해결책이다.

방법은 아래와 같다.

interface SkeletonProps {
  varient: 'skeleton';
}
interface ContentProps {
  varient: 'content';
  quizList: Quiz;
  index: number;
}

type ClassItemProps = SkeletonProps | ContentProps;

export default function ClassItem(props: ClassItemProps) {

    ...

  if (props.varient === 'skeleton') {
       ...
  }

  const { quizList, index } = props as ContentProps;

스켈레톤 Props와 컨텐츠 Props를 분리하여 Union 타입으로 지정 후 조건문을 통해 해당 되는 props에 접근한다.

결과

props를 통해 스켈레톤 UI를 제작한 방식의 장점을 꼽아보자면,

컴포넌트 재활용성이 올라갔다.
- varient props를 추가하여 스켈레톤일 때와 아닐 때 다른 UI를 리턴해주는 방식으로 ClassItem 컴포넌트를 재활용할 수 있었다.
SkeletonUI의 코드가 간단하다.
```
  export default function SkeletonQuizList() {
    return (
      
        
      
    );
  }
```
단순히 varient props만을 추가한 컴포넌트를 사용하기 때문에 간단한 구조를 가진다.

반면 위 방식의 단점을 꼽아보면,

ClassItem의 복잡도가 올라갔다.
- 기존 오롯이 ClassItem에만 쓰이는 비지니스 로직과 UI 코드가 존재했다면, varient props를 추가해줌으로써 varient 를 판단하는 로직과 스켈레톤 UI 코드가 혼재하면서 코드가 복잡해졌다.
다소 난해한 Props 타입
- 이전에는 Props를 Union 타입으로 활용해본적이 없어서 난해하게 느껴질지 모르겠으나, Props를 Union타입으로 선언하면서 불필요한 타입단언이 생겼다.

위의 장단점을 저울질 해보았을 때 개인적인 생각으로는 단점이 더 크다고 생각한다.

가장 큰 단점은 ClassItem 컴포넌트의 복잡도가 올라간 것이다.

사실 스켈레톤 컴포넌트는 단순한 UI만 제공하면 되기 때문에 현재 ClassItem에 존재하는 코드를 스켈레톤 컴포넌트에 넣는다고해서 코드의 복잡도가 크지는 않다.

하지만 ClassItem 컴포넌트는 실제 컨텐츠와 관련된 비지니스 로직과 UI들이 존재하기 때문에 스켈레톤과 관련된 코드들이 존재하면 다소 혼란스러울 수 있다.

결론

위에서 언급한 Props를 활용한 방식은 장점보다 단점이 크다고 생각한다.

그래서 스켈레톤 컴포넌트에 스켈레톤 UI를 직접 작성하는 방법으로 코드를 짰다.

기본적인 레이아웃만을 보여주기 때문에 직접 코드를 작성해도 매우 길이가 매우 짧고 간결했다.

위의 UI는 간단한 구조이기 때문에 직접 스켈레톤 UI를 작성하는 방식이 더 알맞다고 생각한다.

그렇다면 좀 더 복잡한 구조에서 스켈레톤 UI를 작성해보자.

복잡한 UI의 스켈레톤

결론부터 말하면 복잡한 UI의 스켈레톤은 더더욱 Props 방식을 지양해야된다는 것을 느꼈다.

기본적으로 UI가 복잡한 만큼 컴포넌트 내부의 비지니스 로직과 Props도 많아서 여기에 Varient Props를 추가하여 스켈레톤 UI를 추가하면 더욱 복잡해졌다.

그렇다면 좀 더 슬기롭게 스켈레톤 UI를 작성하는 방법은 무엇일까 생각해보다가 MUI의 스켈레톤 컴포넌트를 참고했다.

MUI의 스켈레톤

MUI는 이라는 컴포넌트가 존재한다.

해당 컴포넌트의 props로 모양, 크기, 애니메이션 등을 지정하여 사용한다.

즉, 회색 컴포넌트가 미리 생성되어 있고 props로 회색 컴포넌트를 조정한다고 생각하면된다.

  // 원형
  // 사각형
  // 둥근 모서리

MUI의 스켈레톤 컴포넌트를 참고해서 기존의 복잡한 스켈레톤 UI를 수정해보았다. 결과는 아래와 같다.

위에서 언급한 복잡한 컴포넌트 스켈레톤
- 컴포넌트 구조가 매우 복잡하여 읽기가 힘들다.

export default function SkeletonQuizWait() {
  return (
    
      
        
          
            
              
              
            
            
            
              
              
            
          

          
            
              {Array.from({ length: 32 }).map((_, index) => (
                
                  
                  
                
              ))}
            
          
        

        
          
        
      
    
  );
}



 컴포넌트를 적용한 모습
스켈레톤 컴포넌트에는 기본 배경 색과 애니메이션 코드만 작성되어있다.
여전히 복잡하나 약간은 정돈된 느낌이 든다.



    
      
        
          
            
              
              
            
            
            
              
              
            
          

          
            
              {Array.from({ length: 32 }).map((_, index) => (
                
                  
                  
                
              ))}
            
          
        

        
          
        
      
    

레이아웃을 커스텀 컴포넌트로 분리하고 스켈레톤을 적용한 모습
컴포넌트명 덕분에 읽기는 훨씬 수월하다.




    
        
          
            
              
              
            
            
            
              
              
            
          
    
    
         
            {Array.from({ length: 32 }).map((_, index) => (
              
                
                
              
            ))}
          
      
    
    
    
  


최종 컴포넌트 코드
초기 컴포넌트 로직 작성 시 레이아웃 컴포넌트들을 잘 분리하고,
내부 요소에 대한 스타일들을 클래스로 분리하여 작성하면 아래와 같은 모습이다.




    
        
          
            
              
              
            
            
            
              
              
            
          
    
    
         
            {Array.from({ length: 32 }).map((_, index) => (
              
                
                
              
            ))}
          
      
    
    
    
  

최종 결론
스켈레톤 UI를 잘 작성하기 위해서 필요한 것은 다음과 같다는 결론을 내렸다.

분리된 레이아웃 컴포넌트
내부 요소에 대한 스타일 클래스화
커스텀 스켈레톤 컴포넌트 활용

초기에 스켈레톤을 고려하지 않고 코드를 작성하다보니 프로젝트가 마무리되고 이를 수정하려니 시간과 노력이 많이 들었다. 
이번 경험을 통해서 스켈레톤 뿐 아니라 재사용성이 높은 컴포넌트 제작에 필요한 기본적인 요소들을 습득할 수 있었다고 생각한다.



Socket.io와 Tanstack Query 함께 쓰기
Wed, 01 Jan 2025 10:16:54 GMT
Socker Server State 관리 전략
현재 프로젝트는 실시간 양방향 통신을 위해 소켓을 활용하고 있으며, 대부분의 데이터가 소켓을 통해 주고받는 형태다. 기존에는 API를 통해 서버 데이터를 수신하고 이를 React-Query로 관리하려 했으나, API 호출이 적어 소켓 기반 데이터 관리로 방향을 전환했다. 따라서 소켓 통신으로 받는 Server State를 React-Query로 브라우저 캐시에서 관리하는 방안을 고민하게 되었다.
브라우저 캐시에 저장할 데이터의 기준
소켓을 통해 전달되는 모든 데이터를 브라우저 캐시에 저장하는 것은 비효율적이다. 예를 들어, 채팅과 같은 자주 변동되는 데이터는 캐시할 필요가 없다. 반면, 퀴즈 상태, 참가자 정보와 같은 준영속적이고 중요한 데이터는 캐시 관리에 포함하는 것이 바람직하다
React-Query와 Socket의 효율적 통합: useSuspenseQuery와 emitEventWithAck 활용
소켓 데이터를 관리할 때 React-Query와 useSuspenseQuery를 결합하면, 소켓 기반 데이터 흐름에서도 브라우저 캐시와 상태 관리를 효율적으로 수행할 수 있다. 기존의 useState 대신 React-Query의 캐시를 활용하여, 새로고침 시 자동으로 데이터를 패치할 수 있는 구조를 제공한다. 이를 위해emitEventWithAck 함수를 사용하여 소켓 이벤트를 Promise 기반으로 처리한다.
emitEventWithAck: 소켓 이벤트의 Promise 래핑
import { Socket } from 'socket.io-client';

export const emitEventWithAck = (socket: Socket, event: string, data: any) => {
  return new Promise((resolve, reject) => {
    socket.emit(event, data, (response: T) => {
      if (response) {
        resolve(response);
      } else {
        reject(new Error(`"${event}" event emit failed`));
      }
    });
  });
};

useQuizSession: React-Query와 소켓 데이터 통합
이 훅은 useSuspenseQuery를 사용하여 소켓 데이터를 React-Query의 캐시에서 관리한다. 이를 통해 퀴즈 세션 데이터를 브라우저에서 자동으로 캐싱하며, 새로고침 시에도 데이터를 자동으로 불러올 수 있는 구조를 제공한다.
//예시 코드
export const useQuizSession = ({ socket, pinCode }: UseQuizSessionProps) => {
  return useSuspenseQuery({
    queryKey: ['show quiz', pinCode],
    queryFn: () => emitEventWithAck(socket, 'show quiz', { pinCode }),
  });
};
사용 사례 및 장점

useState 불필요: 소켓 데이터를 관리하는 데 useState 대신 React-Query의 캐시를 사용하여 코드가 간결해진다.
응답 대기 처리: emitEventWithAck를 통해 소켓 이벤트 응답을 Promise로 관리하여 비동기 처리와 에러 핸들링이 용이하다.
효율적인 캐시 관리: React-Query의 queryKey를 활용해 필요한 데이터만 갱신하고 불필요한 요청을 줄인다.




[부스트캠프 멤버십] 6주차 회고
Sun, 06 Oct 2024 12:24:53 GMT
5주차 회고를 작성하지 않았다.
지난 2주간의 학습 스프린트를 회고해본다.
지난 2주에 대한 평가
챌린지와 멤버십 과정을 통틀어서 가장 학습과 구현을 못한 시간이었다. 그 원인에 대해서 생각해보면 1주간 인터미션으로 쉬고 그 다음주에 4일 동안 예비군을 갔다오면서 너무 오래 쉰 탓에 그런 것 같다. 그 전까지 이어오던 공부 템포를 잃어버린 느낌이다. 그래서인지 집중도 안되고 게임을 좀 했다. 
다행히도 좋은 팀원분들과 멘토님을 만나서 갈수록 회복이 되는 것을 느꼈다. 너무 열심히 해주시고 챙겨주셔서 이 분들에게 폐를 끼치면 안되겠다는 생각으로 따라갔다. 그래서 후반부에는 템포를 다시 찾은 느낌이다.
반성할 점
이번 학습 스프린트는 목표없이 주변 눈치만 살피며 나아갔다. 피어세션이나 그룹세션 때 어떻게는 결과물을 들고가야된다는 생각에 "학습" 스프린트의 의미가 무색하게 나를 위한 학습 과정이 빠져있었다. 그래서 절대적인 시간 투자도 부족한 것이 있지만 지난 2주간 알맹이 없는 시간을 보낸 것 같다. 
개선방향
목표 설정의 중요성을 느꼈다. 그래서 다음 2주가 시작되기 전에는 나의 목표를 정하고 시작하려고 한다. 이번 목표 중 하나는 팀원 분들에게 긍정적인 영향을 끼치겠다는 굉장히 어려운 목표도 있다. 이번 학습 스프린트에서 내가 도움을 받았던 것처럼 나도 남들에게 도움을 주고 싶다. 남에게 긍정적인 영향을 끼치는 가장 쉬운 방법은 굉~장히 열심히 하는 것이라 생각한다. 
화이팅!



[부스트캠프 멤버십] 4주차 회고
Sun, 15 Sep 2024 10:04:26 GMT
4주가 끝나고 연휴다...마지막 한주는 매우 아쉬운 한 주 였다. 그치만 쉬니까 좋다 
한줄평
지난주보다 퇴행한 한 주
이번주의 나
3주차에는 리팩토링에 집중한 한 주 였다면, 4주차에는 남은 기능에 집중하려고 했으나!@!@!
4일 중 하루는 거의 날렸다. 가장 큰 원인은 도망간 집중력이다. 체력이 문제일까 아니면 그냥 마음가짐의 문제일까. 아침에 일어나는 게 힘들고 과제에 집중이 힘들었다. 그래서 멍때리거나 유튜브 보는 시간이 길어지고 기능 구현에 많이 힘을 쓰지 못했다. 그리고 4일 중 하루는 유튜브보다가 3D 멀미 이슈로 1시간 정도 앓아누웠다. 
지난 주와 바뀐 점
지난 주는 계획을 한대로 착실히 보낸 한 주 였지만 이번주는 아무것도 지키지 못 한 한 주 이다. 우선 화,목에는 운동을 가기로 했으나 운동을 가지 않았고, 학습한 내용을 블로그에 포스팅 하기로 했으나 하나도 하지 않았다. 그 때문에 학습은 했으나 깊이있는 학습을 하지 않았다. 
대체로 부정적인 한 주 였으나, 배운점도 있다. 그룹원 분들을 보면서 기술적인 부분이나 태도적인 부분을 보며 나를 반성하였다. 반성으로 끝나면 되지 않고 이를 실천해야한다. 다행히도 한 주는 쉬어갈 수 있다. 이때 어떤 부분을 어떻게 개선해야할 지 곰곰이 생각해봐야겠다. 
정리
천금같은 한 주. 야무지게 잘 활용하자.



[부스트캠프 멤버십] 3주차 회고
Sun, 08 Sep 2024 11:31:58 GMT
시간이 빠르다 벌써 3주가 끝나고 한달차가 되어간다.
한줄평
지난주보다 발전된 한 주

이번주의 나
1,2주차 보다 구현보단 학습과 코드 개선에 집중한 한 주 였다.
기능구현은 좀 늦춰줬지만 더 단단하게 다지고 나아간다는 느낌을 받아서 지난 주보다 만족감이 높은 한 주였다. 이러한 방식으로 앞으로 학습 스프린트를 보낼 생각이다. 기능 구현이 늦어지는 것은 시간을 좀 더 할애하여 개선할 생각이다.
지난 주와 바뀐 점

학습한 내용을 정리하여 블로그 포스팅을 하였다.
구현한 코드를 리팩토링하는데 시간을 할애했다.

다음주의 나
학습과 구현의 비중을 6:4 정도로 다시 조정할 생각이다. 지난 주는 7:3의 비율이었다고 생각한다. 지난주는 리팩토링에 상당한 시간을 할애했는데 코드 구현 시 "리팩토링하면 되지"라는 생각을 버리고 구현할 때부터 깔끔한 코드를 작성해야겠다. 이번에 "Tidy First?"라는 책을 구매했는데 책에서 제시하는 방법대로 작은 것부터 깔끔한 코드로 작성해나갈 생각이다.
그리고 기록에 대한 고민이 많았는데 노션을 활용하며 좀 더 체계화된 기록을 할 수 있었다. 하지만 다른 캠퍼 분들을 보면 아직은 한참 부족한데 다른 분들이 어떻게 하는지 참고해나가면서 기록의 체계화도 더 발전시킬 계획이다.
정리
학습-기록-구현-리팩토링 병렬로 처리하자.



Express에서 미들웨어를 활용한 에러처리하기
Thu, 05 Sep 2024 13:29:59 GMT
미들웨어란?
요청과 응답 중간에 존재하여 미들웨어라 부른다.
미들웨어는 요청과 응답을 조작하여 기능을 추가하기도 하고, 잘못된 요청을 걸러내는 역할도 한다.
Express에서는 웹 요청과 응답에 대한 정보를 사용해서 필요한 처리를 진행할 수 있도록 분리된 독립적인 함수이다.
미들웨어 종류
1. 어플리케이션 레벨 미들웨어
app.use(미들웨어 함수) 또는 app.METHOD(미들웨어 함수)
( METHOD: get, post, delete ... )
내에서 정의되는 미들웨어를 의미한다.
2. 라우터 레벨 미들웨어
Express의 Router 객체에 bind된 미들웨어를 의미한다.
const router = express.Router();

router.get('/',(req, res) => { ... });

app.use('/api', router);
/api로 들어오는 요청에 대해서 등록된 미들웨어 함수가 동작한다.
3. 빌트인 미들웨어
Express에 내장된 미들웨어 함수를 의미한다.
4. 서드파티 미들웨어
서드파티 라이브러리에서 제공하는 미들웨어를 사용하여 기능을 추가할 수 있다.
5. 에러 핸들링 미들웨어
에러가 발생했을 때 호출되는 미들웨어이다.
일반미들웨어는 3개의 인자를 기본적으로 받지만 에러 핸들링 미들웨어는 4개의 인자를 받는다.
app.use((err, res, req, next) => {
  ...
}) 
에러 핸들링 미들웨어가 호출되는 경우

동기 처리 시 발생한 에러
  동기 처리 시 발생한 에러는 try - catch문에서 throw Error를 할 경우 Express가 해당 에러를 잡아 에러 핸들링 미들웨어를 호출시킨다.

  하지만 더 일반적인 방법은 next(err)를 통해서 에러 핸들링 미들웨어를 호출해주는 것이 더 명시적이기 때문에 next(err) 표현을 활용하는 것이 더 좋다.



비동기 처리 시 발생한 에러
비동기 처리 시 발생한 에러는 동기 처리 시 발생한 에러와는 다르게 throw Error를 통해 발생한 에러를 Express가 잡아주지 못한다. 
그래서 이때는 명시적으로 next(err)를 통해서 에러 핸들링 미들웨어를 호출해주어야 한다.

미들웨어 추가 방법
1. 전역 미들웨어

모든 요청에 대해서 실행되는 미들웨어이다.

app.use(미들웨어 함수)를 활용하여 전역 미들웨어를 추가할 수 있다.
서버에 요청이 들어오면 항상 미들웨어 함수가 실행된다.
2. 특정 경로에 대한 미들웨어

특정 경로로 들어온 요청에 대해서만 미들웨어가 실행되도록 한다.

app.use('/api' , (req, res) => { ... })
app.use()의 첫번째 인자로 경로를 지정하여 특정 경로에 대해서만 미들웨어가 실행되도록 할 수 있다.
3. 여러 개의 미들웨어 등록
미들웨어 함수는 하나만이 아니라 여러개 등록할 수 있다.
app.use( (req, res) => { ...1... } , (req, res) => { ...2... })
단, 이때 순차적으로 미들웨어 함수가 실행되게 하기위해서는 next() 함수를 반드시 호출해야 한다.
위의 경우 ...1... 만 실행되고 다음 미들웨어 함수는 실행되지 않는다.
app.use( (res, res, next) => { ...1... next() } ,
        (req, res) => { ...2... })
위의 경우 처럼 앞선 미들웨어 함수에서 next()를 호출해야 다음 미들웨어 함수가 실행이 된다.
미들웨어 함수

기본 인자 : req , res , next , err (에러 핸들링 미들웨어)

인자의 역할 :
req : request 객체 , 요청에 대한 정보를 담고 있다.
res : response 객체 , 이를 통해 서버에서 클라이언트로 데이터를 전송하거나, 상태 코드를 설정하고, 응답 본문을 정의할 수 있다.
next : 미들웨어 흐름 제어 , next(err) 시 에러 핸들링 미들웨어로 넘어간다.
err : 에러 핸들링 미들웨어에서 사용되며 에러에 대한 정보를 담고 있다.

2개 이상 미들웨어 함수를 등록할 수 있다.


Express에서 에러 핸들링 하기!
현재 BE 구조

현재 문제점

반복된 try-catch 사용
 service, controller의 모든 함수에서 try-catch문을 사용하고 있다.

구체화되지 않은 Error code
 대부분의 에러들이 500 에러로 구체화되어 있지 않다.

Error handle Middleware의 미사용
 Error handle Middleware가 구현이 되어있으나 이를 활용하지 않고 있다.


문제 해결 방법

반복된 try-catch문 => Wrapper 함수 활용
 각 service, controller 함수들을 감싸는 wrapper함수를 만들어 두고 wrapper 함수 내에서 try-catch 문을 통해 에러 핸들링을 수행하였다.
 반복되어 사용하던 try-catch문을 줄일 수 있었다.

구체화되지 않은 Error code => custom Error class 선언 및 활용
 Error 클래스를 extends 하는 커스텀 에러 클래스를 선언해두고 예상되는 에러 사항에 맞는 에러 클래스들을 호출하여 에러를 세분화하여 관리하였다.

Error handle Middleware 활용
 Controller 함수들을 감싸는 Wrapper함수에서 에러 발생 시 next(error)를 통해 에러 핸들링 미들웨어로 에러를 보내도록 하여 해당 미들웨어에서 에러 처리를 하도록 수행하였다.


[참고자료]:
[EXPRESS] 📚 미들웨어 이론 & 실용 💯 정리



JS는 어떻게 동작할까
Wed, 04 Sep 2024 09:39:12 GMT
NodeJs는 무엇인가?
Javascript를 브라우저 외부에서 실행가능하도록 하는 JS 런타임 환경
기존에는 브라우저에서만 동작하여 클라이언트 측 언어였으나 NODEJS 출현 이후 서버에서도 활용된다.
런타임 환경?

코드 실행 환경. 즉, 코드를 실행하기 위한 일련의 구성요소와 도구를 의미한다.
크롬 브라우저는 V8 엔진, DOM, Web Apis 등으로 런타임 환경이 구성된다.
NODEJS는 V8엔진, libUV, Nodejs core lib 등으로 런타임 환경이 구성된다.

NodeJs의 특징

비동기 I/O 및 이벤트 기반 처리 
단일 스레드 모델
이벤트 루프

NodeJs는 위와 같은 3가지 특징을 가지는데 위 3가지 특징은 연관성을 가진다.
이를 한 줄로 요약하면 다음과 같다.

NodeJs는 싱글스레드 기반으로, 비동기 I/O와 이벤트 루프를 통해 논블로킹 처리를 지원하는 런타임 환경이다.

싱글스레드는 단 하나의 콜스택을 가진다. 즉, 한번에 하나의 일을 처리할 수 있다.
싱글스레드인데 어떻게 비동기적으로 I/O를 처리하는지 의문이 든다.
브라우저에서 JS는 어떻게 동작하는가
V8 엔진이 Js 런타임 환경을 제공한다.
Blocking 이란 무엇인가

블로킹은 느린 작업을 의미한다. 
콜스택에 느린 작업이 포함된 경우 블로킹이라 말할 수 있다.

만약 동기적으로 작업한다면 블로킹 코드가 있는 경우 매우 느리게 작업을 수행할 것이다.
console.log("HI")
setTimeout(()=>{console.log("LONG")},10000)
console.log("HELLO")
위 코드를 동기적으로 실행하게 된다면 다음과 같이 출력된다.
HI
(10초 뒤)
LONG
HELLO
하지만 위 코드를 크롬에서 돌리게 되면 다음과 같다.
HI
HELLO
(10초 뒤)
LONG
어떻게 이런식으로 동작할까?
보통 싱글스레드라고 한다면 아래 그림처럼 생각할 수 있다.

브라우저가 그림과 같다면 위에서 보았던 첫번째 결과처럼 동작할 것이다.
하지만 실제 브라우저는 두번째 결과를 보인다. 
그렇다면 실제 브라우저는 어떻게 동작할까?

단순히 콜스택과 힙만 있던 구조에서 뭔가가 추가되었다. 딱봐도 중요해보이는 친구들이다.
Web APIs , Queue, EventLoop 이 3가지 덕분에 브라우저는 블로킹 코드들을 논 블로킹하게 처리할 수 있게되었다.
세 친구들이 어떻게 동작하는지 알아보자
우선 Web APIs는 setTimeout 같은 타이머의 시간초를 대신 세어주는 친구를 가지고 있다. 그래서 callstack에 들어온 setTimeout의 작업을 Web API에게 떠넘길 수 있다.
Web API는 시간을 세고있다가 정해진 시간이 되면 가지고 있던 callback 함수를 queue에 넣는다.
EventLoop는 Queue에 존재하는 작업을 Callstack에 집어넣는 역할을 수행하는데 Callstack이 비어있을 경우 작업을 집어넣는다.
Loop라는 말처럼 계속 돌면서 Callstack과 Queue의 상태를 살핀다.
WebAPIs
https://developer.mozilla.org/en-US/docs/Web/API
WebAPIs를 찾아볼 수 있다. 
하지만 Timer API는 찾아볼 수 없는데 setTimeout이나 setInterval같은 함수들은 Web Workers API가 하는 기능에서 찾아볼 수 있다.
Queue
위의 그림에서는 큐 하나로 표현했지만 실제 브라우저에서는 3개의 큐를 가지고 있다.
Task Queue , MicroTask Queue , Render Queue를 가지고 있다.
큐마다 하는 일이 달라서 '큐를 3개로 나누어 놓았겠구나' 라는 생각이든다.
각각의 큐는 어떤 일들을 처리하고 큐 간의 우선순위는 어떻게 나뉘어질까?

MicroTask Queue : 
Promise가 성공 또는 실패한 뒤 호출되는 then catch의 콜백함수 들이 들어간다.
MutationObserver의 콜백 함수
queueMicrotask()의 콜백함수 




Task Queue : 
MicroTask가 하지 않는 비동기 작업들이 Task Queue에 들어간다고 생각하면 된다. 




Render Queue : 
브라우저가 화면을 업데이트하고 Repaint 또는 Reflow를 처리할 때 사용되는 큐이다.
DOM, CSS 변경 사항이 있을 경우 해당 작업들을 처리한다.



우선순위
Microtask Queue > Task Queue > Render Queue
NodeJS는 어떻게 브라우저처럼 동작하게 할까?
앞서서 브라우저에서 JS가 동작하는 방식을 보았다.
브라우저에서는 WebAPIs, 큐, 이벤트 루프를 통해서 논블로킹 비동기 처리를 지원할 수 있었다.
NodeJs도 브라우저와 유사한 방법으로 동작한다.
브라우저 환경이 아니기 때문에 WebAPI가 없는 대신 libuv를 활용해서 이를 지원한다.
libuv 내부에 이벤트 루프를 가지고 있어 비동기 작업, 네트워크 I/O와 같은 작업들이 이벤트 루프에 의해 처리된다.
하지만 브라우저의 이벤트 루프와는 약간은 다른 점이 libuv의 이벤트 루프는 6 단계를 거친다.

[출처] https://www.korecmblog.com/blog/node-js-event-loop
6단계의 페이즈 별로 어떻게 동작하는 지
https://www.korecmblog.com/blog/node-js-event-loop 블로그에 상세하게 나와있으니 참고하시길...
[참고자료]
https://www.youtube.com/watch?v=P9csgxBgaZ8
https://sjh836.tistory.com/149
https://www.korecmblog.com/blog/node-js-event-loop
https://blog.naver.com/pjt3591oo/221976414901
https://www.youtube.com/watch?v=8aGhZQkoFbQ
https://www.youtube.com/watch?v=cCOL7MC4Pl0
https://developer.mozilla.org/en-US/docs/Web/API
https://www.youtube.com/watch?v=eiC58R16hb8
https://javascript.plainenglish.io/how-the-event-loop-works-in-the-chrome-browser-ccf99c6c5a5



[부스트캠프 멤버십] 2주차 회고
Sun, 01 Sep 2024 12:58:30 GMT
챌린지 과정을 끝내고 멤버십에 합류할 수 있었다. 강력해진 내가 멤버십 과정을 어떻게 헤쳐나갈까를 기대하며 멤버십에서의 한 주를 보냈다.
한줄평
한 달 전의 나로 회귀했다... 
이번 주의 나
챌린지 초반과 비슷하게 구현과 학습의 균형을 못 잡고 있다.
차라리 학습에 균형이 쏠렸으면 좋았을텐데 구현에 균형이 쏠려 학습이 소홀했다.
구현 진행도는 빠른편이나 나에게 남은 것이 별로 없는 느낌이 강하다.
이를 보완하기 위해 한가지 주제에 대해서 깊게 파면서 공부하고 이를 블로그에 포스팅하기로 했다.
이번주 딥다이브 주제는 NODEJS였고 이를 아직도 공부 중이다...
단순히 공부하는 것은 괜찮지만 이를 글로 남기는 것이 굉장히 어렵다고 느껴진다.
다음 주의 나
이번 주에서 가장 아쉬운 점은 딥다이브한 주제를 포스팅하지 못 한 것이다.
우선 NODEJS를 깊게 공부하고 다음은 브라우저 동작방식에 대해서 깊게 공부해 볼 생각이다.
블로그 포스팅이라는 것에 압박을 갖지 말고 부담없이 작성하고 이를 계속해서 수정해나가야겠다.
두번째로 아쉬운 점은 생활습관이다. 아침 일찍 일어나는 것과 운동하는 습관이 아직 안 잡혀있다.
원래의 목표는 8시 30분에 기상하고 주 3회 운동을 하는 것이 목표였는데 이번 주는 보통 9시에 일어나고 운동은 한번 갔다. 이것도 마찬가지로 부담을 지우고 해야겠다.
8시 30분에 일어나서 바로 뭐를 하지 않아도 일단은 일어나는 것부터, 운동도 무조건 1시간 이상을 하지 않더라도 일단 헬스장에 가는 것부터 하려고 한다.
정리
부담갖지 말고 가벼운 마음으로 실행을 하자.