To save or to autosave: Autosaving patterns in modern web applications

자동 저장에 대한 패턴을 소개합니다.

1. Autosave on a time interval.
2. Autosave on an action interval.
3. Autosave when action is followed by inaction.
4. Autosave when focus is shifted.

+) Autosave with web sockets

고민한 것들

자동 저장 요청을 보낸 후, 새롭게 변경된 서버 상태를 기반으로 다시 동기화해야 하는가?

최신화된 서버 상태를 기반으로 클라이언트에 동기화한다는 것은 최신 상태의 허브를 "서버"로 둔다는 것. 여러 클라이언트가 함께 작업한다면, "서버"가 최신 상태를 관리하고 이를 동기화함으로써 충돌을 방지할 수 있을 것이다.

이는 곧, 동시 작업을 수행하지 않는 경우에는 불필요한 작업일 수 있다는 것이기도 함.

현재 진행하는 프로젝트에서 "동시 작업"은 제공하고자 하는 기능이 아니기 때문에, 서버 상태를 기반으로 동기화하는 것은 진행하지 않기로 결정했음.

내용

• vscode(또는 cursor)에서 lint가 제대로 되지 않는다.
  • ex) useEffect에 전달하는 deps에 값을 제대로 전달하지 않았을 때
  • ex) 전달받은 매개변수를 사용하지 않았을 때

새로운 프로젝트를 진행하는데, lint 설정은 이전 프로젝트와 그대로지만 에디터에서 lint 경고나 에러를 제대로 나타내지 못했다.

환경

package.json

"next": "15.0.1",
"eslint": "^9.14.0",

.eslintrc.json

{
  "extends": ["next/core-web-vitals", "next/typescript"]
}

해결

디버그 (debug)

eslint debugger를 통해 설정에 어떤 문제가 있는지 파악할 수 있다. https://eslint.org/docs/latest/use/configure/debug

$ npx eslint --debug

Oops! Something went wrong! :(

ESLint: 9.14.0

ESLint couldn't find an eslint.config.(js|mjs|cjs) file.

From ESLint v9.0.0, the default configuration file is now eslint.config.js.
If you are using a .eslintrc.* file, please follow the migration guide
to update your configuration file to the new format:

https://eslint.org/docs/latest/use/configure/migration-guide

If you still have problems after following the migration guide, please stop by
https://eslint.org/chat/help to chat with the team.

eslint 버전이 9로 업데이트됨에 따라, eslint의 설정을 관리하는 파일의 형태가 변경되었고 기존에 사용하고 있던 형태인 .eslintrc.*는 새로운 파일 형태로 변경해주어야 한다는 것.

마이그레이션 (migration)

.eslintrc.json

{
  "extends": ["next/core-web-vitals", "next/typescript"]
}

eslint.config.mjs

import path from "node:path";
import { fileURLToPath } from "node:url";
import { FlatCompat } from "@eslint/eslintrc";
import js from "@eslint/js";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
const compat = new FlatCompat({
    baseDirectory: __dirname,
    recommendedConfig: js.configs.recommended,
    allConfig: js.configs.all
});

const config = [
  ...compat.extends("next/core-web-vitals", "next/typescript"),
];

export default config;

결론

eslint 9로 버전이 변경됨에 따라, 기존 설정 파일 형태 중 .eslintrc.*를 사용할 수 없게 되었음. 이로 인해, 에디터에서 해당 설정을 읽을 수 없게 되면서 lint가 동작하지 않았던 것.

eslint debugger를 통해 문제에 대한 원인을 찾을 수 있었고, 마이그레이션 가이드를 따라 해결할 수 있었다.

참고

• Eslint 마이그레이션 가이드 https://eslint.org/docs/latest/use/configure/migration-guide

• 유사한 문제를 겪은 개발자의 질문 https://stackoverflow.com/questions/79128326/eslint-9-is-not-working-properly-with-next-15

• nextjs 15 github issue https://github.com/vercel/next.js/issues/71763#issuecomment-2436288395

LinkedIn에서 제목 그대로 storybook 팀이 lodash 대신 toss 팀의 오픈소스인 es-toolkit을 도입했다라는 문동욱님의 글을 보게 되었다.

storybook에 es-toolkit을 도입하게 된 설명은 다음과 같았다.

lodash is hard to tree-shake, it's CJS, and we want to move to less heavy, ESM dependencies.

This replaces lodash for es-toolkit which is mostly a drop-in replacement ♥️

I've only changed the core for now.

왜?

눈에 들어온 키워드는 tree-shake, CJS, ESM

1. tree-shake는 빌드 과정에서 사용하지 않는 모듈을 포함시키지 않는 것이라고 알고 있는데, 왜 lodash는 tree-shake가 어려운 걸까?

2. CJS와 ESM의 어떤 부분이 다르기 때문에 tree-shake에 영향을 주는 걸까?

Lodash가 tree-shake가 어려운 이유는 CommonJS(CJS)와 ES Modules(ESM)의 차이와 관련되어 있음

CJS (CommonJS):

• 노드 환경에서 주로 사용되며, module.exports와 require()로 모듈을 불러온다.
• 런타임에서 모듈을 불러오는 동적 구조이기에 빌드 도구 입장에서 어떤 코드가 사용되는지 분석하기 어렵다. 따라서, tree-shaking이 잘 동작하지 않는다.

ESM (ES Modules):

• 브라우저와 모던 자바스크립트 환경에서 사용되며, import와 export로 정적 구조를 가진다.
• 정적 구조라서 빌드 타임에 어떤 모듈을 사용하는지 명확하게 분석할 수 있다. 빌드 도구가 사용되지 않는 코드를 안전하게 제거(tree-shake)할 수 있다.

결론

• Lodash는 주로 CJS로 작성되었음

• CJS(CommonJS)는 런타임에서 모듈을 불러오는 "동적 구조"이기에 tree-shake가 어려움

• ESM(ES Modules)는 "정적 구조"이기에, 어떤 모듈을 사용하는 지 명확히 분석할 수 있어 사용하지 않는 코드를 제거(tree-shake)할 수 있음

• 공간 정보를 다루기 위해 PostGIS를 활용하기
• postgreSQL의 function을 활용하여 데이터를 가져오기
• 성능 측정 (단순 비교 vs PostGIS)

배경

지도에 마커를 표시하기 위해 데이터를 불러와야 했는데, 모든 데이터를 가져온 후에 지도에 표시하는 것은 비효율적인 방법이라고 생각했다. (클라이언트 지도 상에 보이지 않는 영역에 대한 데이터를 불러오기 때문)

클라이언트에서 보고 있는 영역에 대한 데이터만 불러오려면 어떻게 해야 할까?

1. 클라이언트에서 보고 있는 영역에 대한 정보를 가져온다.
2. 영역 정보를 기반으로 데이터를 요청한다.

1) 클라이언트에서 보고 있는 영역에 대한 정보를 가져온다.

보고 있는 영역의 좌표는 남서쪽 모서리(min)와 북동쪽 모서리(max) 좌표를 통해 표현할 수 있다.

2) 영역 정보를 기반으로 데이터를 요청

따릉이 정류소 데이터

영역에 해당하는 정류소 데이터를 가져오려면?

1. 단순 비교

지도의 경계 좌표가 남서(37.571, 126.976), 북동(37.573, 126.979) 라면, 아래 조건을 통해 데이터를 필터링하여 가져올 수 있다.

37.571 <= latitude <= 37.573 126.976 <= longitude <= 126.979

// supabase 예시 코드
const get_data_within_bounds = async (
  lat_min,
  lat_max,
  lon_min,
  lon_max
) => {
    const { data, error } = await supabase
        .from('my_marker_data')
        .select('*')
        .gte('latitude', lat_min)
        .lte('latitude', lat_max)
        .gte('longitude', lon_min)
        .lte('longitude', lon_max);
    // ...
}

2. PostGIS 확장

PostgreSQL의 PostGIS 확장을 사용하면, 지리 공간 데이터를 더욱 효율적으로 관리하고 쿼리할 수 있다.

1. PostGIS 확장 활성화 데이터베이스에서 PostGIS 확장을 활성화한다.

   CREATE EXTENSION IF NOT EXISTS postgis;

2. 지리 공간 데이터 타입의 컬럼 추가

   ALTER TABLE my_marker_data
   ADD COLUMN geom geometry(Point, 4326);

• 4326은 WGS 84 좌표계를 나타냅니다.

3. 기존 데이터 업데이트

UPDATE my_marker_data
SET geom = ST_SetSRID(ST_MakePoint(longitude, latitude), 4326);

• ST_MakePoint(longitude, latitude): 포인트 생성
• ST_SetSRID: 좌표계(SRID) 설정

4. 데이터베이스 함수 생성

CREATE
OR REPLACE FUNCTION public.stations_in_view (
  min_latitude DOUBLE PRECISION,
  max_latitude DOUBLE PRECISION,
  min_longitude DOUBLE PRECISION,
  max_longitude DOUBLE PRECISION
) RETURNS TABLE (
  id BIGINT,
  station_id TEXT,
  station_name TEXT,
  LOCATION TEXT,
  latitude DOUBLE PRECISION,
  longitude DOUBLE PRECISION
) AS $$
BEGIN
    RETURN QUERY
    SELECT 
        s.id,
        s.station_id,
        s.station_name,
        s.location,
        s.latitude,
        s.longitude
    FROM 
        public.stations s
    where
      ST_Intersects(
          s.geom,
        ST_MakeEnvelope(
            min_longitude, min_latitude,
            max_longitude, max_latitude,
            4326
        )
      );
END;
$$ LANGUAGE plpgsql;

5. 클라이언트에서 쿼리 수행

const get_data_within_bounds = async (max_latitude, max_longitude, min_latitude, min_longitude) => {
    let { data, error } = await supabase
        .rpc('stations_in_view', {
            max_latitude, 
            max_longitude, 
            min_latitude, 
            min_longitude
        });
    // ...
}

추가

성능 비교

클라이언트에서 성능 측정

지리 정보를 활용하는 방식이 일반적인 필터에 비해 당연히 빠를 것이라고 생각했는데, 예상과 다른 결과. 쿼리 성능보다는 네트워크의 영향이 더 큰 건 아닐까?

쿼리 성능 측정

EXPLAIN ANALYZE 를 활용해서, 쿼리 성능을 측정했다.

ex) Seq Scan on stations (cost=0.00..83.63 rows=2763 width=131) (actual time=0.013..0.277 rows=2763 loops=1) Planning Time: 0.390 ms Execution Time: 0.486 ms

cost: 예측한 쿼리 실행 비용 actual time: 실제 실행 시간 (첫 번째 행을 가져오는 데 걸린 시간, 마지막 행을 가져오는 데까지 걸린 총 시간) planning time: 쿼리 실행 계획을 수립하는 데 걸린 시간 execution time: 쿼리를 실제로 실행하는 데 걸린 전체 시간 (모든 노드의 실행 시간 + 추가적인 오버헤드)

EXPLAIN ANALYZE
SELECT
  *
FROM
  public.stations
WHERE latitude >= 36
  AND latitude <= 38
  AND longitude >= 126
  AND longitude <= 128;

EXPLAIN ANALYZE
SELECT *
FROM public.stations
WHERE ST_Intersects(
  geom,
  ST_MakeEnvelope(126, 36, 128, 38, 4326)
);

성능: 단순 비교 > PostGIS

예상과 달리 공간 인덱스를 생성했음에도 단순 필터를 이용해 비교를 하는 것 보다 느리게 나왔다. 데이터 수가 적어서 순차적 스캔이 활성화될 수 있다고 해서, 순차 스캔을 비활성화도 해봤지만 속도가 빠른 결과가 나오지는 않았다.

