tab key를 사용해 header 영역에 있는 검색 버튼을 클릭했을 때 검색 모달창이 정상적으로 나오지만, 모달창의 마지막 요소를 지나면 html 문서에서 모달창 뒤에 오는 요소로 tab이 이동하는 문제가 생겼다. 어디에 focus 되었는지, 검색창을 닫지도 않았는데 뒤에 오는 내용이 맥락없이 읽힐 수도 있다.

문제 해결

tabindex?

tabindex로 tab 순서를 강제로 지정해줄 수는 있다. 하지만 포커스 순서를 제어하는 것은 피하는 것이 좋다. 키보드 포커스가 순서대로 이동하는 것이 아닌 중구난방으로 이동하게 될 경우 혼란을 줄 수 있다. 마크업으로 문서에 요소를 순서에 맞게 배치하는 것이 훨씬 좋다.

tabindex - MDN 공식문서

focus trap?

현재 보이는 모달창 내에서 tab key가 이동할 수 있도록 하기 위해 focus trap을 적용하였다. esc를 누르면 모달창을 닫을 수 있고, 닫은 후에는 focus의 위치를 원래의 위치(검색 아이콘)에 두었다. shift + tab 으로 이동하더라도 모달창 내에서만 이동하도록 했다.

function openSearchBox() {
  focusedElementModal = document.activeElement;

  // 포커스 가능한 요소들
  let focusableEls = $(searchBox).find(
    'a[href], area[href], input:not([disabled]), select:not([disabled]), textarea:not([disabled]), button:not([disabled]), iframe, object, embed, *[tabindex], *[contentditable]',
  );
  focusableEls = Array.prototype.slice.call(focusableEls);
  searchBox.on('keydown', trapTabKey);

  const firstTabStop = focusableEls[0];
  const lastTabStop = focusableEls[focusableEls.length - 1];

  firstTabStop.focus();

  searchBox.addClass('active');
  $('body').addClass('notscroll');
  searchBox.attr('aria-hidden', 'false');

  // 포커스 트랩 이벤트
  function trapTabKey(e) {
    // check Tab key
    if (e.keyCode === 9) {
      if (document.activeElement === firstTabStop && e.shiftKey) {
        e.preventDefault();
        lastTabStop.focus();
      } else if (document.activeElement === lastTabStop && !e.shiftKey) {
        e.preventDefault();
        firstTabStop.focus();
      }
    }

    // ESCAPE
    if (e.keyCode === 27) {
      closeSearchBox();
    }
  }
}

// 검색창 숨기기
function closeSearchBox() {
  searchBox.removeClass('active');
  $('body').removeClass('notscroll');
  searchBox.attr('aria-hidden', 'true');
  focusedElementModal.focus();
}

마치며

모달창 내의 포커스 이동을 통제할 수 있었지만, 검색 아이콘을 클릭하고 tab 키를 눌렀을 때 모달창의 첫 번째 요소로 이동하길 바랐으나 검색 아이콘과 형제 요소인 장바구니 아이콘으로 이동해버려서 이 부분은 추후 수정할 예정이다. 기본 뼈대인 마크업을 정확하게 해야 함을 매번 느끼지만 이번에도 다시금 느꼈다.

참고 사이트

https://lee-jing.tistory.com/19 https://tarot-story.tistory.com/23

네이티브 앱(Native app = 모바일 기기에 최적화 된)

스마트폰 운영체제에 맞춰 개발된 앱. 안드로이드, iOS에서 사용하는 언어를 이용해 개발.

장점

• 앱 실행 속도가 빠름
• 유용한 API 지원을 받을 수 있음
• 카메라, 페이스 인식, 연락처 조회 등 스마트폰 기본 기능들 활용 가능
• 각 운영 체제에 최적화되어 있어 안정적인 서비스 제공 가능
• 고성능 그래픽 처리 가능(2D, 3D, 증강현실 등)

단점

• 해당 플랫폼 별로 다른 언어를 사용함으로, 각 운영체제의 개발 언어를 알고 있어야 한다.
• 플레이 스토어 & 앱 스토어에 올려 심사를 받고 통과해야만 앱이 등록되기 때문에 번거로움
• 앱 업데이트 시 심사를 거쳐야 하기 때문에 업데이트 또한 번거로움
• 각 운영체제 별로 개발해야 하므로 개발 비용 발생

웹뷰(WebView)

네이티브 앱 내에 내제되어 있는 웹 브라우저이다. 앱을 벗어나지 않고도 웹 브라우저를 띄울 수 있다. 프론트엔드 개발자가 작성한 코드가 앱 내의 웹뷰 컴포넌트로 임베딩된다.

웹뷰를 사용하는 이유?

• 네이티브 앱 개발의 단점을 커버치기 위해 사용.
  • 앱 스토어 리스크 : 앱은 스토어를 통한 배포 프로세스이기 때문에 개발, 빌드 후 배포를 하더라도 바로 사용자에게 전달되는 것이 아니다. 각 스토어마다 앱의 가이드라인이 다르고 추후 정책이 바뀔 수 있기 때문에 리스크가 있음.
  • 버전 이슈 : 앱 최신 버전이 업데이트 되면 사용자들은 앱 버전 업데이트를 해줘야 하는데 자주 업뎃이 되면 사용자의 사용성이 떨어질 수 있다.
  • 개발자 풀 : 앱개발자들은 실제로 많이 없고, 회사에서도 잘 뽑지 않는다. 네이티브 앱 만으로 만들어진 거대한 서비스는 없다고 한다.
