Dorong Dorong 💻😴

TOAST UI - 터치와 클릭 이벤트 글에서 생긴 의문을 정리하기 위한 글입니다.

터치 이벤트를 달았는데 왜 클릭 이벤트까지 발생하나요?

• 터치가 발생하면 내가 별도로 클릭 이벤트를 달지 않았어도 click 이벤트가 중복으로 발생해 버립니다.
  왜 이런 동작이 일어나는 걸까요?
• 웹은 오랫동안 마우스 클릭 중심으로 설계되고 발전했습니다.
• 지금까지 많은 사이트가 오직 click 이벤트만 듣고 동작하도록 만들어져 있기 때문에, 모바일 브라우저는 호환성 유지를 위해 터치 시 자동으로 click 이벤트도 함께 발생시키도록 설계돼 있습니다. 그렇기에 터치스크린 환경에서도 기존 마우스 중심 사이트들이 별도 수정 없이 동작할 수 있습니다.

터치 이벤트 후 click 이벤트가 발생하는 게 왜 편의일까요?

• 여러 자료에서 이걸 편의라고 하던데 표현이 너무 포괄적으로 느껴져서 그런지 처음에는 이해가 되지 않았습니다. 아래는 제가 찾아본 후 이해한 내용입니다!
  
  • 브라우저는 이 사이트가 터치/클릭 둘 다 지원하는지, 어떤 식으로 의도했는지 알 방법이 없습니다.
  • 그래서 일괄적으로, 터치가 발생하면 반드시 click 이벤트도 같이 발생하도록 만들었습니다.
  • 브라우저는 저희가 만든 사이트만 띄우는 것이 아니라 아주 많은 사이트를 동시에 지원해야 합니다. 모바일 도입 초기엔 대부분 오직 클릭 이벤트만 사용했기 때문에, 터치 이벤트만 발생시 클릭 이벤트가 발생하지 않으면 옛날 사이트들이 모바일에서 먹통이 될 수 있다고 판단했습니다. 그래서 터치 시 자동으로 클릭 이벤트도 발생시키도록 설계되었고 기존 클릭 기반 사이트와의 호환성도 보장합니다.

React 등에서도 클릭 이벤트가 발생할까요?

• 많이 사용하는 React 기준으로 여기서도 브라우저의 이벤트 위임 메커니즘을 그대로 따랐습니다. 브라우저의 네이티브 이벤트 시스템을 그대로 활용했기 때문에 동일한 동작이 발생해요.
• 브라우저가 터치 이벤트 후 자동으로 마우스와 클릭 이벤트를 생성하는건 React 이전 단계에서 일어납니다.
• React는 브라우저의 네이티브 이벤트를 감싸는 SyntheticEvent를 사용하고 있어요. 하지만 브라우저의 기본 이벤트 동작은 변경하지 않습니다.
• 그리고 이벤트 위임을 사용하지만 이건 이벤트 처리 방식을 최적화하는 것이지 브라우저의 기본 이벤트 동작을 바꾸는게 아닙니다.
• 관련 토론인 GitHub 이슈 #9809를 정리해보면,
  
  • preventDefault() 무효화: React의 합성 이벤트에서 e.prevnetDefault()가 클릭 이벤트 방지에 실패
  • 네이티브 DOM API는 작동: addEventListener로 직접 등록하면 preventDefault()가 정상 동작
  • 브라우저별 차이: Chrome, Firefox, Safari에서 각각 다르게 동작 (추가 확인이 필요)
• 위의 내용은 관련 이슈를 직접 보고 상세 내용과 이유를 확인해 보는걸 추천드립니다!
• 이슈에서 제시된 해결책들도 짧게라도 정리해 보겟습니다.

// 방법 1: 네이티브 DOM API 사용
componentDidMount() {
  this.elem.addEventListener('touchstart', e => {
    e.preventDefault(); // 이건 작동함
  });
}