성능 차이가 발생한 이유 (by gpt)

• 데이터량이 적음
• 공간 함수의 오버헤드
• 쿼리 계획 수립 시간 증가

위 성능 차이가 유의미한 차이일까?

실행 시간 비교

• 단순 비교 쿼리: 0.7ms
• 공간 쿼리: 1.2ms

절대 시간 차이는 약 0.5ms 이는, 실제 애플리케이션에서 사용자 체감 성능에 거의 영향을 미치지 않음.

성능 차이의 유의미성을 판단하는 기준 (사용자 경험에 미치는 영향) (by gpt)

• 응답 시간이 1초를 넘을 경우: 성능 개선 필요
• 응답 시간이 100ms 이내: 사용자들이 느리다고 느낄 수 있지만, 대부분의 어플리케이션에서 충분히 빠름

Next

• 정류소 데이터를 효과적으로 캐싱하려면 어떻게 해야 할까?

💡 아웃바운드를 위하여 후보자를 외부 사이트(ex. 링크드인)를 통해 소싱하려고 할 때, 위하이어 사이트와 소싱을 위한 외부 사이트를 번갈아가며 작업하는 것이 번거롭기에 이를 해결하기 위해 확장 프로그램을 개발하였습니다.

요약

• iframe을 통해, 확장 프로그램을 웹뷰로써 동작하도록 합니다.

  • window의 message 이벤트를 통해 상호작용합니다.

• 확장 프로그램의 유지보수를 위해, 타입스크립트로 전환하였습니다.

세부 내용

• iframe을 통해, 확장 프로그램을 웹뷰로써 동작하도록 합니다. 확장 프로그램의 재배포 과정을 거치지 않고, 웹 서비스의 업데이트를 통해 유저에게 최신 버전의 서비스를 제공할 수 있습니다.

  function createIframe(
    id: string,
    url: string,
    styles: Record<string, string>
  ): HTMLIframeElement {
    const iframe = document.createElement('iframe');
    iframe.id = id;
    iframe.setAttribute('src', url);
    Object.assign(iframe.style, styles);
    return iframe;
  }
  
  function insertIframe() {
    const wehireIframe = createIframe(
      IFRAME_ID,
      WEHIRE_URL,
      IFRAME_STYLES
    );
    wehireIframe.className = 'wehire-iframe';
    document.body.prepend(wehireIframe);
    // ...
  }

• window의 message 이벤트를 통해 상호작용합니다.

  • 웹뷰의 picker 버튼을 클릭했을 때, 클라이언트 브라우저에 마우스 이벤트를 등록합니다.

    // 웹뷰
    <button onClick={() => {
      window.parent.window.postMessage({
        type: 'activatePicker',
        pickerType: 'name',
      }, "*");
    }}>
      Name Picker
    </button>

    // 확장 프로그램
    let pickerType = null;
    
    const onMessage = (
      event: MessageEvent<IframeEventMessage>
    ) => {
      const eventType = event.data.type;
    
      switch (eventType) {
        case 'activatePicker': {
          pickerType = event.data.pickerType;
          addMouseEvent();
        }
    
        case 'autoScraping': {
          // ...
        }
      }
    };
    
    window.addEventListener('message', onMessage);

• 유지보수를 위해 스택을 자바스크립트에서 타입스크립트로 전환하고, 빌드를 위해 웹팩을 사용했습니다. (웹팩 설정)

  const path = require('path');
  const { CleanWebpackPlugin } =
        require('clean-webpack-plugin');
  const TerserPlugin =
        require('terser-webpack-plugin');
  
  module.exports = {
    entry: {
      background: './src/background.ts',
      script: './src/script.ts',
    },
    module: {
      rules: [
        {
          test: /\.tsx?$/,
          use: 'ts-loader',
          exclude: /node_modules/,
        },
      ],
    },
    resolve: {
      extensions: ['.tsx', '.ts', '.js'],
    },
    output: {
      filename: '[name].js',
      path: path.resolve(__dirname, 'dist'),
      publicPath: '/',
    },
    plugins: [
      // 빌드할 때마다 dist 폴더를 정리
      new CleanWebpackPlugin(),
    ],
    // 디버깅을 위하여, 소스맵 추가
    devtool: 'source-map',
    optimization: {
      minimize: true,
      minimizer: [
        // 코드 압축을 위해 TerserPlugin 추가
        new TerserPlugin({
          terserOptions: {
            compress: {
              drop_console: true,
            },
          },
        }),
      ],
    },
  };  

추가 내용

Window.postMessage()

  targetWindow.postMessage(message, targetOrigin, [transfer]);

주의사항

• 메시지 출처 검증 및 targetOrigin 명시

  메시지를 수신할 때, 반드시 메시지의 출처(origin)를 검증해야 합니다. 이를 통해 신뢰할 수 없는 도메인에서 전송된 메시지를 처리하지 않도록 할 수 있습니다.

  메시지를 전송할 때는 postMessage의 두 번째 인자로 targetOrigin을 명시하여, 메시지가 전송될 대상의 출처를 지정합니다. targetOrigin의 정보와 targetWindow의 정보가 맞지 않다면 이벤트는 전송되지 않습니다.

  // 확장 프로그램
  const TARGET_ORIGIN = 'https://wehire.kr';
  
  // 메시지 수신 (메시지 출처 검증)
  window.addEventListener('message', (event) => {
    // 보안 검증: 메시지의 출처(origin) 확인하기
    if (event.origin !== TARGET_ORIGIN) {
      // 신뢰할 수 없는 출처에서 온 메시지를 무시합니다.
      return;
    }
  });
  
  // 메시지 발송 (targetOrigin 명시)
  function sendMessageToIframe(message) {
    iframe.contentWindow.postMessage(message, TARGET_ORIGIN);
  }

  // 웹뷰
  const TARGET_ORIGIN = 'chrome-extension://<EXTENSION_ID>'
  // 메시지 수신
  window.addEventListener('message', (event) => {
    if (event.origin !== TARGET_ORIGIN) {
      return;
    }
  });
  
  // 메시지 발송
  function sendMessageToExtension(message) {
    window.parent.window.postMessage(message, TARGET_ORIGIN);
  };

💡 채용 페이지를 쉽게 구성하고, 관리할 수 있도록 어드민 페이지를 제공하고, 채용 페이지의 SEO 최적화를 통해 더 많은 구직자들에게 접근할 수 있도록 한다.

기술

• Context API
• IntersectionObserver API
• ServerSide Rendering

세부 사항

채용 페이지 구성을 위한 어드민 페이지 구성

• Context API를 사용하여 복잡한 폼을 관리하고, 컴포넌트 구조화를 통해 효율적인 상태 관리를 구현했습니다.

  - /settings
    - /sites
      - SettingSiteFormProvider.tsx (Context Provider)
      - useSettingSiteFormContext.ts (useContext 커스텀 훅)
      - index.tsx (페이지 컴포넌트)

  // SettingSiteFormProvider.tsx
  const SettingSiteFormProvider = ({
    children,
    defaultValue,
  }) => {
    const form = useForm({
      defaultValue,
    });
  
    // ...
    return (
      <FormProvider {...form}>
        {children}
      </FormProvider {...form}>
    )
  };
  
  // useSettingSiteFormContext.ts
  const useSettingSiteFormContext = () => {
    const form = useFormContext();
  
    return form;
  };

  // 활용
  // index.tsx
  const SettingsSitePage = () => {
    // ...
  
    return (
      <SettingSiteFormProvider>
        <SEOFieldset />
        <SocialChannelsFieldset />
      </SettingSiteFormProvider>
    ); 
  };
  
  // SEOFieldset.tsx
  const SEOFieldset = () => {
    const form = useSettingSiteFormContext();
  
    // ...
  };

• IntersectionObserver API를 활용하여 scrollSpy 기능을 구현해, 사용자가 스크롤할 때 현재 위치를 쉽게 파악할 수 있도록 했습니다.

  // useScrollSpy.ts
  const useScrollSpy = (
    targetElements,
    options,
  ) => {
    const [activeSection, setActiveSection] = useState('');
  
  useEffect(() => {
    const callback = (entries) => {
      // ...
    };
  
    const observer = new IntersectionObserver(callback, options);
  
    targetElements.forEach((element) => observer.observe(element));
  
    return () => observer.disconnect();
  }, [targetElemtns, options]);
  
  return activeSection;
  };

채용 페이지 SEO (동적 사이트맵 생성)

• 서버사이드 렌더링을 통해 동적으로 sitemap.xml을 생성하였습니다.

  // sitemap.xml.tsx
  
  const SitemapPage = () => {
    return null;
  }
  
  export const getServerSideProps = async (context) => {
    // ...
    const sitemap = generateSiteMap({
      siteUrl,
      changeFreq,
      priority,
    });
  
    context.res.setHeader('Content-Type', 'text/xml');
    context.res.write(sitemap);
    context.res.end();
  
    return { props: {} };
  }

💡 여러 클라이밍장의 세팅 일정을 한눈에 확인할 수 있도록 정보를 제공합니다. 또한, 사용자가 특정 클라이밍장을 방문했을 때, 이후 언제 다시 방문해야 해당 클라이밍장의 모든 섹터가 새롭게 바뀌는지 확인할 수 있습니다.

기술 스택

프론트엔드:

• Next.js:
  • 정적 페이지 구성
  • 서버 컴포넌트
• Tailwind CSS

데이터베이스 및 인증:

• Supabase: 데이터베이스와 인증 관리를 위해 사용되었습니다.

기타 도구 및 서비스:

• Git: 버전 관리를 위해 사용되었습니다.
• Vercel: 배포 플랫폼으로 사용되었습니다. Vercel을 통해 프로젝트를 배포하고 관리하였습니다.

개발 과정

1. 프로젝트 기획 단계

   • 요구사항 분석: 클라이밍 세팅 정보를 필요로 하는 사용자들의 니즈를 파악하기 위해 인스타그램 부계정을 개설하여 세팅 정보를 정리해 올리는 작업을 했습니다. 이를 통해 세팅 정보에 대한 수요가 있다는 것을 확인했습니다.
   • 최소 기능 제품(MVP) 제작: 핵심 기능만 빠르게 제작하여 사용자 피드백을 받아 제품을 개선해 나가기로 했습니다.

2. 프론트엔드 개발 과정

   • 컴포넌트: 새로운 개념인 서버 컴포넌트 및 액션에 대한 학습을 진행하며, 컴포넌트를 개발했습니다.
   • 퍼블리싱: 모바일 디바이스를 기준으로 사용이 편리하도록 했습니다.
   • API: Supabase와 통합하여 데이터베이스와 통신하는 API를 개발했습니다. 서버 컴포넌트에서 주로 요청을 보내고, 클라이언트 컴포넌트에서는 route handler를 통해 데이터 요청을 처리했습니다.

3. 데이터베이스 및 인증 설정 과정

   • 데이터베이스 설계: 클라이밍장 브랜드, 클라이밍장, 클라이밍장 섹터, 클라이밍장 섹터 세팅 히스토리로 테이블을 나누어 정의했습니다. 데이터 모델링 과정에서 테이블 간 관계 설정을 고려했습니다.
   • 인증 설정: 카카오톡 로그인 작업은 처음이었지만, 공식 문서를 참고하여 어렵지 않게 구현했습니다. 인증 흐름을 설계하고 보안을 고려한 설정을 적용했습니다.