• 앱을 벗어나지 않는다는 점이 포인트. 유저들을 앱을 벗어나 다른 컨텐츠가 뜨게 되면 방금까지 사용하던 앱으로 돌아갈 확률이 감소하게 된다고 한다.
• 잘만든 웹뷰 화면들은 네이티브 앱인지 웹인지 분간이 어렵기 때문에 잘 만들면 서비스적 측면에서 더 나은 선택지가 될 수 있음.
• 더 많은 기능을 빠르게 제공(핵심!): 사용자들에게 기능들을 빠르게 제공하고 수정할 수 있다. 유저들의 피드백을 수용해 즉각적으로 반영하여 빠르게 서비스를 개선해 나갈 수 있다.

웹뷰가 일반 웹과 달라야 하는 점

웹 개발자가 일반적으로 개발하는 일반 웹과 네이티브 앱에 들어가는 웹뷰는 개발 성격이 살짝 다르다. 앱은 화면과 화면 간의 전환이 정말 빠르고 자연스럽게 이뤄지므로 프레임이나 렌더링 성능이 좋아야 한다. 만약 웹뷰로 만들어진 페이지에서 화면 전환 시 렌더링이 늦어진다면 사용자 경험은 떨어진다.

웹뷰는 빨라야 한다. 그러므로 웹뷰는 일반 웹과 달리 다른 성능 지표를 생각하며 개발해야 한다.

1. LCP(Largest Contentful Paint) : FCP(First Contentful Paint)와는 살짝 다르게 페이지의 가장 큰 컨텐츠 = 페이지의 주요 내용이 얼마나 빠르게 렌더링 되는지에 대한 지표
2. CLS(Cumulative Layout Shift) : 레이아웃이 얼마나 덜 끊기는지에 대한 지표. 컨텐츠를 보다가 갑자기 이미지가 나중에 렌더링되서 뚝 끊기는 현상을 줄여야 한다.
3. FID(First Input Delay) : 사용자와 인터랙션(터치, 드래그 등등)에 따라서 얼마나 빠르게 반응하는지를 요구하는 지표.

출처

크로스 플랫폼 프레임워크(cross-platform frameworks)

한 가지 개발 언어와 프레임워크로 ios, 안드로이드 양쪽 스토어에 출시할 수 있는 개발 방법. 둘 이상의 플랫폼에서 돌아가는 앱을 만들 수 있다.

예) 구글 Flutter, 페이스북의 React Native

장점

• 코드를 하나만 작성하면 양쪽 스토어에서 모두 사용할 수 있어 시간을 줄 일 수 있음
• 빠른 개발 가능
• 하나의 코드로 작성하기 때문에 유지보수 용이

단점

• 기존 네이티브 앱이 가지고 있는 동적인 요소 퍼포먼스를 100% 구현할 수 없음
• 네이티브 앱에 비해 성능이 떨어져 느린 경우가 있음
• 라이브러리가 다양하지 않아 기능 구현에 어려움이 있을 수 있음
• 업데이트 지연 발생 가능

모바일 웹 앱

네이티브 앱처럼 보이고, 기능 또한 앱과 동일하게 구현되지만 웹 기술을 활용하여 만들어진 앱을 '웹앱'이라 한다. 네이티브 앱과 달리 웹 기반의 html, css, js 등을 활용하며, 별도의 앱 파일을 설치하지 않고 인터넷 브라우저 기반으로 작동된다.

앱 없이 인터넷을 통해 구동되는 것을 보면 일반 모바일 웹과 똑같은 것이라 느낄 수 있지만, 두 가지의 차이가 약간 있다.

• 모바일 웹 : PC를 기준으로 제작된 뒤 모바일 화면 규격에 맞게 폰트나 이미지 등을 바꾼 것.

• 웹 앱 : 처음부터 모바일을 기준으로 제작되어 이용자에게 훨씬 편안한 환경을 제공한다. 하지만 설치하는 앱이 아니므로 카메라나 음성 등 디바이스 자체 기능에 접근할 수는 없다.

++ 차이점 실행 방식에 차이가 있다. 모바일 웹은 화면의 일부분이 바뀔 때 전체를 서버에서 새롭게 불러오는 풀 브라우저방식, 웹앱은 변경이 필요한 부분만 바꾸는 단일 페이지 방식(Single page application)을 사용. 따라서 모바일 웹이 웹앱보다 속도가 느리다는 특징이 있음.

• 웹앱 : 모바일 화면도 구성한 웹

• 모바일 앱 : 모바일 화면만 구성한 앱

++ 차이점

인프콘 웹뷰 영상

하이브리드 앱(Hybrid app)