// 방법 2: 플래그 사용
handleTouchStart(event) {
  this.hasBeenTouchedRecently = true;
  setTimeout(() => { 
    this.hasBeenTouchedRecently = false; 
  }, 500);
}

handleMouseDown(event) {
  if(this.hasBeenTouchedRecently) {
    return; // 터치 후 마우스 이벤트 무시
  }
}

 <meta name="viewport" content="width=device-width">

프론트엔드 개발을 하다 보면 크로스브라우징 이슈는 피할 수 없습니다.

::-webkit-input-placeholder와 같은 브라우저별 프리픽스(-webkit-, -moz-, -ms- 등)를 일일이 추가하는 건 굉장히 번거로운 작업이예요.

사실 현업에서는 개발자가 직접 이러한 프리픽스를 추가하는 것이 매우 곤란한 일입니다.

(저도 관련된 대화를 나누다 알게됐어요!)

이러한 문제를 해결하기 위해 번들러를 통해 자동으로 프리픽스를 추가해주는 방법인 Autoprefixer를 사용할 수 있습니다.

PostCSS를 기본적으로 사용하는 라이브러리라면, 혹은 CSS로 변환한 후 postcss-loader가 처리하게 한다면 개발자가 각 브라우저 환경에 맞게 스타일을 따로 작성하지 않아도 Autoprefixer가 웹킷 프리픽스와 같은 것을 자동으로 붙여줍니다.

이번 포스트에서는 PostCSS와 Autoprefixer를 활용해 해당 ISSUE를 해결하는 방법을 실제 프로젝트 경험을 바탕으로 상세히 알아보겠습니다!

PostCSS와 Autoprefixer란?

PostCSS

• JavaScript 플러그인을 사용해 CSS를 변환하는 도구
• "Post-processor"라고도 불리는 이유는 CSS를 작성한 후에 처리하기 때문
• CSS 구문 분석에 최적화된 파서를 사용해 높은 성능을 보임
• CSS 전처리기(Sass)나 후처리기로 사용 가능 (이 부분은 제가 헷갈렸던 부분이라 아래 추가설명을 넣었어요!)
  1. CSS 전처리기(SASS):
     CSS 기능을 확장한 언어 입니다. 변수, 중첩 규칙, 믹스인 등을 지원하고, PostCSS는 Sass로 작성한 코드를 처리할 수 있지만, PostCSS 자체는 Sass 문법을 사용하진 않아요.
  2. CSS 후처리기:
     PostCSS는 CSS코드가 작성된 후에 추가적인 변환 작업을 수행하는 도구로 사용될 수 있습니다.
     예를 들어, 제가 지금 작성하는 Autoprefixer 같은 플러그인을 사용해서 자동으로 브라우저 프리픽스를 추가할 수 있는 것처럼요!
• 200개 이상의 플러그인으로 다양한 기능 제공 (생태계가 큽니다!)
• 모듈화된 구조로 필요한 기능만 플러그인으로 선택적 추가 가능

Autoprefixer

• PostCSS의 대표적인 플러그인
• 브라우저 프리픽스를 자동으로 추가해주는 도구
• Browserslist 설정을 통해 지원 브라우저 범위 지정 가능

Create React App과 Vite의 기본 지원

해당 부분은 Webpack을 직접 설정하지 않을 땐 어떻게 되는 건지, 기본 설정이 되어 있는지 등이 궁금해 찾아보게 됐습니다.

Create React App (CRA)

• PostCSS와 Autoprefixer가 기본으로 설정되어 있음
• 별도 설정 없이 바로 사용 가능
• browserslist 설정도 기본 제공

CRA의 package.json을 보시면 아래와 같은 코드를 확인하실 수 있습니다.

"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

Vite

• PostCSS는 기본 지원
• Autoprefixer는 별도 설치 필요

yarn add -D autoprefixer

// vite.config.js
import autoprefixer from 'autoprefixer'

export default {
  css: {
    postcss: {
      plugins: [
        autoprefixer()
      ]
    }
  }
}