4. 배포 과정

   • 배포: Vercel을 통해 배포를 진행했습니다. Vercel 환경에서의 프로덕션 빌드 최적화와 환경 변수 설정을 고려했습니다.
   • 성능 모니터링: Vercel에서 제공하는 Analytics와 SpeedInsight를 통해 서비스의 성능 및 지표를 확인했습니다. 페이지 로딩 시간, 사용자 행동 분석 등의 메트릭을 모니터링하고, 이를 통해 성능 개선을 위한 인사이트를 얻었습니다.

결과 및 성과

사용자 피드백:

• 실제 사용자 유입: 인스타그램 계정을 통해 프로젝트를 공개하였고, 실제 사용자들이 유입되었습니다. 사용자들은 이 서비스가 필요했던 것임을 피드백을 통해 확인했습니다.

기술적 성과:

• Next.js 14(app router) 및 서버 컴포넌트 이해: 최신 버전의 Next.js에 대한 깊이 있는 이해를 통해 서버 컴포넌트를 활용하여 데이터를 효율적으로 처리하고, 성능을 최적화하는 방법을 익혔습니다.
• 성능 최적화: FCP, LCP 시간을 개선하기 위해 다양한 성능 최적화 작업을 수행하였고, 이를 통해 사용자 경험을 향상시켰습니다.
• Supabase 이해: Supabase를 활용한 데이터베이스 관리와 인증 설정을 통해 데이터베이스 작업의 효율성을 높였습니다.

배운점 및 개선할 점:

• 성능 최적화: 실 사용자들을 위한 성능 측정 및 개선 작업의 중요성을 깨달았습니다. 특히, 서버 컴포넌트 렌더링 시 데이터 페칭 과정에서의 최적화 필요성을 인식하고 이를 개선했습니다.
• 사용자 경험(UX): 방문일 입력의 허들을 낮추기 위한 방법을 고민하며, 사용자 친화적인 인터페이스를 설계할 필요성을 배웠습니다.

💡 예비 신혼부부의 이야기를 담은 풍성한 모바일 청첩장을 만들어, 초대 받는 사람들이 결혼식 주인공들에 대해 깊게 이해하고 마음 깊이 축하할 수 있도록 돕는 서비스입니다.

2023.12 ~ (진행 중) https://bora-n-maria.vercel.app/

기술 스택

프론트엔드:

• Next.js:
  • 동적 메타 데이터 구성: 청첩장 별 메타 데이터를 동적으로 구성하여 각 청첩장이 적절한 메타 정보를 갖추도록 했습니다.
  • 정적 페이지 구성: 제작된 청첩장 페이지들을 정적 페이지로 구성하여 성능을 최적화하였습니다.
  • 서버 컴포넌트: 서버 컴포넌트를 활용하여 성능을 최적화하였습니다.
  • 서버 액션: 캐싱 관리를 통해 성능을 최적화하였습니다.
• Tailwind CSS: 스타일링을 위해 사용되었습니다.
• react-hook-form: 복잡한 폼을 효율적으로 관리하기 위해 사용되었습니다.
• Kakao API: 예식장 검색 및 지도 노출을 위해 사용되었습니다.
• 이미지 최적화: 클라이언트에서 업로드한 이미지를 서버에 보내기 전에 이미지 사이즈 및 화질, 확장자 변경 등을 통해 최적화하였습니다.

데이터베이스 및 인증:

• Supabase: 데이터베이스와 인증 관리를 위해 사용되었습니다.

기타 도구 및 서비스:

• Git: 버전 관리를 위해 사용되었습니다.
• Vercel: 배포 플랫폼으로 사용되었습니다. Vercel을 통해 프로젝트를 배포하고 관리하였습니다.

주요 기능

1. 모바일 청첩장 관리
   • 스토리 및 게시물 관리
   • 결혼식장 장소 검색 및 약도 제공
2. 메타 정보 입력
   • 예비 신혼부부의 정보 등을 통해 청첩장이 공유되었을 때, 메타데이터로 활용할 수 있도록 하였습니다. 이를 통해 청첩장이 더 많은 사람들에게 효과적으로 전달될 수 있습니다.

개발 과정

1. 프로젝트 기획 단계:
   • 서비스 정의: 어떤 서비스를 왜 만들고 싶은지 정의하는 과정으로 시작하였습니다. 시장에 있는 다양한 모바일 청첩장 서비스들을 살펴보고 구조를 분석하였습니다.
   • 노션 정리: 노션을 통해 분석한 내용을 정리하면서 프로젝트를 구체화해 나갔습니다.
   • 사용자 인터뷰: 결혼한 지인들에게 인터뷰를 진행하여 청첩장 서비스에 대한 피드백을 받았고, 이를 기획에 반영하여 보강하였습니다.
   • UI/UX 디자인 설계: Figma를 사용하여 UI/UX 디자인을 설계했습니다. 주로 PC에서 모바일 청첩장을 제작하는 경우가 많기 때문에, PC를 기준으로 디자인을 설계했습니다. 완성된 디자인은 다시 피드백을 받아 수정하였습니다.
2. 프론트엔드 개발 과정:
   • 컴포넌트 개발: 사용자가 입력한 내용이 결과물에 바로 적용되도록 중점을 두어 컴포넌트를 설계했습니다. 다양한 콘텐츠를 업로드해야 하기 때문에 폼 관리에도 신경을 많이 썼습니다.
   • 퍼블리싱: Tailwind CSS를 사용하여 반응형 디자인을 적용하고 스타일링을 진행했습니다.
   • API 통합: Supabase와 통합하여 데이터베이스와 통신하는 API를 개발했습니다. 서버 컴포넌트를 활용하여 성능을 최적화하고, 캐싱 관리 기능도 구현했습니다.
3. 데이터베이스 및 인증 설정 과정:
   • 스토리지: 업로드한 이미지의 저장을 위해 Supabase의 스토리지를 사용했습니다.
   • 데이터베이스: 스토리, 게시물, 결혼식장 콘텐츠 모두 이미지를 기반으로 이루어지기 때문에, 이미지를 위한 테이블을 공용으로 구성하고, 각 테이블과의 연결을 위한 링크 테이블을 통해 관계를 설정했습니다. 이로써 데이터의 무결성을 유지하고 효율적인 데이터 관리를 구현했습니다.
4. 배포 과정:
   • 배포: Vercel을 통해 프로젝트를 배포했습니다. Git을 이용하여 버전 관리를 하였습니다.

결과 및 성과

성과 및 배운 점:

1. 데이터베이스 설계:

   • 청첩장을 구성하는 요소인 기본 정보, 스토리, 게시물, 예식장 등을 효율적으로 관리하기 위해 데이터베이스 설계에 많은 고민을 하였습니다. 데이터베이스의 구조가 서비스에 큰 영향을 미친다는 교훈을 얻었으며, 이를 통해 작업을 시작하기 전에 아키텍처에 대한 충분한 고민이 반드시 필요함을 느꼈습니다.

2. 복잡한 폼 관리:

   • 복잡한 폼을 효율적으로 관리하기 위해 컴포넌트를 설계하는 것이 중요함을 배웠습니다. 여러 필드를 포함한 폼을 처리하면서, 상태 관리와 유효성 검사를 효과적으로 구현하는 방법을 익혔습니다. react-hook-form을 활용하여 폼 상태를 관리하고, 유연하게 확장할 수 있는 컴포넌트를 작성하는 기술을 향상시켰습니다.

3. 이미지 최적화:

   • Next.js의 Image 컴포넌트를 통해 이미지를 최적화하는 방법을 이전에 사용했으나, 이번 프로젝트에서는 클라이언트에서 업로드한 이미지를 서버에 보내기 전에 최적화하여 네트워크 통신 간 성능을 개선할 수 있음을 알게 되었습니다. 이를 통해 이미지 사이즈, 화질, 확장자 등을 최적화하는 방법을 이해하고 적용할 수 있었습니다.

개선할 점:

1. 모바일 기기 대응:
   • 처음에는 PC를 기준으로 레이아웃을 구성하였으나, 반응형 레이아웃을 활용하여 모바일 기기에도 대응할 수 있도록 구조를 변경할 필요성을 느꼈습니다. 이를 통해 더 많은 사용자들에게 최적의 사용자 경험을 제공할 수 있도록 개선하려고 합니다.
2. 성능 개선:
   • 완성된 모바일 청첩장을 방문했을 때, 더 좋은 사용자 경험을 제공하기 위해 최적화 작업을 통해 성능을 개선할 계획입니다. 로딩 속도와 인터랙티브 성능을 향상시켜 사용자 만족도를 높이고자 합니다.

평가 기준

• 기능 구현

개요

• 메시지 발송 플랫폼 구현

요구사항

필수 사용 언어 및 라이브러리

• TypeScript, React
• yarn
• Emotion

디자인

• 제공한 피그마 파일을 참고하여 레이아웃을 구성합니다.

기능 구현

• 페이지별 요구사항

  1. 로그인
     • 사용자의 입력 값에 대해 유효성 검증을 진행합니다.
     • 입력 값이 유효하지 않은 경우, 아래 작업을 수행하도록 구현합니다.
       • 유효하지 않은 Input 테두리가 빨간색으로 변합니다.
       • 유효하지 않은 Input으로 Focus 됩니다.
     • 로그인에 성공한 경우, 서비스 페이지로 이동합니다.
  2. 회원가입
     • 사용자의 입력 값에 대해 유효성 검증을 진행합니다.
     • 입력 값이 유효하지 않은 경우, 아래 작업을 수행하도록 구현합니다.
       • 유효하지 않은 Input 테두리가 빨간색으로 변합니다.
       • 유효하지 않은 Input으로 Focus 됩니다.
     • 회원가입에 성공한 경우, 로그인 페이지로 이동합니다.
  3. 서비스(메시지 발송)
     • 메시지 발송 폼을 구현합니다.

• 별도의 요구사항이 없는 것은 지원자가 판단하여 개발합니다.

구현 내용

프로젝트 구조

/src
    /api (backend API 관리)
    /components (공용 컴포넌트)
    /contexts (공용 컨텍스트)
    /hooks (공용 훅)
    /icons
    /pages (라우트 기본 단위를 페이지로 설정)
    /schemas (zod 스키마)
    /styles
    /types
    /utils
    main.tsx

라우팅 (w. react-router)

구현해야 하는 페이지는 총 3개

• 회원가입 /auth/signup
• 로그인 /auth/login
• 서비스 /

최근에는 주로 Nextjs를 사용했었기 때문에, 페이지 라우팅을 위해 react-router를 사용하는 것은 익숙하진 않았었어요.

공식 문서를 살펴보면서, 라우팅을 위한 작업을 진행했습니다.

• 프로젝트 구조 NextJS의 페이지 기반 라우팅 방식이 익숙했기에, 이 방식을 살려서 구조를 설계하고자 했습니다.

    디렉토리
    /src
        /pages
            page.tsx
            /messages
                page.tsx
            /auth
                /login
                    page.tsx
                /register
                    page.tsx

• createBrowserRouter 공식 문서 상, 웹 서비스의 라우팅을 위해 권장하는 방식인 createBrowserRouter를 사용했습니다.

  // main.ts
  
  const router = createBrowserRouter([
    {
      path: "/",
      element: <RootLayout />,
      children: [
        {
          path: "/",
          element: <RootPage />,
        },
        {
          path: "/messages",
          element: <MessagesPage />,
        },
      ],
    },
    {
      path: "/auth/login",
      element: <LoginPage />,
    },
    {
      path: "/auth/register",
      element: <RegisterPage />,
    },
  ]);

• layout RootPage와 MessagesPage에서 공통으로 사용하는 레이아웃 및 로직이 존재했기에, 이를 위해 RootLayout을 구성했습니다.

  • 공통 로직 로그인 여부를 체크하고, 로그인이 되어있지 않다면 로그인 페이지로 리다이렉트합니다.

    // layout.tsx
    
    const RootLayout = () => {
        // 로그인 체크
      return (
        <LayoutWrapper>
          <Sidebar />
          <Outlet />
        </LayoutWrapper>
      );
    };