웹과 앱의 장점을 하나로 합침. 하이브리드 앱은 네이티브 앱 + 웹앱 개발 방식을 모두 사용한다. 앱의 화면이나 기능 등 콘텐츠 영역은 웹 기반으로 제작하고 겉모습은 앱 마켓 등록과 설치를 위해 네이티브 앱으로 포장함. 두 가지 개발 방식을 이용하므로 웹과 앱의 API 모두 사용 가능하다. 따라서 웹앱에서는 불가능 했던 디바이스 자체 기능에 접근할 수 있게 된다.

장점

• 웹 기술을 기반으로 제작되지만, 모바일 API도 사용할 수 있으므로 디바이스 자체 기능을 활용할 수 있음
• 네이티브 앱에 비해 개발 비용 및 시간 절약 가능
• 한 번 개발해두면 패키징을 바꾸는 방식으로 여러 플랫폼에 대응 가능

단점

• 네이티브 앱 개발 지식 필요
• 브라우저의 성능이 떨어지면 앱 구동 속도 저하됨
• 네이티브 앱에 비해 디자인의 자유도가 떨어짐

SDK

software development kit. 어떤 소프트웨어를 만들기 위한 도구 모음. 그 도구 안엔 API도 있을 수 있다.

예) ios SDK를 다운받으면 개발자에게 ios 어플리케이션을 만드는데 필요한 모든 도구가 제공된다. 아이폰 시뮬레이션을 할 수 있는 시뮬레이터도 제공됨.

API

application programming interface. 모듈화되어 만들어진 것으로, 어떤 기능을 제어하거나 제공하는 인터페이스를 말함. 대부분의 어플리케이션은 API에 의존하고 있다.

예) 업로드 버튼을 클릭하면 업로드 된다거나, 계산기를 이용해 값을 얻을 수 있는 것.

1. HTML5 W3C(Markup Validation Service)

2. CSS W3C(CSS Validation Service)

Web Accessibility

1.한국형 웹 콘텐츠 접근성 지침 [웹 접근성 연구소](한국형 웹 콘텐츠 접근성 지침 2.2)

2. OpenWAX OpenWAX(Open Web Accessibility eXtension)

3. WAVE WAVE Web Accessibility Evaluation Tools

4. sitero(명도 대비 검사) sitero

웹호환성

Can I use

Cross Browsing

Browserstack

Lighthouse

구글에서 만든 웹페이지의 품질 개선을 위한 오픈소스 자동화 도구. 아래 5가지의 항목별 지표를 확인할 수 있으며 웹사이트의 성능 개선을 위한 지침도 함께 제공한다.

• 퍼포먼스(성능)
• 접근성
• 웹표준
• SEO
• PWA

Lighthouse

• 내용을 알 수 없는 이미지

• 이미지를 볼 수 있는 특정인과의 사적인 문서(사이트, 이메일)에 사용된 이미지
• 장식 이미지에 alt="" 대신 role="presentation" 사용

위와 같은 특별한 경우를 제외하고 거의 모든 경우에 alt 속성을 사용한다.

출처 - img태그 alt 속성 써야할까?

Heading과 Sectioning elements

Heading elements <h1>-<h6>

• 폰트 사이즈를 이유로 태그를 사용하지 말고, 의미있는 태그로 사용할 것.

• <h1>, <h2>, <h3> ... 순차적으로 사용할 것.
• 페이지 당 하나의 h1만 사용할 것을 권장. 여러 <h1> 사용이 가능하긴 하지만 접근성과 SEO를 위해 되도록이면 <h1> 하나만 사용.

출처 : MDN) The HTML Section Heading elements

Sectioning elements

<header>, <footer>, <main>, <article>, <section>, <nav>, <aside>

위의 section 요소들에는 반드시 heading tag가 포함되어야 한다. 위치에 상관없이 section 요소 내에 포함하기만 하면 되는 것 같다.

출처 : MDN) section content

svg

SVG란? : Scalable Vector Graphics. XML 기반의 2차원 벡터 그래픽으로 HTML 요소로 이뤄져 있어 CSS와 Javascript로 컨트롤이 가능하다. 벡터이기 때문에 확대하거나 크기를 키워도 이미지가 깨지지 않으며 용량도 늘어나지 않는다.

다만, 그래픽을 수학적 연산으로 그려낸 이미지이기 때문에 복잡한 형태일수록 사이즈가 커질 수 있다. 단순한 아이콘이나 로고, 도형을 구현할 때 사용된다.

svg 사용법

svg 코드를 직접 수정하여 이미지를 컨트롤 해야할 경우 - 3, 4번 이미지를 직접 컨트롤 하지 않을 경우 - 1, 2번

1. img 요소의 src에 이미지 경로로 작성하는 방법
2. css background 이미지로 넣는 방법
3. svg 코드를 복붙하여 HTML 안에 넣는 방법
4. object 요소 안에 넣는 방법

스크린 리더와 관련된 속성과 태그

aria-hidden

• 웹 접근성을 개선하기 위해 사용되는 속성으로, 해당 요소의 시각적인 표현 여부를 스크린 리더 등 보조 기술에 전달함.
• true/false의 속성값을 가짐.

aria-hidden="true" // 스크린 리더가 읽지 않음
aria-hidden="false"  // 스크린 리더가 읽음