현재 프로젝트에 Custom Webpack 설정하기

커스텀 Webpack 설정에서는 수동으로 PostCSS와 Autoprefixer를 설정해야 합니다.

필요한 패키지 설치

yarn add -D postcss postcss-loader autoprefixer

웹팩 설정 예시

module.exports = {
  module: {
    rules: [
      {
        test: /\.module\.scss$/,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              modules: {
                localIdentName: "[name]__[local]--[hash:base64:5]",
              },
              importLoaders: 2,
            },
          },
          {
            loader: "postcss-loader",
            options: {
              postcssOptions: {
                plugins: [
                  ["autoprefixer"]
                ],
              },
            },
          },
          "sass-loader",
        ],
      },
      {
        test: /\.(scss|css)$/,
        exclude: /\.module\.scss$/,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              importLoaders: 2,
            },
          },
          {
            loader: "postcss-loader",
            options: {
              postcssOptions: {
                plugins: [
                  ["autoprefixer"]
                ],
              },
            },
          },
          "sass-loader",
        ],
      },
    ],
  },
  // ... 기타 웹팩 설정
};

실수했던 부분과 해결 방법

package.json에 작성돼야 하는 json 문법을. browserslistrc 파일에 적용해 버렸어요. 공식 문서를 읽다 순간적으로 착각했습니다. 너무 간단하지만 제 기준에서 치명적인 실수란 생각이 들어 기록해두려 합니다!

Browserslist 설정 오류

Error [BrowserslistError]: Unknown browser query `{`. Maybe you are using old Browserslist or made typo in query.

.browserslistrc 파일 사용 (권장)

저는 최종적으로 아래의 코드로 수정했습니다!

# 프로덕션 환경
[production]
>0.2% # 전 세계 사용률 0.2% 이상인 브라우저
not dead # 공식 지원이 중단되지 않은 브라우저
not op_mini all # Opera Mini 브라우저 제외

# 개발 환경
[development]
last 1 chrome version # 최신 크롬 버전
last 1 firefox version # 최신 파이어폭스 버전
last 1 safari version # 최신 사파리 버전

해결방법 2: package.json에 설정