공용 컴포넌트 (FormField)

로그인, 회원가입, 메시지 발송 등 여러 폼을 구현해야 했기 때문에, 폼의 구성요소를 컴포넌트화하여, 재사용할 수 있도록 했습니다.

공용 컴포넌트는 shadcn/ui 를 참고하여 구조화했습니다.

• 사용 예제

    <form>
        <FormField>
            <FormFieldLabel>라벨</FormFieldLabel>
            <Input
                ref={inputRef}
                value={value}
                onChange={onChange}
                onBlur={onBlur}
                disabled={disabled}
                name={name}
            />
            <FormFieldError>{error.message}</FormFieldError>
        </FormField>
    </form>

• 구현 상세 내용

  • FormField label과 input을 연결할 수 있는 htmlfor 값을 Context API를 통해 관리합니다.

  • Input react-hook-form 을 활용했을 때, 해당 컴포넌트에 ref를 전달하기 때문에 이를 위해 forwardRef를 사용하여 컴포넌트를 정의했습니다.

  • FormFieldError 에러 메시지를 렌더링합니다.

복잡한 폼 관리

폼을 관리하기 위해 react-hook-form 라이브러리를 사용했습니다.

각 필드의 유효성을 검증하기 위해서 zod 와 @hookform/resolver 라이브러리를 활용했습니다.

• 구현 예시

    const formSchema = z.object({
        header: z.string().max(100, "헤더는 최대 100자까지 가능합니다"),
        recipents: z.array(z.object({ phoneNumber: z.string() })).min(1, "수신자를 입력해주세요"),
    });
  
    type FormValues = z.infer<typeof formSchema>;
  
    const MessageForm = () => {
        const form = useForm<FormValues>({
            resolver: zodResolver(formSchema), // 유효성을 검증합니다.
            defaultValues: {
                header: "",
                recipents: [{ phoneNumber: "" }],
            },
        });
  
        // ...
  
        return (
            <form>
                <Controller
                    control={form.control}
                    name="header"
                    render={({ field, fieldState }) => (
                        <FormField>
                            <FormFieldLabel>헤더</FormFieldLabel>
                            <Input {...field} hasError={!!fieldState.error} />
                            <FormFieldError>{fieldState.error?.message}</FormFieldError>
                        </FormField>
                    )}
                />
            </form>
        );
    };

API 에러 핸들링 (로그인, 회원가입)

백엔드로의 요청에 대한 응답을 성공과 실패 두가지 케이스로 나누어, 구조화하였습니다. 에러가 발생했을 때, 어떤 데이터와 관련이 있는지도 전달하여 해당 필드에 에러를 표현하였습니다.

// auth.ts

type AuthAPIResponse<D = unknown, T = unknown> = 
  | {
      success: true;
      data: D;
    }
  | {
      success: false;
      target: T;
      message: string;
    }

const login = async (values: {
  email: string;
  password: string;
}): Promise<AuthAPIResponse<unknown, Path<LoginInput>>> => {
  const url = `${API_DOMAIN}/api/auth/signin`;
  const res = await fetch(url, {
    method: "POST",
    body: JSON.stringify(values),
    headers: {
      "Content-Type": "application/json",
    },
  });

  const isSuccess = res.ok;

  if (isSuccess) {
    const data = await res.json();
    return {
      success: true,
      data,
    };
  }

  switch (res.status) {
    case 400: {
      const data = await res.json();
      // 백엔드 응답에 따른 분기처리
      const isInValidEmail = data.detail === "Invalid email";
      const isInValidPassword = data.detail === "Invalid password";

      if (isInvalidEmail) {
        return {
          success: false,
          target: "email",
          message: "가입된 이메일이 아닙니다.",
        };
      }

      if (isInvalidPassword) {
        return {
          success: false,
          target: "password",
          message: "비밀번호가 일치하지 않습니다.",
        };
      }

      throw new Error("알 수 없는 오류가 발생했습니다.");
    }

    default: {
      throw new Error("알 수 없는 오류가 발생했습니다.");
    }
  }
}

해당 API 메서드를 호출하는 컴포넌트에서는 다음과 같이 에러를 처리할 수 있었습니다.

const form = useForm(...);

const onSubmit = async (values) => {
  try {
      const res = await login(values);

    const isSuccess = res.success;

    if (!isSuccess) {
      form.setError(
        res.target,
        {
          type: "",
          message: res.message,
        },
        { shouldFocus: true },
      );
    }

    // ...
  } catch (e) {
    if (e instanceof Error) {
      alert(error.message);
    } else {
      console.error(error);
    }
  }
};

추가한 라이브러리

• react-router 페이지 라우팅

• zod 유효성 검증(form)

• react-hook-form form 관리

• @hook-form/resolver zod를 활용하여, react-hook-form의 유효성 검증을 수행하기 위함

• react-hot-toast 토스트

어려웠던 부분

emotion

기존에는 주로 tailwind를 사용하여, 스타일링을 진행했었다 보니 emotion을 통해 스타일링을 하는 것이 익숙치 않아, 고민되는 부분이 있었습니다.

• css, styled, Global 등 스타일링을 할 수 있는 방법이 다양하게 있어, 어떤 방식으로 스타일링을 진행할 것인가?

• 코드 가독성을 저해하지 않는 방법은 무엇일까?

• 스타일링을 위한 코드가 컴포넌트 구조 혹은 로직에 대한 이해를 위한 가독성을 떨어뜨리지 않도록 하려면?

• 스타일이 선언된 위치와 해당 스타일이 적용되는 요소 간, 간격이 멀지 않도록 하고자 함.

• 재사용 하지 않는 스타일은 어디에 정의할 것인가?

• 재사용 가능한 스타일 관련 코드는 어떻게 관리할 것인가?

• Global 을 사용하여, 해당 컴포넌트의 하위 컴포넌트에 대해 일관된 스타일을 적용하도록 시도해 봤지만, 이 방법은 스타일링 코드와 적용되는 부분 간 거리가 떨어져 있기에 스타일을 수정하기 위해서 찾기 힘들 수 있으며, 해당 코드가 어디에 영향을 미치는지 이해하기 어려울 수 있기에 사용하지 않는 것이 좋겠다고 판단.

회고 목적: 시간을 들인 과제를 회고하면서, 개선점을 찾아보기 과제에 대한 세부 내용은 생략되었습니다.

평가 기준

• 기능 구현
• 관심사 분리
• 정적 타입
• hook 함수

요구사항

필수 사용 언어 및 라이브러리

• Typescript
• Nextjs
• tailwind

기능

• 유저 row 무한 스크롤
• 유저 id 복사

구현 내용

무한 스크롤을 위한 상태 관리

방식 고민

1. 서버 상태 관리를 위한 라이브러리(tanstack query)를 사용하는 게 좋을까? 사용하지 않는 것으로 함

   이전 회사에서 사용했던 방법은 react-query의 infiniteQuery를 사용하는 것이었다.

   클라이언트 사이드에서 데이터를 가져오는 방식은 첫 페이지를 렌더링할 때 값이 없는 상태가 되었다. 이 문제는 페이지 컴포넌트를 서버에서 렌더링할 때, 서버사이드에서 prefetch를 수행하고, hydrate 시 그 데이터를 기본 값으로 사용하는 방식을 통해 해결할 수 있었다.

   이전 회사는 NextJS 12 버전을 사용하고 있었고, 이번 과제는 NextJS 14 (app router)였기에 동일한 방식을 적용할 수는 없었다.

   우선, react-query를 사용해야 하는지를 생각해보았다. 현재는 tanstack-query 라이브러리인 해당 라이브러리는 서버 상태를 관리하는 데 유용한 라이브러리이다.

   유저의 데이터만 다루면 되었기에, 서버 상태를 관리하기 위한 라이브러리까지 추가하진 않아도 될 것이라고 생각했다. 또한, 과제를 진행하는 입장에서는 라이브러리를 사용하면, 안좋게 보진 않을까? 싶기도 했기 때문에…

   서버 상태 관리는 라이브러리를 사용하지 않고, 직접 구현하는 것으로 했다.

2. 로컬 상태 vs 전역 상태

    <Page>
        <Filter />
        <DataSection />
    </Page>

   컴포넌트 구조를 위와 같이 설계했기에, Filter와 DataSection 모두 사용하는 데이터는 각 컴포넌트 상위에서 관리해야 했다.

   Page 컴포넌트는 서버 컴포넌트로 구현하려고 했기 때문에(클라이언트 컴포넌트로 변경하면, app router의 서버 컴포넌트 이점을 아무것도 살리지 못할 것이라고 생각했음) 로컬 상태가 아닌 전역 상태로 관리하고자 했다.

3. 전역 상태를 관리하기 위한 방법

   서버 상태를 관리하기 위해 라이브러리를 설치하지 않았는데, 전역 상태를 관리하기 위해 라이브러리를 추가하는 것은 이상했기에 전역 상태도 직접 구현하고자 했다.

   nextjs에서는 서버 컴포넌트와 클라이언트 컴포넌트를 조합하여, 효율적으로 렌더링하기 위해 composition pattern을 소개하고 있고, ContextAPI의 Provider를 활용하는 방식 역시 동일한 패턴이기에 ContextAPI를 활용하여 데이터를 관리하는 것으로 결정했다.

구현

무한 스크롤 구현을 위해 필요한 로직은 Context 내부에 담아, 관심사를 분리하고자 했다.

// DataContext.tsx
'use client';

type DataContextType = {
    data: Data[];
    setData: (data: Data[]) => void;
    loadMoreData: () => void; // 다음 데이터를 가져오기
    isFetching: boolean;      // 데이터 로딩 중
    hasMore: boolean;         // 추가로 가져올 데이터가 있는지 여부
}

const DataContext = createContext<DataContextType | null>(null);

const DataContextProvider = ({
    initialData, // 렌더링시 필요한 초기 값
    children,    // compositionPattern
}) => {
    const [data, setData] = useState([initialData]);
    const [offset, setOffset] = useState(10);
    const [isFetching, setIsFetching] = useState(false);
    const [hasMore, setHasMore] = useState(true);

    const loadMoreData = async () => {
        if (isFetching || !hasMore) return;

        setIsFetching(true);
        const newData = await getData(offset, 10);

        setData(prev => [...prev, ...newData]);
        setOffset(prev => prev + 10);
        setIsFetching(false);
        setHasMore(newData.length === 10);
    };

    return (
        <DataContext.Provider
            value={{
                data,
                setData,
                loadMoreData,
                isFetching,
                hasMore,
            }}
        >
            {children}
        </DataContext.Provider>
    )
};

// useDataContext.ts

const useDataContext = () => {
    const contextValue = useContext(DataContext);

    if (!contextValue) {
        throw new Error('useDataContext는 DataContextProvider 내부에서 사용되어야 합니다.');
    }

    return contextValue;
}

초기 데이터 문제는 서버 컴포넌트가 서버에서 렌더링될 때 가져온 후, Provider로 값을 넘겨주는 것으로 해결할 수 있었다.

// page.tsx

export default async function Home() {
    const data = await getData(0, 10);

    return (
        <DataContextProvider initialData={data}>
            <Filter />
            <DataSection />
        </DataContextProvider>
    )
}

데이터를 사용하여, 대시보드에 렌더링

// DataSection.tsx

const DataSection = () => {
    const { data, loadMoreData, isFetching, hasMore } = useDataContext();

    // ...
    return (
        <>
            {data.map...}
            {isFetching && <LoadingSkeleton />}
            {hasMore && <div ref={loader}>...</div>}
        </>
    )
}