true는 다음과 같은 경우 추가하면 안된다고 mdn 사이트에 나와있다.

• html hidden 속성이 존재하는 경우
• 요소 또는 요소의 조상이 display: none 으로 숨겨진 경우
• 요소 또는 요소의 조상이 visibility: hidden 으로 숨겨진 경우

출처 : MDN) aria-hidden

display: none

i 태그

i 태그 자체는 스크린 리더에서 읽히지 않는다. i 태그는 주로 아이콘 같은 비의미적인 스타일을 적용하기 위해 사용되지만, 스크린 리더는 이런 스타일을 무시하고 의미 있는 컨텐츠만 읽는다.

<i class="icon">🔍</i>

위와 같이 유니코드 이모지를 사용하는 경우, 스크린 리더는 일반적으로 이모지의 유니코드를 읽지 않고, 대신에 브라우저에 내장된 기본 음성 표현을 사용해 해당 이모지를 설명한다.

따라서 🔍 는 스크린 리더에게 돋보기 또는 관련된 용어로 읽힌다고 한다.

만약 정확한 아이콘의 의미를 전달하고 싶다면, 적절한 대체 텍스트나 ARIA 속성을 사용하면 된다.

role 속성 사용:
<i class="ic-cart" role="img" aria-label="장바구니 아이콘"></i>

aria-label 속성 사용:
<i class="icon" aria-label="Search"></i>

OS : ctrl + shift + / Windows : cmd + shift + /

전체 피그마 UI 표시/숨기기

OS : cmd +
Windows : ctrl + \

이름 한번에 변경

OS : cmd + R Windows : ctrl + R

요소 다중 선택 후 Rename + $NN(오름차순 넘버)/$nn(내림차순 넘버)

Quick actions

ctrl + /

layout show/hide

shift + G

최상단에 nav와 로고 등이 있는 header 영역(바로 위에는 이벤트 배너가 있는 구조)이 position:relative 값을 먹고 있고, 아래로 스크롤 했을 때 fixed로 변경해서 고정해야 하는데 스크롤 시 부자연스럽게(띡박거림) 상단에 fix 되었다. 스무스하게 header가 제자리에 챡- 붙었으면 좋겠어서 찾아봤다.

컨텐트 영역의 위치 간격주기

header 영역은 그대로 두고, content 영역에 header의 height 만큼의 top 위치를 줘서 스크롤 되면서 header가 점프하듯이 기존의 위치에서 최상단에 fix될 때, 그 사이 간격을 띄우면 자연스럽게 붙게 된다.

content 영역의 위치를 변경하는 것이기 때문에 기존의 content의 위치에 따라 레이아웃에 영향을 줄 수 있다.

stackoverflow) Smooth scroll header with fixed position

2. font-smooth

  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;

웹폰트를 부드럽게 사용하기 위해 css의 font-smoothing 속성을 사용. 이 속성을 사용하면 브라우저에 표현되는 텍스트가 렌더링 될 때 좀 더 부드럽게 표현이 된다. 표준 속성은 아니라서 모든 브라우저 및 환경에 적용되지는 않는다. Safari 및 Mac 등에서는 완벽하게 구현되지만 이외에는 제한적으로 사용된다.

출처 - MDN) font-smooth

3. scroll chanining

사이드바를 만들고 스크롤을 할 때 사이드바가 전부 스크롤 되면 메인 화면이 스크롤이 된다. 왜 메인 화면까지 스크롤이 되냐하면, 스크롤이 되지 않는 부분에서 스크롤을 했을 때 부모 요소로 스크롤이 전달되기 때문이라고 한다. 이런 현상을 스크롤 체이닝(scroll chaining)이라 한다.

이러한 현상을 해결하기 위한 css의 <overscroll-behavior> 속성이 있다.

overscroll-behavior

스크롤이 끝까지 갔을 때 스크롤이 전달되는 것을 막는 속성이다.

overscroll-behavior: auto | contain | none;

출처 - MDN) overscroll-behavior 출처 - 정현수님 스크롤체이닝 포스트

scrolling 막기 (css + js)

모달창을 띄워서 뒤의 컨텐트의 스크롤을 막거나 사이드바+오버레이로 반쯤 뒤에 가려진 컨텐트의 스크롤을 막는 방법

1. 모달창 스크롤 막기

  overflow: hidden;
  touch-action: none;

클래스명을 지정해주고 javascript에서 모달창을 열었을 때, body 부분에 클래스를 준다.

  document.body.classList.add('notscroll');

2. 사이드바 스크롤 막기

  position: fixed;
  top: 0;
  left: 0;
  width: 100%;

위와 마찬가지로 사이드바를 열었을 때, body 부분에 클래스를 주면 된다.

4. truncate

 white-space: nowrap;
 overflow: hidden;
 text-overflow: ellipsis;

텍스트가 길어서 부모 요소의 너비 크기를 벗어나 바깥으로 튀어나가는 한 줄인데 부모 너비 밖의 잘린 텍스트는 숨기고 말 줄임표를 붙여야 할 때 위의 코드를 사용.

출처 - Dales

5. transition과 css property