{
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Browserslist 설정 가이드

주요 쿼리 설명

• >0.2%: 전 세계 사용률 0.2% 이상인 브라우저
• not dead: 공식 지원이 중단되지 않은 브라우저
• not op_mini all: Opera Mini 브라우저 제외
• last 1 chrome version: 최신 크롬 버전
• last 2 versions: 각 브라우저의 최신 2개 버전
• > 1%: 전 세계 점유율 1% 이상
• IE 11: IE 11 지원

설정 테스트

• browserslist.dev에서 설정을 테스트할 수 있음
• 어떤 브라우저가 포함되는지 실시간으로 확인 가능

실제 동작 예시

변환 전 CSS

.example {
  display: flex;
  user-select: none;
}

변환 후 CSS

.example {
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-user-select: none;
     -moz-user-select: none;
      -ms-user-select: none;
          user-select: none;
}

주의사항과 팁!

• 로더 순서: PostCSS 로더는 Sass 로더 이후, CSS 로더 이전에 위치해야 합니다.  
  1. sass-loader (SCSS -> CSS 변환)
  2. postcss-loader (자동 프리픽스 추가)
  3. css-loader (CSS -> JS 변환)
  4. style-loader (JS -> style 태그 삽입)
• 성능 최적화: development 환경에서는 source map을 활성화하고, production에서는 비활성화하는 것이 좋습니다.
• 브라우저 지원 범위: browserslist 설정을 통해 지원할 브라우저 범위를 적절히 조절해야 합니다.

주의사항과 팁에서의 Development 환경에서 source map 활성화하는 이유 & Production 환경에서 비활성화 하는 이유에 대해서만 좀 더 자세히 알아볼게요!

Development 환경에서 source map 활성화하는 이유:

1. 디버깅 용이성
   • 개발 중에는 원본 소스 코드와 변환된 코드를 매핑하여 쉽게 디버깅할 수 있습니다
   • 브라우저의 개발자 도구에서 실제 작성한 CSS 파일의 위치와 라인을 정확히 확인 가능
   • PostCSS로 변환된 코드가 아닌 원본 코드를 직접 확인하며 수정 가능
2. 개발 효율성
   • 코드 수정 시 즉각적인 피드백 확인 가능
   • CSS 문제 발생 시 정확한 위치 추적이 가능하여 수정 시간 단축
   • 복잡한 스타일 구조에서도 원본 코드 위치를 쉽게 파악!

Production 환경에서 source map 비활성화하는 이유:

1. 파일 크기 최적화
   • source map 파일은 원본 코드와 변환된 코드의 매핑 정보를 포함하므로 상당한 크기를 차지
   • 프로덕션 환경에서는 불필요한 데이터 전송을 줄여 로딩 속도 향상
   • 일반적으로 source map 파일은 원본 파일 크기의 절반 이상을 차지할 수 있음
2. 보안 강화
   • source map이 노출되면 원본 코드 구조가 드러날 수 있음
   • 악의적를 가진 사용자가 코드 구조를 분석하는 것을 방지
   • 기업의 proprietary 코드 보호!!
3. 성능 최적화
   • 브라우저가 source map을 처리하는 추가적인 작업 제거
   • 초기 페이지 로딩 시간 단축
   • 서버 대역폭 사용량 감소

실제 설정 예시! (프로젝트 코드보다 간략화)

// webpack.config.js
module.exports = {
  mode: process.env.NODE_ENV,
  module: {
    rules: [{
      test: /\.css$/,
      use: [
        'style-loader',
        {
          loader: 'css-loader',
          options: {
            sourceMap: process.env.NODE_ENV === 'development'
          }
        },
        {
          loader: 'postcss-loader',
          options: {
            sourceMap: process.env.NODE_ENV === 'development'
          }
        }
      ]
    }]
  }
};

결론

PostCSS와 Autoprefixer를 사용하면 크로스브라우징을 위한 수동 작업을 자동화할 수 있습니다.

CRA나 Create Vite같은 경우 이미 이러한 기능을 기본으로 제공하고 있으며, 커스텀 웹팩 설정에서도 간단한 설정만으로 동일한 기능을 사용할 수 있습니다.

특히 Browserslist 설정을 통해 프로젝트의 브라우저 지원 범위를 명확히 하고, 필요한 프리픽스만 추가함으로써 최적화된 CSS를 생성할 수 있겠죠?!

.browserslistrc 파일을 사용하면 설정 관리가 더욱 용이해지며, 다른 도구들과도 설정을 공유할 수 있습니다.

여기서 "다른 도구들"은 주로 다음과 같은 CSS 또는 JavaScript 도구들을 의미합니다!

1. Autoprefixer: CSS에 필요한 브라우저 프리픽스를 자동으로 추가해주는 도구로, Browserslist 설정을 통해 어떤 프리픽스를 추가할지 결정 (지금까지 설명드린 내용이죠?!)
2. Babel: 최신 JavaScript 코드를 구형 브라우저에서도 작동할 수 있게 변환해주는 도구로, Browserslist 설정을 통해 지원할 브라우저 정의 가능
3. ESLint: JavaScript 코드의 품질을 관리하는 도구로, Browserslist와 함께 사용해 특정 브라우저 환경에 맞는 코드 스타일 적용 가능
4. Stylelint: CSS 스타일을 검사하는 도구로, Browserslist 설정을 참고하여 브라우저 호환성 관련 규칙 적용 가능

즉, .browserslistrc 파일을 사용하면 이러한 다양한 도구들이 동일한 브라우저 지원 범위를 공유하게 되어, 개발 및 유지보수 과정에서 일관성을 유지할 수 있습니다!