무한 스크롤을 위한 추가 데이터 요청 트리깅

스크롤을 내려, 대시보드 최하단까지 스크롤이 되었을 때 추가로 데이터를 가져오는 로직을 구현하기

방식

Intersection Observer API를 활용하여, 최하단까지 스크롤이 되었음을 확인하고 이때 다음 데이터를 불러오도록 함

구현 과정

1. 리스트 최하단에 “더보기” 버튼을 만들어, 데이터 추가 요청과 업데이트가 제대로 이루어지는지 확인
2. 더보기 버튼 위치에 Intersection Observer를 적용한 요소를 만들어, 해당 요소가 화면에 노출되었을 때 데이터를 추가로 불러오도록 함

구현

// DataSection.tsx

const DataSection = () => {
    // ...

    const loader = useRef<HTMLLIElement>(null);

    useEffect(() => {
        const intersectionObserverOptions: IntersectionObserverInit = {
            root: null,
            rootMargin: "0px",
            threshold: 1.0,
        };

        const observer = new IntersectionObserver((entries) => {
            entries.forEach((entry) => {
                if (entry.isIntersecting) {
                    loadMoreData();
                }
            });
        }, intersectionObserverOptions);

        if (loader.current) {
            observer.observe(loader.current);
        }

        return () => {
            observer.disconnect();
        };
    }, [loadMoreData]);

    return (
        <>
            {data.map...}
            {isFetching && <LoadingSkeleton />}
            {hasMore && <div ref={loader}>...</div>}
        </>
    )
};

id 복사

버튼을 눌렀을 때, 해당 유저의 아이디를 클립보드에 복사하기 위해 Navigator.clipboard.writeText 메서드를 활용했다.

const copyToClipboard = async (text: string) => {
    try {
        await navigator.clipboard.writeText(text);
        alert('복사되었습니다.');
    } catch (e) {
        alert('복사에 실패했습니다.');
    }
}

추가한 라이브러리

zod

추가한 이유

json-server로 API 요청을 보내, 데이터를 가져올 때 해당 데이터에 대한 검증을 위한 데이터 검증 레이어를 추가하기 위해서.

사용 예시

// getData.ts

const dataSchema = z.object({
    id: z.number(),
    name: z.string(),
    // ...
});

const getData = async (offset: number, limit: number) => {
    const res = await fetch(...);

    // ...

    const data = await res.json();

    try {
        return dataSchema.array().parse(data);
    } catch (e) {
        console.error('screening data 구조가 올바르지 않습니다.', e);
        return [];
    }
}

dayjs

추가한 이유

날짜 및 시간 포맷팅

대체 가능한 라이브러리로는 date-fn, moment 등이 있음. 그 중 dayjs를 선택한 이유는 사이즈가 가장 작고, 높은 다운로드 수 & 스타 수.

개선할 점

관심사 분리

Intersection Observer API

Intersection Observer API 관련 로직을 DataSection.tsx에 두었는데, 이는 훅이나 컴포넌트로 분리시키는 것이 더 좋았을 것 같다.

// useIntersectionObserver.ts

type Props = {
  callback: IntersectionObserverCallback;
  options?: IntersectionObserverInit;
};

const DEFAULT_OPTIONS: IntersectionObserverInit = {
  root: null,
  rootMargin: "0px",
  threshold: 0,
};

export const useIntersectionObserver = ({
  options = DEFAULT_OPTIONS,
  callback,
}: Props) => {
  const observer = useRef<IntersectionObserver | null>(null);

  useEffect(() => {
    const handleIntersect = (
      entries: IntersectionObserverEntry[],
      observer: IntersectionObserver
    ) => {
      if (callback) {
        callback(entries, observer);
      }
    };

    observer.current = new IntersectionObserver(handleIntersect, options);

    return () => {
      if (observer.current) {
        observer.current.disconnect();
      }
    };
  }, [callback, options]);

  const observe = (element: Element) => {
    if (observer.current && element) {
      observer.current.observe(element);
    }
  };

  const unobserve = (element: Element) => {
    if (observer.current && element) {
      observer.current.unobserve(element);
    }
  };

  return {
    observe,
    unobserve,
  };
};

상태 관리

라이브러리 활용하기

Context API가 아닌 다른 상태관리 라이브러리를 사용하는 것이 더 나을 수 있을 것 같다.

해당 회사의 채용 공고를 보면, 'Zustand, Recoil, Redux 등 상태 관리 개발 경험이 있으신 분'이 명시되어 있는데 단순한 상태를 관리한다는 이유로 Context API를 사용하는 것은 채용 공고에 명시되어 있는 상태 관리 방식을 어필할 수 없게 되는 부분도 있기 때문.

여러 암장들을 다니면서 운동을 하는데, 방문한 날 그 암장이 세팅 중이라면 뭔가 손해보는 기분이 들었었다. 보통 4~5개의 섹터로 구분되는데, 1개 섹터가 탈거되어 있으면... ㅠ

세팅 중인 암장을 피하기 위해서 나는 사람들과 함께 클라이밍 약속을 잡을 때, 그 암장이 세팅 중인지 인스타를 통해 확인하는 버릇이 생겼다. 대부분 암장은 각각 인스타 계정을 운영하고 있어서, 그곳에서 세팅 정보도 확인할 수 있었는데, 여러 암장을 후보지로 두고 갈 곳을 찾는 내 입장에서는 하나하나 들어가야 하는 게 귀찮고 불편했었다.

불편한 이 지점이, 내가 뭔가를 해볼 수 있는 포인트라고 생각했다. "사람들이 많이 방문하는 암장의 이번주 세팅 일정을 알려주는 것"

이 문제를 해결하기 위해, 나는 서비스를 만들지 않았다. 나는 세팅 일정을 올리는 인스타 부계정을 만들었다.

서비스를 만들지 않고, 인스타그램 부계정을 만든 이유는

1. 클라이밍을 활발히 하고 있는 사람들은 주로 인스타그램을 이용한다. 따라서, 해당 플랫폼 내에서 정보를 얻는 것이, 인스타에서 내가 만든 서비스로 사람들을 오게 만드는 것보다 훨씬 쉬울 것
2. 이번주 세팅 일정은 인스타그램 게시물로 정보 전달이 충분히 가능함

나는 인스타그램 부계정을 먼저 운영해보고, "세팅 일정"을 확인하고자 하는 수요가 있는지 파악하면서 서비스가 필요한 지점을 찾아보는 중이다.

--

혹시 클라이밍을 좋아하는 velog 분들이 있다면, 한번 구경오세요 :) @de.gu.r.r

이전부터 클라이밍을 주제로 서비스를 만들고 싶었고, 실제로 잠깐 진행했던 적도 있었다. 그때는 회사에 다니고 있기도 했어서, 회사 사람들을 모아서 진행했었는데 방향이 모호했다보니 완성하기 전에 중단되었었다.

단순히, 만들고 싶다라는 동기 만으로는 서비스를 만들고 싶지 않았기에 당시에 중단하기로 한 판단은 잘했다고 생각한다.

서비스는 모름지기 쓰임이 있어야 하고, 쓰임이 곧 그 서비스의 가치를 증명한다고 생각하기에 만들고 싶은 주제를 가지고 제대로 쓰일 수 있을 것 같은 서비스를 만들고 싶었다.

운동을 기록하고 싶은 사람이 많기 때문에, 클라이밍 역시 운동을 기록하는 서비스가 많이 등장하는데 나는 그 부분은 충분히 인스타그램으로 대체가 될 수 있다고 생각했었다.(초창기에 만들고 싶었던 서비스도 운동 기록 기능을 포함하고자 했었다.)

그렇게 시간이 흐르고, 백수가 되고 평일 낮에 클라이밍을 갈 수 있게 되면서 개인적인 니즈가 생겨나게 된다. '암장의 세팅 날짜가 언제지? 그 날은 피해서 가고 싶은데'였다. 클라이밍장은 여러개의 벽으로 구성되어 있고, 보통 매주 혹은 격주로 일부 벽을 새롭게 세팅을 하는데 하루에서 이틀정도 소요가 된다. 클라이밍장에 방문했는데, 해당 지점이 세팅을 하고 있다면 그 벽은 사용하지 못하기 때문에 뭔가 아쉬웠다.

그래서 나는 '서비스를 만들지 않았다'.

새롭게 서비스를 만드는 것 만이 능사는 아니었기에, 더 쉽고 접근성이 높은 방안을 생각해 보았다.

이전부터 만들고 싶었던 인스타그램 부계정. 하지만, 아주 멋들어진 무브를 뽑내긴 아직 클린이라고 생각했기에 본계에만 게시물을 올리며 망설였던 부계정.

나는 클라이밍장 세팅 정보를 모으는 부계정을 만들기로 했다. 그리고 어느덧 세번째 게시물을 올리고 있다. 전혀 모르는 사람들이 게시물에 좋아요를 눌러주는 것을 행복해하며, 그게 곧 그 게시물의 가치라고 생각하며 하나씩 꾸준히 올려보려고 한다.

게시물을 준비하며, 정보를 모으고 있던 중 '서비스'로 만들고 싶은 주제가 생각났고 그렇게 서비스 제작에 착수했다. (2편으로...)

--

혹시 클라이밍을 좋아하는 velog 분들이 있다면, 한번 구경오세요 :) @de.gu.r.r

인스타그램 레이아웃의 모바일 청첩장에는 스토리/게시물에 이미지가 필수였다. 이미지의 용량이 크면 청첩장을 만들 때에도 사용자 경험이 좋지 않고, 청첩장을 볼 때에도 경험이 좋지 않을 것이기에 이미지의 용량을 줄이는 과정이 필요했다.

이미지 압축을 어디에서 해야 할까?

프로젝트는 NextJS와 supabase로만 구성되어 있기에 이미지 압축을 어디에서 진행할 것인지에 대한 선택지는 두개 였다.

1. 클라이언트
2. 서버(NextJS)

용량이 큰 이미지가 네트워크 통신을 통해 전달될 때의 시간을 줄이고 싶었던 것이기 때문에 클라이언트에서 이미지 업로드 직후 '이미지 압축' 작업을 하고, 이후에 압축한 이미지를 서버로 전달하도록 하고자 했다.

이미지 압축은 어떻게 할까?

어떻게 이미지의 용량을 줄일 수 있을까?

1. 확장자를 변경한다.
2. 이미지 크기를 줄인다.

이미지 확장자에 따른 차이

ChatGPT에게 이미지 확장자에 따른 차이를 물어봤고, WebP 방식으로 결정했다.

이미지 포맷마다 고유의 특성과 압축 방식을 가지고 있으며, 이는 파일 크기와 이미지 품질에 직접적인 영향을 미칩니다. 주로 고려할 수 있는 확장자는 JPEG, PNG, WebP, AVIF입니다.

1. JPEG 손실 압축 방식 투명도 미지원

2. PNG 비손실 압축 방식 투명도 지원

3. WebP 손실 압축 방식 (JPEG에 비해 높은 압축 효율) 투명도 지원 브라우저 호환성 이슈 (대부분의 현대 브라우저는 가능)

4. AVIF 손실, 비손실 압축 방식 (WebP에 비해 높은 압축 효율) 투명도 지원 브라우저 호환성 이슈 (WebP에 비해 지원하는 브라우저가 적음)

• 선택 가이드 웹 호환성 중요: JPEG 또는 PNG 호환성과 압축률의 균형: WebP 최고의 압축률: AVIF

해보자

압축 로직 플로우