요소에 움직임을 주고 싶을 때 간혹 transition이 먹히지 않는 경우가 있다. 모든 css property가 대상이 되지는 않기 때문이다. 그 이유는 브라우저 동작과 관련 되어 있다.

대상이 될 수 있는 css property

// Box model
width height max-width max-height min-width min-height
padding margin
border-color border-width border-spacing

// Background
background-color background-position

// 좌표
top left right bottom

// 텍스트
color font-size font-weight letter-spacing line-height
text-indent text-shadow vertical-align word-spacing

// 기타
opacity outline-color outline-offset outline-width
visibility z-index

출처 - 이웅모님 Poiemaweb) css3-transition

6. visibility와 display 차이

요소를 화면에 보이지 않게 하기 위해 위의 속성을 자주 사용하게 되는데, 단순히 보이고 안 보이고의 차이만 있는 것은 아니다. 요소가 차지하고 있던 공간을 그대로 유지하느냐의 차이가 있다.

visibility: hidden | visible | collapse;

<display: none> 을 줄 경우, 그 요소가 차지하고 있던 공간도 함께 숨겨지게 된다. 그 다음으로 오는 요소가 숨겨진 요소의 자리를 대신 차지하게 된다.

<visibility: hidden> 을 줄 경우, 요소가 차지하고 있던 공간을 그대로 유지한 채 숨김 처리 된다.

출처 - MDN) visibility

7. overflow

• 내부 요소가 부모의 범위를 벗어날 경우 어떻게 처리할지 지정하는 속성.

• 속성이 효력을 갖기 위해서는 반드시 block level의 width나 height의 값을 설정해줘야 한다.

출처 - MDN) overflow

2. display : none

요소를 보이지 않게 하는 속성. 화면에 보이지 않을 뿐만 아니라 스크린리더도 읽지 못함.

overflow:hidden, display:none의 차이

overflow:hidden일 경우 -> 숨김처리, 스크린리더가 읽을 수 있음. display:none일 경우 -> 숨김처리, 스크린리더가 읽을 수 없음.

8. margin: 0 auto 가운데 정렬 안되는 이유

1. width 선언 여부

요소의 width를 선언하지 않았을 경우, margin: 0 auto;가 작동하지 않는다. 만약 width를 선언하고 남은 공간이 있다면 margin으로 자동으로 채우게 되는데,

left, right 를 auto로 하게 되면 margin을 사이좋게 나눠가지게 되면서 가운데 정렬 된다. 부모 요소에 margin: 0 auto;를 줬는데 가운데 배치가 되지 않는다면 부모 요소의 width를 선언했는지 확인한다.

2. box-type이 inline 일 경우

display: inline;은 margin-left, margin-right이 먹히지 않는다.

3. li 안에 a 태그 클릭 영역

메뉴 컴포넌트 만들 때 li 태그 안에 a 태그를 넣어서 사용하는 경우가 많은데, padding을 줘야 할 때 li에 주지 않고 a 태그에 줘야 클릭 영역이 넓어져서 빈 공간을 클릭했을 때에도 link 이동이 가능해진다.

9. z-index

Position된 요소들의 수직방향으로의 레벨을 알려주는 속성. 레이어층으로 이뤄진 요소들을 어느 레벨로 위치시킬건지 정한다. 정수값을 적어주면 되는데, 정수값이 커질수록 상위 레벨에 속한다.

10. img 태그

img는 inline box-type이지만 width와 height 값을 주면 사이즈 조절이 된다. 아마 이미지 파일 자체가 가지고 있는 이미지 사이즈가 있기 때문에 그럴텐데, 명시적으로 display:block을 해주면 스타일 오차를 줄일 수 있다. block으로 바꿔주면 개발자도구의 box-model 패널을 보면 content 부분의 값이 지정해준 값으로 딱 맞춰진다.

11. text-align

block 내에 있는 inline 요소(텍스트 포함)을 정렬할 때 사용하는 속성. span이나 strong과 같은 inline 태그에 text-align 속성을 주고 싶다면 display:block 을 주면 된다.

13. text hidden

font-size: 0;
overflow: hidden;
text-indent: 100%;
white-space: nowrap;

text-indent: -9999em;

14. position : sticky

sticky로 고정된 첫번째 요소가 스크롤 위치에 따라 상단에 고정(sticky)된 상태에서도, 뒤에 오는 형제 요소들은 첫번째 요소가 원래 자리한 위치를 인식한다. 그래서 스크롤에 따라 뷰포트 내에서 고정되는 것처럼 보이지만, 레이아웃 상에서는 여전히 원래 자리의 공간을 차지하고 있기 때문에 바로 뒤에 오는 형제 요소들이 바로 이어져 보이지 않고 약간의 공백이 보이게 된다.

15. aspect-ratio가 작동되지 않는 이유

aspect-ratio

npm i http-proxy-middleware

src/ setupProxy.js src 폴더 안에 setupProxy.js 을 두고

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function (app) {
   app.use(
      createProxyMiddleware('/v1/search/book.json', {
         target: 'https://openapi.naver.com',
         changeOrigin: true,
      }),
   );
   app.use(
      createProxyMiddleware('/api', {
         target: 'http://localhost:3000/',
         changeOrigin: true,
      }),
   );
};