input=file 에 파일을 올렸을 때, 이미지 압축을 수행한다. 이미지 압축은 canvas를 이용한다. 이미지 압축이 완료되면, 압축한 이미지를 supbase에 업로드한다.

압축 과정

1. file을 접근 가능한 dataUrl로 변환한다.
2. dataUrl을 통해 Image 객체를 생성한다.
3. canvas에 Image를 그린다. (이미지 크기 조정)
4. canvas를 blob으로 변환한다. (이미지 확장자 변경 및 품질 조정)
5. blob을 supabase에 업로드한다.

코드를 짜보자

const compressImageAndUploadFile = (file: File) => {
  // 1. file을 접근 가능한 dataUrl로 변환한다.
  const fileReader = new FileReader();
  fileReader.onload = () => {
    const dataUrl = reader.result;

    if (!dataUrl || typeof dataUrl !== 'string') {
      return;
    }

    // 2. dataUrl을 이용해, image 객체를 생성한다.
    const image = new Image();
    image.onload = () => {
      // 3. canvas를 이용해, 이미지를 압축한다.
      const canvas = document.createElement("canvas");

      // 3-1. 이미지의 최대 크기를 제한한다.
      const MAX_HEIGHT = 1024;
      const MAX_WIDTH = 1024;
      // 3-2. 이미지 크기를 줄일 때, 비율을 계산한다.
      const ratio = Math.min(MAX_WIDTH/image.width, MAX_HEIGHT/image.height, 1);

      const newWidth = image.width * ratio;
      const newHeight = image.height * ratio;
      canvas.width = newWidth;
      canvas.height = newHeight;

      const canvasContext = canvas.getContext("2d");
      if (!canvasContext) {
         throw new Error("Cannot get canvas context");
      }

      canvasContext.drawImage(image, 0, 0, newWidth, newHeight);

      // 4. canvas를 blob으로 변환한다.
      // 확장자: webp
      // 품질: 0.7
      canvas.toBlob(blob => {
        // 5. 변환한 blob을 file로 변환한 후 supabase에 업로드한다.
        if (!blob) {
          return;
        }
        const compressedFile = new File([blob], 'fileName', {
          type: blob.type,
        });
        uploadFile(compressedFile);
      }, 'image/webp', 0.7)
    };
    image.src = dataUrl;
  };

  // 1-1. fileReader로 file을 읽는다.
  fileReader.readAsDataURL(file);
};

const handleImageChange = (e: ChangeEvent<HTMLInputElement>) => {
  const file = e.target.files?.[0];

  if (!file) {
    return;
  }

  compressImageAndUploadFile(file);
}

코드 리팩토링하기

리팩토링 기준

1. 이미지 압축 로직과 파일 업로드 관련 로직을 분리하기
2. 콜백 지옥에 빠지지 않도록 만들기

const handleImageChange = async (e: ChangeEvent<HTMLInputElement>) => {
  const file = e.target.files?.[0];

  if (!file) {
    return;
  }

  const dataUrl = await readFileAsDataURL(file);
  const image = await loadImage(dataUrl);
  const compressedBlob = await convertImageToCompressedBlob(image);
  const compressedFile = new File([blob], 'fileName', { type: blob.type });

  await uploadFile(compressedFile);
}

const readFileAsDataURL = (file: File): Promise<string> => {
  return new Promise<string>((resolve, reject) => {
    const fileReader = new FileReader();

    reader.onload = () => {
      const dataUrl = reader.result;

      if (!dataUrl || typeof dataUrl !== 'string') {
        reject(new Error('Invalid data URL'));
        return;
      }

      resolve(dataUrl);
    };
    reader.onerror = reject;
    reader.readAsDataURL(file);
  })
};

const loadImage = (url: string): Promise<HTMLImageElement> => {
  return new Promise<HTMLImageElement>((resolve, reject) => {
    const image = new Image();

    image.onload = () => reslove(image);
    image.onerror = reject;
    image.src = url;
  })
};

const convertImageToCompressedBlob = (image: HTMLImageElement): Promise<Blob> => {
  const MAX_WIDTH = 1024;
  const MAX_HEIGHT = 1024;
  const BLOB_TYPE = "image/webp";
  const BLOB_QUALITY = 0.7;

  return new Promise((resolve, reject) => {
    const canvas = document.createElement("canvas");

    const ratio = Math.min(MAX_WIDTH/image.width, MAX_HEIGHT/image.height, 1);

    const newWidth = image.width * ratio;
    const newHeight = image.height * ratio;
    canvas.width = newWidth;
    canvas.height = newHeight;

    const canvasContext = canvas.getContext("2d");
    if (!canvasContext) {
      throw new Error("Cannot get canvas context");
    }

    canvasContext.drawImage(image, 0, 0, newWidth, newHeight);
    canvas.toBlob(blob => {
      if (!blob) {
        reject(new Error("Cannot convert canvas to Blob"));
        return;
      }

      resolve(blob);
    }, BLOB_TYPE, BLOB_QUALITY);
  })
};

Problem

1. 확장자만 바꾼다고 해서, 용량이 줄어드는 건 아니다.

압축률이 좋은 확장자라고 했으니, 확장자만 바꿨을 때에도 용량이 줄어들 것이라고 생각했다.

하.지.만 canvas에 이미지를 로드한 후, blob으로 변환할 때 quality를 1로 설정했더니 용량이 오히려 커지는 경우가 생겼다.

canvas에서 이미지를 변환할 때, quality 매개변수는 0부터 1까지 입력이 가능하고 1은 최고 품질을 의미한다. 따라서, 최고 품질로 설정했을 때에는 파일 크기가 오히려 커질 수 있다.

quality를 1.0으로 설정했을 때, 원본 파일 크기: 16,387,072 변환한 파일 크기: 29,319,412

quality를 0.7로 설정했을 때, 변환한 파일 크기: 917,310

1. file을 보내려면?

문제

fetch를 통해 Route Handler로 요청을 보낼 때, data에 파일을 그대로 넣었더니 json() 메서드로 파싱시, 에러가 발생했다.

// StoryForm.tsx
const uploadImageFile = async (file: File) => {
  const res = await fetch(url, {
    method: 'POST',
    body: compressedImageFile,
  });

  //...
}

// route.ts
export const POST = async (req) => {
  const requestBody = await req.json();
  // SyntaxError: Unexpected token R in JSON at position 0
}

문제 원인

파일을 API Route로 보내고 처리하는 과정에서 JSON으로 데이터를 파싱하려고 시도했을 때 발생하는 문제는 파일 데이터를 JSON 형식으로 직접 보내려고 했기 때문이다. 파일은 바이너리 데이터이므로 JSON 형식으로 직접 변환되지 않는다. 따라서 파일을 전송할 때는 FormData 객체를 사용하여 멀티파트 형식으로 데이터를 인코딩해야 한다.

문제 해결

// StoryForm.tsx
const uploadImageFile = async (file: File) => {
  const formData = new FormData();
  formData.append('file', file);

  const res = await fetch(url, {
    method: 'POST',
    body: formData,
  });

  //...
}

// route.ts
export const POST = async (req) => {
  const requestBody = await req.formData();
  // ...
}

2. File 타입을 확인할 수 없다?

문제

Route Handler에서 요청 formData에 있는 내용이 File 타입인지 확인하기 위해, instanceof를 통해 체크하려고 했다. 하.지.만 에러가 발생했다.

const checkIsFile = (value: unknown): value is File => {
  return value instanceof File;
}
// ReferenceError: File is not defined

문제 원인

File 객체가 서버 측(Node.js) 환경에서 정의되어 있지 않기 때문이다. File 객체는 브라우저의 Web API의 일부로, 브라우저 환경에서만 사용할 수 있다. 따라서, Next.js의 서버 측 로직(ex: API Route Handler)에서는 접근할 수 없다.

문제 우회

formData에 담긴 file 객체의 타입을 체크하진 않고, 존재하는지만 확인하도록 함.

export const POST = async (req: NextRequest) => {
  const formData = await req.formData();
  const file = formData.get('file');

  if (!file) {
    return NextResponse.json({ message: "BadRequest" }, { status: 400 });
  }

  // ...
}

• '렌더링'이라는 단어로 머리속에 혼재되어 있던, 브라우저 렌더링과 리액트 렌더링을 구분하여 생각할 수 있게 되었다.
• 리액트 렌더링을 수행하는 쪽에 따라 CSR과 SSR로 구분하여 생각할 수 있게 되었다.
• hydrate 시에 브라우저 콘솔에 발생한 경고의 이유를 알게 되었다.

리액트를 이용해서 프론트엔드 개발을 할 때, 리액트 렌더링이 어느쪽에서 수행되는지를 기준으로 나눠볼 수 있다.

1. 클라이언트사이드 렌더링(CSR)

2. 서버사이드 렌더링(SSR)

단일 페이지 어플리케이션(SPA)의 등장

SPA 등장 이전의 멀티 페이지 어플리케이션은 서비스 내에서 페이지 전환(라우팅) 시, 이동하려는 페이지에 대한 HTML 파일을 새로 가져와 브라우저에서 렌더링을 해야 했다. 이로 인해, 이동할 때 사용자 경험이 좋지 않았다. (다음 페이지에 대한 HTML을 받아 렌더링을 하기 전까지, 빈 화면이 노출)

액자에 그림을 바꿔서 걸 때, 이전 그림을 빼고 다음 그림을 넣는 동안 액자 뒷면이 그대로 노출 되는 것

모바일 앱과 유사한 사용자 경험을 제공하기 위해 자바스크립트 코드를 사용하여, 유저 인터렉션에 따라 DOM 구조를 수정하는 방식을 도입하고자 함.

동작 방식

SPA는 단일 페이지(HTML)로 구성된 앱으로, 초기 페이지 요청 시 함께 받은 자바스크립트 코드를 이용하여 렌더링 및 리렌더링을 수행한다.

액자에 그림을 바꾸기 위해, 그려져있던 그림을 지우개로 지우고 새로 그리는 방식

단점

첫 페이지 요청 시, 많은 양의 자바스크립트 코드를 다운로드해야 하므로 초기 로딩 시간이 길어진다.

액자를 두고, 첫 그림을 가져올 때 그림을 그릴 빈 도화지를 가져오고 그림을 그릴 도구들을 가져온 후에 직접 그려야 함.

단점 해결 방안

1. 코드 스플리팅과 지연 로딩 필요한 코드를 필요한 시간에 받도록 하여, 로딩 시간을 줄일 수 있음

   그릴 수 있는 그림을 모두 그릴 수 있도록 여러 도구(연필, 물감, 크레파스 등)를 처음부터 준비하지 않고, 지금 보려는 그림을 그릴 도구만 준비하는 것.

2. 서버사이드 렌더링 페이지 요청 시, 서버에서 해당 페이지에 대한 HTML을 렌더링한 후 클라이언트로 전달

   빈 도화지를 받지 않고, 그림이 그려진 도화지를 받는 것.

서버사이드 렌더링

과정

서버에서 요청받은 페이지에 대해 HTML을 렌더링한 후, 클라이언트에 전달한다. 클라이언트에서는 전달 받은 HTML에 대해 Hydration이 수행된다.

리액트가 클라이언트 측에서 실행되어, 정적인 HTML에 동적인 기능을 추가하는 것을 Hydration이라고 한다. 이 과정에는 이벤트 리스너의 등록, 리액트 컴포넌트의 상태 관리 등이 포함되어, 사용자와의 인터렉션이 가능한 동적인 페이지로 전환된다.

추가 설명

• 서버사이드에서 리액트 컴포넌트를 렌더링할 때, ReactDomServer.renderToString() 이라는 메서드를 사용한다. 정적 HTML 마크업을 생성한다.

• 클라이언트 사이드에서 Hydration을 수행할 때는 ReactDOM.hydrate() 메서드를 사용한다. 정적 HTML 마크업에 리액트 이벤트 핸들러를 연결하고, 리액트 상태 관리 및 생명주기 메서드 등을 활성화한다.

• Hydration시, 서버에서 생성한 마크업과 연결하려고 하는 컴포넌트를 렌더링했을 때의 마크업이 다르면 '경고'가 발생하고, 클라이언트사이드 렌더링으로 전환된다. 서버사이드 렌더링에 이어 추가 렌더링이 발생하게 될 수 있음.

쿠키란?

웹 서버가 생성하여, 웹 브라우저로 전송하는 "작은 정보 파일" 웹 브라우저는 수신한 쿠키를 일정 기간동안 저장하고, 향후 사용자가 웹 서버에 요청을 보낼 때, 첨부한다.

언제 쓸까?

• 사용자 세션 웹 서버에 요청을 보내는 사용자가 누구인지 파악하기 위해. ex) 웹 사이트에 로그인했을 때, 웹 서버에서는 세션 쿠키를 생성하여 브라우저로 전송한다. 브라우저에 저장된 쿠키는 이후 웹 서버로 보내는 요청에 포함된다. 요청을 받은 웹 서버는 어떤 유저에 대한 요청인지 파악할 수 있게 된다.

• 트래킹 사용자가 방문한 웹 사이트가 기록되어, 다음에 브라우저가 해당 서버에서 콘텐츠를 로드할 때 기록을 쿠키에 담아 서버로 전송한다. 이를 통해, 어떤 곳들을 방문했었는지를 알 수 있게 된다.

옵션

• 유효 기간 설정 (Expires/Max-age)
• 전송 가능한 요청 도메인 설정 (Domain)
• 전송 가능한 요청 경로 설정 (Path)
• 보안 측면
  • HTTPS 프로토콜 요청에 대해서만 쿠키를 전송 (Secure)
  • JavaScript를 통해 접근할 수 없도록 함 (HttpOnly)
  • 같은 사이트 요청에서만 제공 설정 (SameSite)

?!

1. HttpOnly 옵션이 활성화되지 않은 쿠키는 어떻게 가져올 수 있을까? document.cookie 를 통해, 쿠키 정보를 확인할 수 있다.

Package.json과 Package-lock.json

Package.json

Node.js 프로젝트에서 사용되는 "프로젝트에 대한 설명서" 파일이다. 프로젝트의 이름, 버전, 작성자, 라이센스, 의존성(서드파티 패키지) 정보가 포함되어 있다.

Package-lock.json

프로젝트 기본 정보 및 의존성 트리에 대한 정보가 포함되어 있다.

Package-lock.json이 필요한 이유는?

package.json 파일 안에 있는 "의존성" 정보에는 해당 패키지에 대한 '대략적인' 버전이 명시된다. 즉, 정확한 패키지 버전에 대한 정보는 없음. 다른 서버에서 프로젝트를 실행할 때, 대략적인 버전으로 설치가 되는 경우에 문제가 생길 "수도" 있기 때문에 특정한 시점을 기준으로 명확한 버전을 명시할 필요가 있기 때문에 package-lock.json 이 필요하다.

브라우저 렌더링

브라우저 렌더링

브라우저 렌더링은 웹 페이지가 사용자의 화면에 표시되는 과정을 말한다. 브라우저 렌더링은 다음 과정을 거쳐 진행된다.

1. 문서(HTML) 파싱(분석) 브라우저는 HTML Document를 받아서 DOM 트리를 구축한다. 이 트리는 페이지의 구조를 나타내며, 각각의 HTML 태그는 트리의 노드가 된다.

2. CSS 파싱 CSS 파일과 style 태그 내부의 스타일 정보를 파싱하여, CSSOM 트리를 생성한다. 이 트리는 페이지의 시각적 규칙을 나타낸다.

3. 렌더 트리 구축 DOM 트리와, CSSOM 트리를 결합하여, 렌더 트리를 형성한다. 렌더 트리는 페이지에 실제로 표시되는 요소들만 포함한다.

4. 레이아웃 (리플로우) 렌더 트리의 각 노드에 대해 화면 상의 정확한 위치와 크기를 계산한다. 브라우저 창의 크기 변경이나 요소의 추가 및 삭제 등에 의해 다시 실행될 수 있다.

5. 페인트 렌더 트리의 각 노드를 화면에 그린다. 텍스트 색상, 배경 이미지 등의 시각적 스타일이 적용된다. 레이아웃 단계 이후에 실행된다.

6. 합성 여러 레이어를 합쳐 최종적인 화면을 생성한다. CSS의 transform 속성을 활용한 애니메이션은 별도의 레이어에서 처리될 수 있는데, 이처럼 복잡한 페이지는 여러 레이어로 구성될 수 있음.

?!

• 실제로 표시되는 요소만을 포함한다? display: none 스타일이 적용된 요소는 렌더 트리에 포함하지 않는다.

업데이트 유형

Reflow와 Repaint는 브라우저 렌더링 과정에서 발생하는 업데이트 유형이다. 웹 페이지 성능과 직접적인 관련이 있다.

Reflow

(정의) 레이아웃을 다시 계산하고, 변경이 필요한 경우 업데이트하는 과정

(원인) DOM 요소의 추가(제거), 요소의 크기나 위치 변경, 창 크기 조절, 숨겨진 요소의 표시 등의 원인으로 일어난다.

(영향 범위) 한 요소의 변경은 해당 요소의 자식, 부모 요소등 페이지의 다른 부분에도 영향을 줄 수 있다. (페이지 전체 레이아웃을 다시 계산해야 할 수도 있다는 것)

(성능 영향) 비용이 많이 드는 연산이기에, 웹 페이지 성능에 큰 영향을 미친다. 특히, 복잡한 레이아웃을 가진 페이지에서 영향이 크다.

Repaint

(정의) 요소의 시각적 변경이 발생했을 때, 변경된 요소를 다시 그리는 과정

(원인) 텍스트 색상 변경, 배경 이미지 변경, 테두리 스타일 변경 등 레이아웃 변경을 수반하지 않는 스타일 변경

(영향 범위) reflow에 비해 영향 범위가 작다. 해당 요소에 대한 스타일 변경으로 인해 다른 요소에 영향을 주지 않기에 발생한 요소에 대해서만 업데이트가 수행됨.

(성능 영향) reflow에 비해 성능에 미치는 영향이 적다. 단, 빈번하게 발생하면 렌더링 성능에 부정적인 영향을 줄 수 있다.

불필요한 Reflow를 줄이는 방법

일괄적으로 처리하는 방향

1. 스타일 변경 일괄 처리 (클래스를 통한 스타일 변경)

   적용 전

   DOM 요소의 스타일을 개별적으로 변경

    const element = document.getElementById('myElement');
    element.style.padding = '10px';
    element.style.margin = '20px';
    element.style.color = 'blue';

   적용 후

   단일 DOM 변경 사이클에서 여러 스타일 변경을 수행하기 위해 수정

    const element = document.getElementById('myElement');
    element.style.cssText = 'padding: 10px; margin: 20px; color: blue;';
    // 또는
    element.className = 'newStyles';

2. 레이아웃 정보 읽기와 쓰기 분리

   적용 전

   레이아웃을 읽고 쓰는 작업이 혼재되어 있어, 불필요한 Reflow가 발생할 수 있음

    const elements = document.querySelectorAll('.item');
    for (let element of elements) {
      element.style.height = (element.offsetHeight + 10) + 'px';
    }

   적용 후

   모든 레이아웃 정보를 읽은 후, 일괄적으로 변경을 적용

    const elements = document.querySelectorAll('.item');
    const heights = Array.from(elements).map(el => el.offsetHeight + 10);
   
    elements.forEach((element, index) => {
      element.style.height = heights[index] + 'px';
    });

3. 오프스크린 요소 사용

   적용 전

   화면에 바로 요소를 추가하고, 스타일을 변경합니다.

    const element = document.createElement('div');
    document.body.appendChild(element);
    element.style.width = '100px';
    element.style.height = '100px';
    // 이러한 방식은 요소가 DOM에 추가될 때마다 Reflow를 유발할 수 있습니다.

   적용 후

   요소를 브라우저의 화면에 표시되지 않는 영역에서 조작한 후, 최종적으로 DOM에 추가합니다.

    const element = document.createElement('div');
    element.style.width = '100px';
    element.style.height = '100px';
    // 요소에 대한 모든 변경을 적용한 후에 DOM에 추가합니다.
    document.body.appendChild(element);
    // 이 방법은 DOM에 요소를 추가하기 전에 모든 변경을 완료하여 Reflow를 최소화합니다.

정리

• 공통점 웹 페이지의 시각적 업데이트 과정의 유형이다.

• 차이점 Reflow는 레이아웃의 변경을 포함하여, 연산 비용이 더 많이 든다. Repaint는 시각적 스타일 변경에 국한되어, 레이아웃 변경을 수반하지는 않는다. 따라서, Reflow는 Repaint를 수반할 수 있지만 Repaint가 반드시 Reflow를 수반하는 것은 아니다.

1. update 로직 수정

client에서 직접 supabase로 업데이트 요청을 하지 않고, route로 이양하기 update할 때, 권한 체크하기

왜?

1. client 사이드에 업데이트 로직까지 몰려있어, 코드 분리 차원
2. supabase를 사용하지 않게 되었을 때, 수정을 용이하게 하기 위함
3. update 과정에서 권한을 체크해야 하는 경우 등의 상황이 생길 때, 어떤 통신을 주고받았는지 클라이언트 단에 노출시키지 않기 위함

구조

action.tsx

export const updateTemplate = async (data) => {
  'use server';
  const url = '~~';
  await fetch(url, {
    method: 'PATCH',
    body: data
  }); // route로 요청보내기

  revalidateTag('template'); // 데이터 refetch
};

SubmitButton.tsx

const SubmitButton = () => {
  // ...
  const submit = await () => {
    // ...
    const data = {};
    await updateTemplate(data);
  };
};

route.ts

const PATCH = (req) => {
  // ...
  await checkUserUpdatePermission();
  await updateTemplateMeta();
  await updateTemplatePosts();
};

2. serverState와 clientState 동기화

업데이트 후, refetch한 serverState와 useState로 관리하던 clientState간의 동기화가 되지 않는 문제

동기화가 필요한 이유

현재 구조에서는 다음 플로우로 업데이트가 2번 일어났을 때, 예상했던 동작과 다르게 수행 됨.

(post를 추가) -> (첫 번째 업데이트) -> (refetch) -> (두 번째 업데이트)

post를 추가했을 때, clientState는 추가된 post의 id를 임시로 만들어서 관리를 한다. 업데이트를 수행했을 때, 임시 id는 제외하고 insert를 하게 되는데 이 post에 대해 새로운 id를 부여함. 그렇기에 refetch를 했을 때 가져오는 template의 post id와 clientState에서의 post id가 달라짐.

업데이트를 1번만 했으면, 크게 문제될 것은 아니지만 다시 업데이트를 했을 때 문제가 발생

아무것도 변경하지 않고, 두 번째 업데이트를 수행한다면 (예상 로직) post에 대해서는 insert 없이, 기존 post에 대해서 update만 수행

(실제 로직) 이전 업데이트에서 추가되었던 post는 delete & insert 수행. 추가되었던 post에 대한 id를 서로 다르게 관리하고 있기 때문)

동기화를 어떻게 할 것인가?