위와 같이 설정해줬다. 사용할 api 가 여럿인 경우 위처럼 사용하면 된다. 404 에러코드는 주소 설정이 잘못된 것이고, 400인 경우 쿼리를 넘겨주면 제대로 받아온다.

참고 링크

CORS 가 뭔데 CORS 에러 어떻게 해결하는건데 리액트에서 프록시 여러 개 설정하는 방법

→ 위의 방법은 로컬 개발환경에서는 제대로 동작하나, 배포했을때 api 응답이 html 페이지를 받아오는 문제가 있었다..

Netlify 배포 시 api 호출 시 html 페이지로 응답되는 문제

아무리 코드를 고쳐봐도 문제의 원인이 어디서 나온 것인지 정확히 파악하지 못해 의심가는 부분들을 테스트 해봤다. 심지어 400, 404, 500 같은 HTTP 에러가 뜬 것도 아니여서 멘붕이 왔다. 개발자 도구의 네트워크 탭에서 api 통신 요청과 응답을 하나하나 뜯어보니 아래의 1, 2번 문제는 아니었다. 정상적으로 request 되었고 env 변수도 알맞게 들어갔다. 응답이 왜 원하는 대로 되지 않는지…

1. 네이버 api url 잘못 설정
2. env 변수 잘못 입력
3. Proxy 에러
4. axios 통신 코드 문제

3, 4에서 분명히 문제가 있을 것이라 판단했고, 맨 하단의 링크들을 참고하여 코드를 수정했다.

setupProxy.js 파일을 삭제하고 netlify.toml 파일을 새로 생성하여 proxy 설정을 따로 해줬다.