1. refetch가 일어나서, server에서 전달받은 template이 변경되었을 때 clientState를 변경된 데이터에 맞춰준다.
2. clientState를 관리하는 컴포넌트의 key를 template 업데이트했을 때 변경하여, 리렌더링을 트리깅한다.
3. 업데이트를 할 때, 동기화가 필요한 데이터(ex. insert)는 따로 clientState 동기화를 해준다.

나는 더 간단한 방식인 1번 방식으로 진행했음. 2번 방식은 동기화 때문에 하기에는 너무 과하다고 생각함. 3번 방식은 로직이 복잡해질 것

적용

// serverComponent
const Page = async() => {
  // ...
  return <InnerPage template={template} /> 
};

// clientComponent
const InnerPage = (template) => {
  const [posts, setPosts] = useState(template.posts);
  useEffect(() => {
    setPosts(template.posts);
  }, [template.posts]);

  // ...
};

TIL

없음.

1. 이미지 추가 시, storage에 업로드하기

file input을 통해 이미지를 추가했을 때, 이미지를 storage에 업로드한다.

기존 로직

1. 파일을 리사이징하여 용량을 줄인다.
2. objectUrl을 이용하여, 로컬에서 이미지를 확인한다.

const handleChangeFileInput = async (event: ChangeEvent<HtmlInputElement>) => {
  const file = e.target.files[0];

  const blob = await resizeFile(file);
  const url = URL.createObjectURL(blob);
  // ...
}

변경한 로직

1. 파일을 리사이징하여 용량을 줄인다.
2. blob을 파일로 변환하여, storage에 업로드한다.
3. 업로드한 이미지 경로를 images 테이블에 저장한다.

const handleChangeFileInput = async (event: ChangeEvent<HtmlInputElement>) => {
  const file = e.target.files[0];

  const blob = await resizeFile(file);

  const fileName = `Date.now()`;
  await supabase
    .storage
    .from('images')
    .upload(fileName, blob)
    .then(({ data, error }) => {
      if (error) {
        throw new Error(error.message);
      }
    });

  const imageUrl = `${BASE_URL}/${fileName}`;
  const newImage = await supabase
    .from('images')
    .insert({ url })
    .select('*')
    .single()
    .then(({ data, error }) => {
      if (error) {
        throw new Error(error.message);
      }

      return data;
    })
  // ...
}

2. 청첩장 수정 기능 만들기

1. Story 업데이트

스토리는 배열 형태로 이미지 배열도 가지고 있기 때문에, wedding_hall 보다 업데이트 로직이 복잡함.

1. 스토리 분리 a. 신규 스토리 b. 기존 스토리 c. 삭제할 스토리

2. 신규 스토리 추가

   • insta_template.stories.insert → 신규 스토리

       const newStoryId = await supabase
           .schema('insta_template')
           .from('stories')
           .insert({
               title: story.title,
               template_id: templateId,
           })
           .select('*')
           .then(({ data, error }) => {
               if error throw new Error(error.message);
     
               return data.id;
           })

   • insta_template.story_image_link.insert → 신규 이미지

       await supabase
           .schema('insta_template')
           .from('story_image_link')
           .insert({
               story_id: newStoryId,
               image_id: story.id,
           });
       // then 생략

   • insta_template.images.update → display_order 업데이트

       await Promise.all(
           story.images.map(async ({ id }, index) => {
               return supabase
                   .schema('insta_template')
                   .from('images')
                   .update({ display_order: index })
                   .eq('id', id);
           })
       )

3. 스토리 업데이트

   • insta_template.stories.update

     → title 업데이트

   • insta_template.story_image_link.insert

     → 신규 이미지

   • insta_template.story_image_link.delete

     → 삭제된 이미지

   • insta_template.images.update

     → display_order 업데이트

4. 스토리 제거

   • insta_template.stories.delete

     → 삭제된 스토리

→ 스토리가 삭제되면 링크 테이블의 데이터도 삭제된다.

1. 유저가 회원가입했을 때, template를 생성하기
2. template가 추가되었을 때, metadata를 생성하기

supabase.database의 function과 trigger

supabase는 postgreSQL DB를 제공하고 있어, 테이블 외에 function과 trigger를 제공한다. 이번 작업은 function/trigger를 이용하여, 테이블에 row가 insert 되었을 때 기본으로 있어야 하는 데이터를 자동으로 추가하도록 했다.

1. 유저가 회원가입했을 때, template를 생성하기

처음에는 회원가입을 할 때, 회원가입 요청을 보낸 후 template를 생성하는 요청도 포함하도록 하려고 했었다.

// /api/auth/signup/route.ts
export const POST = (req: NextRequest) => {
  // ...
  await supabase.auth.signup(user);
  await supabase.from('template').insert(template);
  // ...
};

그런데, signup 함수에 template를 생성하는 로직도 같이 있는 것이 맞을까? 하는 생각이 들면서 다른 방식을 찾아보게 되었다. supabase의 function/trigger를 알게 되었고, 이를 적용해보기로 했다. 내가 원하는 동작은

1. auth.users 테이블에 insert가 되었을 때
2. 생성된 새로운 row(users)에서 userId를 가지고,
3. public.templates 테이블에 insert를 하는 것

1번은 trigger의 역할이 되고, 2/3번은 function의 역할이 된다. function을 먼저 정의해보자 function은 postgreSQL의 프로시저 언어인 PL/pgSQL을 사용하여 작성했다.

create or replace function create_template_on_user_insert()
returns trigger as $$
begin
  insert into templates(user_id, code)
  values (new.id, new.raw_user_meta_data->>'code');
  return new;
end;
$$ language plpgsql security definer;

• create_template_on_user_insert 라는 함수를 생성/대체한다.
• trigger를 반환한다.
• 실행할 함수 본문을 $$ 사인으로 감싼다.
• plpgsql 언어로 작성했으며, 함수 생성자가 호출할 수 있도록 한다.

이 함수를 호출할 trigger를 정의해보자

create trigger create_template_trigger
after insert on auth.users for each row
execute procedure create_template_on_user_insert();

• create_template_trigger 라는 trigger를 생성한다.
• auth.user 테이블의 각각의 row가 insert 이후에 수행되며,
• create_template_on_user_insert 라는 procedure를 실행한다.

이젠, 회원가입이 이루어졌을 때 template 템플릿을 생성할 수 있다!

2. template가 추가되었을 때, metadata를 생성하기

회원가입 후 template를 생성하는 것과 동일한 방법(function/trigger)으로 metadata를 생성해보자.

// 함수 정의
create or replace function create_metadata_on_template_insert()
returns trigger as $$
  begin
    insert into metadata(template_id)
    values (new.id)
    return new;
  end;
$$ language plpgsql security definer;

// trigger 정의
create trigger create_metadata_trigger
after insert on templates for each row
execute procedure create_metadata_on_template_insert();

이젠, template가 추가되었을 때, metadata가 추가된다!

1. Comment 삭제하기 a. submit 후, post 데이터 업데이트하기 b. 삭제 시, 비밀번호 체크하기 c. 비밀번호 확인 가능하도록 하기 d. 비밀번호 입력 후, submit 했을 때 저장하겠냐는 confirm 안뜨게 하기
2. Comment 생성 로직 수정하기 a. 비밀번호 입력 input 수정 b. 값을 입력하지 않았을 때, submit이 실행되지 않도록 하기

1. Comment 삭제하기

Submit 후, post 데이터 업데이트하기

post 데이터는 서버 컴포넌트에서 fetch를 통해 가져왔기 때문에 revalidateTag를 이용해서 데이터를 업데이트시켜야 했다. 그런데, 클라이언트 함수에서 revalidateTag를 호출했을 때, 에러가 발생함.

const handleSubmit = async () => {
  // ...
  await fetch(url, { method: "DELETE" });
  revalidateTag("comments");
  // Invariant: static generation store missing in revalidateTag comments
}

클라이언트 컴포넌트에서 revalidate를 하는 방법을 알아봤다. "How to revalidate data from the client Component"

이 질문의 답변 내용 중 "revalidate하는 함수를 serverAction으로 만들어라"라는 걸 보고 적용해봤다.

// actions.ts
const deleteComment = async (commentId: string, password: string) => {
  "use server";
  // host, protocol, url을 구하기
  await fetch(url, { method: "DELETE" });
  revalidateTag("comments");
}

// DeleteCommentDialog.tsx 중
const handleAction = async (formData: FormData) => {
  // ...
  await deleteComment(commentId, password);
}

알게된 내용 서버 액션은 서버 컴포넌트에서만 사용이 가능한 줄 알았지만, 아니었다. 하긴, 서버 컴포넌트도 어떻게 보면 서버 함수일텐데, 클라이언트 컴포넌트의 자식 컴포넌트로 렌더링을 할 수 있으니까.

삭제 시, 비밀번호 체크하기

1. 비밀번호를 어떻게 전달할 것인가? DELETE 메서드는 body를 포함할 수는 있지만, 실제로 body를 사용하는 것을 권장하진 않는다고 한다. (경우에 따라서 body를 사용할 수 없는 케이스도 있기 때문) 그렇다면, 어떻게 비밀번호를 포함해서 전달할까?

-> QueryString에 비밀번호를 포함시켜서 전달하도록 함

2. supabase로 삭제 요청을 보냈을 때, 실제로 삭제되었는지 판단하려면? eq 메서드로 id, password를 전달해서, 삭제요청을 보냈는데 id와 password가 일치하지 않는 케이스를 판단하려면 count를 활용할 수 있다. delete의 옵션에 count 로직을 어떻게 수행할 지 결정할 수 있다. count 옵션이 없으면 count가 null로 반환되고, 있으면 실제 삭제된 row의 수가 반환된다.

   // comments/:id/route.ts
   const DELETE = async () => {
   // ...
   const { count } = await supabase
    .from("comments")
    .delete({ count: "exact" })
    .eq("id", id)
    .eq("password", password);
   }

3. 한글 등이 포함되었을 때, 주소가 유효하도록 하려면? 쿼리스트링을 encodeURIComponent 함수를 통해 인코딩시키기

   const encodedPassword = encodeURIComponent(password)
   const url = `${protocol}://${host}/api/comments/${commentId}?password=${encodedPassword}`

4. sumit 시, 비밀번호 저장 여부를 체크하는 브라우저 dialog가 뜨지 않도록 하기 비밀번호 input의 autoComplete 속성의 값을 one-time-code로 하면, confirm 창이 뜨지 않음.

   <input
   type="password"
   autoComplete="one-time-code"
   />

Comment 생성 로직 수정하기

비밀번호 인풋 수정

1. autoComplete 속성을 one-time-code로 설정하기

form submit 로직

1. input 값을 입력하지 않았을 때, submit할 수 없도록 하기 두 가지의 방식을 고민했었지만, b안으로 결정했음 이유: a안으로 하려면, submit 버튼의 disabled를 막고 input에서의 Enter 키 입력도 막아줘야 했기 때문에 b안에 비해 로직이 복잡해질 것 같았음.

-_ a. submit 이벤트를 실행할 수 없도록 막기 b. submit 이벤트가 수행되었을 때 확인하여, 중단하기 -_ 입력한 값이 유효한지를 확인하는 것이니까, zod를 활용하면 좋겠다는 생각을 했음. 지금은 입력했는지 여부만 판단하면 되는 것이기에 min 메서드를 활용했고, 추후에 다른 조건이 생기면 schema만 수정해주면 될 것 같다.

const createCommentSchema = z.object({
  name: z.string().min(1),
  content: z.string().min(1),
  password: z.string().min(1),
});

const handleFormAction = async (formData: FormData) => {
  // ...
  const data = {
    name,
    content,
    password,
  }
  const parsedData = createComentSchema.safeParse(data);

  if (!parsedData.success) {
    alert("입력값을 확인해주세요");
    return;
  }
};