// netlify.toml
[[redirects]]
  from = "/proxy/*"
  to = "https://openapi.naver.com/:splat"
  status = 200
  force = true

  [[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200
    force = false

// Search.jsx
const PROXY = window.location.hostname === 'localhost' ? '' : '/proxy';
const URL = `${PROXY}/v1/search/book.json`;

const instance = axios.create({
      headers: {
         'Content-Type': 'application/json',
         Accept: 'application/json',
         'X-Naver-Client-Id': process.env.REACT_APP_NAVER_CLIENT_ID,
         'X-Naver-Client-Secret': process.env.REACT_APP_NAVER_CLIENT_SECRET,
      },
   });

async function fetchData(query) {
      try {
         const response = await instance.get(URL, {
            params: {
               query: query,
               display: 60,
               ...

인스턴스를 생성해준다. 여기서 공부가 부족하다고 느꼈던게, 처음에는 인스턴스를 생성하지 않고 get으로 받아오려고만 해서 제대로 api 요청이 되지 않았던 것 같다. 문제를 해결하느라 엄청난 시간을 쏟아버렸고 문제의 원인을 제대로 파악하지 못해 시간이 걸린 이유도 있었다. 네트워크 통신 공부해야겠다…😥

참고 링크

Create React App - Proxy Netlify 공식 문서 참고 블로그 링크1 참고 블로그 링크2

도메인 연결하기

netlify로 배포한 프로젝트 연결

포폴 사이트는 리액트로 만든 프로젝트고 netlify로 배포했다. netlify 공식 사이트에 들어가서 로그인하면 배포한 프로젝트들을 확인해볼 수 있다. 도메인 연결할 프로젝트의 설정으로 들어가보면 배포가 완료된 프로젝트일 경우 현재 2단계라고 표시가 되어있을거다. 이제 여기에 도메인 주소를 입력해줘야 한다.

도메인 주소 구매하기

나는 gabia에서 도메인 주소를 구매했다. 등록하려는 주소가 이미 등록된 상태였기 때문에 .shop으로 끝나는 도메인 주소를 할인된 가격으로 550원에 구매했다. 도메인 등록 사이트를 찾아보니 gabia, 카페24 등을 보통 많이 사용하는 것 같다. 무료로 도메인을 등록할 수 있는 Freenom도 있는데 안정적이지 않다는 글이 있었다. 여러군데 비교해서 선택하면 된다.

SEO 점수 확인하기

아래 사이트에서 주소를 입력하면 사이트를 분석해서 SEO 점수가 어떠한지 알려준다. 계정없이 무료로 사용할 경우 하루에 1개의 사이트만 확인 가능한 것 같다. seositecheckup

사이트맵 작성

sitemap.xml을 다운로드 받은 후 구글 서치 콘솔 > sitemap 메뉴로 들어갑니다. 검색엔진 크롤러가 사이트맵을 찾을 수 있도록 검색엔진별로 제출하는 것이 필요하다.

위와 같이 했는데 구글 검색하면 검색 결과에 내 사이트가 나오긴 했다. 성공! 그런데 사이트 접속해보니 sitemap 그대로 출력되고 결과물은 보이지 않는다. 사이트맵이 제대로 설정되지 않은 것이라 생각되서 뒤이어 포스팅을 올리겠습니다.

리액트 프로젝트 사이트맵 생성

yarn add react-router-sitemap

+ 후기

다른 프로젝트 하느라 며칠 뒤에 다시 구글 검색해보니 정상적으로 사이트가 보였다! 제대로 설정한 것인지는 모르겠으나 사이트맵 등록하고 나서 정상적으로 나오지 않을 수 있다는 글을 어디선가 읽은 것 같다. 며칠 지나야 한다는 것 같기도 하고... 그래도 어쨌든 뿌듯하다!

도움 받은 사이트

사이트맵(sitemap.xml) 쉽게 만들고 제출하기! xml-sitemaps

SEO를 알아보기 전에, 검색이 어떤 방식으로 동작하는지 소개하는 글이 있어 이해를 돕기 위해 간단하게 적어봤다.

구글 검색의 작동 방식

구글 검색은 자동화된 검색엔진인 웹 크롤러라는 소프트웨어를 사용하여 정기적으로 웹을 탐색한다. Google 색인에 추가할 페이지를 찾는데, 검색결과에 표시되는 페이지의 대부분 사이트 소유자가 검색결과를 위해 사이트를 직접 제출한 것이 아닌 Google 웹 크롤러가 웹 탐색시 발견한 사이트를 자동으로 추가한 것이다.

구글 검색 3단계

1. 크롤링 : 크롤러라는 자동화된 프로그램(Googlebot)을 사용해 인터넷에서 찾은 페이지로부터 텍스트, 이미지, 동영상을 다운로드

   발견한 페이지를 모두 크롤링하는 것은 아니다. 사이트 소유자가 크롤링을 허용하지 않는 페이지도 있고, 사이트에 로그인해야 액세스할 수 있는 페이지도 있다. 웹 사이트 중에는 자바스크립트를 사용해 페이지에 콘텐츠를 표시하는 경우가 많은데 크롤링하는 동안 Google은 페이지 렌더링시 발견된 자바스크립트를 실행하여 콘텐츠를 확인한다.

2. 색인 생성 : 페이지의 텍스트, 이미지, 동영상 파일을 분석하고 대규모 데이터베이스인 Google 색인에 이 정보를 저장

   페이지 내용을 파악하기 위한 단계를 색인 생성이라 하는데 title 요소 및 Alt 속성, 이미지, 동영상 등 텍스트 콘텐츠 및 핵심 콘텐츠 태그와 속성을 처리하고 이를 분석한다. 색인 생성은 페이지 콘텐츠 및 메타데이터에 따라 달라지는데, 페이지의 콘텐츠 품질이 낮거나 Robots meta 규칙이 색인 생성을 허용하지 않는다거나 웹사이트 디자인에 따라 색인 생성이 어려울 수 있다.

3. 검색결과 게재 : 사용자가 검색 시 사용자의 검색어와 관련된 정보를 반환

   Google 컴퓨터는 색인에서 일치하는 페이지를 검색해 품질이 가장 높고 사용자의 검색어와 가장 관련성이 크다고 판단되는 결과를 반환한다. 관련성은 사용자의 위치와 언어, 기기(데스크탑 or 핸드폰)와 같은 정보를 비롯한 수많은 요인으로 결정된다.

Google 검색 작동 방식 검색 UI 요소

검색 엔진 최적화(Search Engine Optimization, SEO)✨

웹페이지 검색 엔진이 자료를 수집하고 순위를 매기는 방식에 맞게 웹페이지를 구성해서 검색 결과의 상위에 나올 수 있게 한다. 웹페이지와 관련된 검색어로 검색한 검색 결과 상위에 나오게 된다면 방문 트래픽이 늘어나기 때문에 효과적인 인터넷 마케팅 방법 중의 하나이며 비용처리 없는 마케팅이라고 할 수 있다. 출처 : 위키피디아

사용자에게 도움이 되는 웹사이트를 빌드하고 사용자 환경을 개선하는 것을 목표로 최적화해야 한다.

사용자에게 정확한 콘텐츠 제공하기

고유하고 정확한 페이지 제목

title 요소로 사이트의 각 페이지에 고유한 제목과 주제를 명확히 작성. title 요소의 텍스트가 너무 길거나 관련성이 낮으면 텍스트의 일부만 표시하거나 검색결과에 자동으로 생성된 제목 링크를 표시할 수 있다.

<html>
<head>
    <title>Brandon's Baseball Cards - Buy Cards, Baseball News, Card Prices</title>
    <meta name="description" content="Brandon's Baseball Cards provides a large selection of
    vintage and modern baseball cards for sale.
    We also offer daily baseball news and events.">
</head>
<body>
...

메타 설명 태그 사용

페이지의 meta 설명 태그는 페이지 내용을 요약하여 제공한다. 이 메타 태그를 검색결과에서 페이지의 스니펫으로 사용할 수 있다. 사용자가 site: 검색 연산자를 사용해 검색했을 때 검색에 도움이 될 수 있다. description meta 태그 길이의 최솟값과 최댓값은 없다.

콘텐츠 설명 작성 시 권장 사항

1) 흥미롭고 정확하게 콘텐츠를 요약한 설명 2) 표제 태그(h1 ~ h6) 사용하여 중요한 텍스트 강조

자세한 문서는 우수한 메타 설명을 만드는 방법 을 읽어보면 되겠다.

사이트 계층 구조 구성하기

사이트 구성 권장 사항

1) url에 단어를 사용하면 사이트의 콘텐츠와 구조를 빠르게 파악할 수 있다. 2) 간단한 디렉토리 구조

단순한 URL을 사용해 웹사이트 문서와 관련된 설명을 제공하는 카테고리 및 파일 이름을 만들면 사이트를 더 잘 구성할 수 있고 콘텐츠를 보는 사용자가 쉽게 이해하여 읽을 수 있다.

<!-- 파악하기 어려운 url -->
https://www.brandonsbaseballcards.com/folder1/22447478/x2/14032015.html

<!-- 파악하기 쉬운 url -->
https://www.brandonsbaseballcards.com/article/ten-rarest-baseball-cards.html

이미지 최적화하기

HTML 이미지 사용

• HTML img 또는 picture 요소를 사용한다. 시맨틱 HTML 마크업을 사용하면 크롤러가 이미지를 찾고 처리할 수 있다. picture 요소를 사용하여 반응형 이미지를 위한 다양한 화면 크기에 여러 옵션을 지정할 수도 있다. 이미지에 landing="lazy" 속성을 사용하면 사용자가 페이지를 더 빠르게 로드할 수도 있다.
• alt 속성 사용
• JPEG, GIF, PNG, BMP, WebP 의 표준 이미지 형식 사용

모바일 친화적인 사이트 만들기

1. 반응형 웹디자인
2. 모바일 버전의 별도 URL

Google 검색엔진 최적화 기초

마치며

구글 공식 문서를 참고한 것이라 SEO를 제대로 숙지했다고 보기는 어려울 것 같다. 그래도 기본적인 이해를 하는데 도움이 되었고 구글 검색을 사용하는 경우가 많기 때문에 유용한 정보를 얻을 수 있었다. 크롤링 개념과 크롤러가 어떻게 활용되는지 또한 알 수 있었다.

auth-service.js에는 Firebase Authentication을 처리하는 로직이 들어있다.

// auth-service.js
class AuthService {
   constructor(app) {
      this.firebaseAuth = getAuth(app);
   }

   logout() {
    // 로그아웃 
   }

   emailSignIn(email, password) {
        // 이메일로 회원가입
   }

   checkedEmailPassword(email, password) {
     // 로그인 시 가입한 정보와 일치하는지 확인 후 home으로 이동 
   }

회원가입과 로그인, 로그아웃을 담당하는 class인데 여기서 문제가 발생했다. checkedEmailPassword() 함수에서 서버로부터 데이터를 받아온 뒤, 가입한 정보가 로그인할 때 입력한 정보와 같으면 페이지 이동을 해야했다.(같지 않으면 switch 문을 이용해 error.code에 따라 각각의 에러메시지를 띄우도록 했다.)

Authentication을 처리하는 로직을 class로 작성한 이유는 login, signin 컴포넌트 뿐만 아니라 profile, post 컴포넌트에서도 이 데이터가 필요하기 때문에 class를 사용한 것이고, function 컴포넌트로 작성하자니 코드 양이 많아질 것 같았다.. 최대한 class 컴포넌트를 사용하되, 페이지 이동도 가능하도록 구현하고 싶어서 class 컴포넌트에서 사용할 수 있는 navigation이 있을까 찾아봤다.

참고한 링크 : https://dbstndi6316.tistory.com/366 https://github.com/remix-run/react-router/issues/8146

1. 클래스 컴포넌트 파일 내에서 useNavigate 사용하는 방법

// in hocs.js
function withNavigation(Component) {
  return props => <Component {...props} navigate={useNavigate()} />;
}

function withParams(Component) {
  return props => <Component {...props} params={useParams()} />;
}

// in BlogPost.js
class BlogPost extends React.Component {
  render() {
    let { id } = this.props.params;
    // ...
  }
}

export default withParams(BlogPost);

깃허브 질문에 달린 답변 중에 위 코드로 시도해봤으나 내 코드(아래 코드)는 index.js에서 firabaseApp을 넘겨 받아야하기 때문에 에러가 발생했다..

2. navigate를 인자로 전달하는 방법

// index.js
const authService = new AuthService(firebaseApp);

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
   <ThemeProvider theme={theme}>
      <App authService={authService} />
   </ThemeProvider>,
);

다른 방법이 없을까 열심히 찾아봤는데 class 컴포넌트에서 navigate를 사용하는 방법보다는 function 컴포넌트에서 사용하는 걸 권장한다는 글이 있었던 것 같다. 비록 깊지 않은 지식을 갖고 있지만 꼭 해결하고 싶어서 내 코드를 열심히 뜯어봤다. 깃허브에 달린 답변을 힌트 삼았다.

// Login.jsx
const navigator = useNavigate();
authService.checkedEmailPassword(navigator, userEmail, userPassword);

navigator 변수에 useNavigate() 함수를 할당해 checkedEmailPassword() 함수의 인자로 전달하는 방법을 시도했다. 확인 결과, 문제없이 잘 동작했다. 더 나은 방법이 있을 수도 있겠지만 현재로서는 최선의 방법으로 해결했다!

구현 화면