그런데 앱에 기능을 넣을 일이 점점 늘어나면서 웹을 React로 개발하면서 앱을 Flutter로 개발하기에는 그만큼 새로 공부를 해야하기 때문에 효율이 안나온다고 생각했다. 이후 새로 들어온 프론트 개발자와 이야기하면서도 언젠가 React native로 바꾸자고 이야기를 했는데, 결국 그분이 퇴사하실 때까지도 일이 바빠 전환하지 못했고, 최근에야 총대를 메고 전환을 해버렸다.

전환하면서 어차피 네이티브 설정들은 똑같을 텐데..하며 AndroidManifest 파일을 그대로 복사를 해서 원링크를 작동시켜봤는데, 앱이 설치돼있어도 스토어로만 이동을 하고 앱이 열리지 않는 문제가 발생했다.

나는 위 AndroidManifest 파일이 문제일거라 생각은 못하고 자꾸 앱스플라이어 원링크 설정을 만지고 있었다. 그래도 해결하지 못했고

결국 안되면 문서를 처음부터 다시 볼 수 밖에 없다.

그래서 찾아낸 부분은 이 부분이었다.

<data android:scheme="app-name" />

위 부분을 아래와 같이 바꾸니까 제대로 작동을 했다.

<data android:scheme="app-name" android:host="*" />

운영팀에 혹시 기존에 사용했던 링크들이 정상 작동했었나 물어봤는데, 아무도 모르고 있었다. 당시에 나도 관심을 가졌어야 했는데 내 일이 바빠서 관심을 못가졌었다...이 부분을 반성하고. 그래서 노션에 히스토리를 남겼고, 여기로도 옮겨본다.

우리 서비스는 웹으로 개발 후에 Flutter 웹뷰로 띄워서 서비스 하고 있다. (웹뷰 띄울 땐 inappwebview를 사용하고 있다.) 이번에 결제 기능을 붙여야해서 토스 결제위젯을 붙였다.

커스텀 할 게 없기 때문에, 토스의 가이드를 보고 그대로 따라 했는데, KB은행 서비스로 결제하려고만 하면 ERR_UNKNOWN_URL_SCHEME 에러가 발생을 하는 것이었다. 문제는 에러화면이 뜨고 그 다음 작업은 이어 나간다는 것..(앱이 없으면 스토어로 간다던가)

토스 개발자분들에게 질문했으나 재현이 안돼서 더 할 수 있는게 없었다.

이틀간 꼬박 삽질을 하다가, 문득 이건 아닐거야..(왜냐면 이 문제 해결기에선 Inappwebview의 버전이 5.4.3 이전일 때 발생한다고 하셔서)라고 참고를 안했던 글이 떠올랐다.

해당링크

if (Platform.isAndroid) {
    await _convertIntentToAppUrl(currentUrl).then((value) async {
        currentUrl = value;
    });
        try {
          // 추가된 부분
          if (!navigationAction.isForMainFrame) {
              await controller.stopLoading();
          }
          //
              await launchUrlString(currentUrl);
        } catch (e) {
          currentUrl = await _convertIntentToMarketUrl(uri.toString());
          await launchUrlString(currentUrl);
        }
    } else if (Platform.isIOS) {
        await launchUrlString(currentUrl);
}

위 코드 처럼 수정하고 InAppWebViewGroupOptions에 resourceCustomSchemes: ['intent'] 추가, shouldOverrideUrlLoading 에 아래 코드 추가했더니 해결됐다.

onLoadResourceCustomScheme: (controller, url) async {
     await controller.stopLoading();
     return null;
},

셋 중 하나라도 빠지면 안되더라.

테스트를 더 하다가 페이북/ISP 앱이 없을 때 앱 다운로드 하러가기 버튼을 클릭했더니 또 ERR_UNKNOWN_URL_SCHEME 에러가 발생했다. Intent를 보니 fallback url이 있길래, fallback url이 있으면 그걸 리턴하고 아니면 intent.dataString을 넘기는 식으로 처리했다.

휴...어려워라

이걸 지우니 shouldOverrideUrlLoading 가 호출됐다.

나름 급한 이슈였기 때문에 프론트엔드 두 명 모두 붙어야 했다. 특정 OS 패치에서만 발생하는 이슈였고, 좀 막막했던 것은 사실이다. OS문제를 어떻게 하지??

문제가 됐던 부분은 셀렉트 박스에서 고객을 선택하면 클릭 이벤트와 블러 이벤트가 발생하는 상황에서 특정 패치에서만 블러 이벤트가 발생했을 때 고객 정보가 바인딩 되지 않는 부분이었다.

로그를 찍어보다가 왜 해당 패치에서만 그러는걸까? 라는 의문은 제쳐두고, 왜 블러 이벤트가 발생하는 거지? 라는 생각을 했다. 블러 이벤트가 필요한게 아니라면? 증상이 아니라 병을 고치면 해결될 일이었다.

그래서 혹시 이전에 고객을 다수 선택한 적이 있냐고 물었고 아니라는 답변을 들었다. 다수 선택을 하고 블러 이벤트가 발생했을 때 데이터가 바인딩 돼야 했다면 어쩌면 지금의 동작도 가져갈 수 있는데 아니었던 것이다. 그럼 문제가 심플해졌다.

애초에 고객을 선택했을 때 두 이벤트가 발생하면 안되는 것이었다. 레거시에서 사용하던 UI컴포넌트에 블러가 되면 셀렉트 이벤트가 발생하는 속성이 들어가 있는 걸 발견하고 그 한 줄을 제거함으로써 문제를 해결했다.

초기 작업자 말고 이후 작업자가 블러 이벤트 발생하는걸 필연적으로 보고 추가 작업해놓은 코드가 있긴한데...나중에....윽...해결하기로 하고...

세팅을 하는데 한세월 걸리고 문제를 파악하고 해결하는데 1시간 남짓 걸렸다. ...밥값은 한 것 같은데 영 가성비가 안나오는 것 같기도 하고.

1. 다른데에선 그렇지 않은데 특정 페이지에서 키보드가 올라오면 화면이 확대되는 이슈가 있었다. (IOS) 이 문제는 쉽게 해결됐는데 회사 동료가 겪었던 이슈였다. Input의 font size가 16보다 작을 때 이런 이슈가 발생을 했고, 화면 확대를 막음으로써 해결했다.

   <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no" />

2. 앱으로 사용하는 특성 상 많은 모달, 오버레이 등이 사용될 수 밖에 없었다. 그래서 z-index, fixed 관련한 이슈가 발생을 했다. 크롬에서는 문제가 없었는데 fixed 처리해놓은 Navigation이 Overlay 위로 올라 온다던지, 이미지 뷰어를 만들어서 띄웠는데 이미지 뷰어 뒤쪽의 스크롤이 노출된다던지.. 가장 쉽게 해결하는 방법은 Portal을 사용해서 가장 상위에 엘리먼트를 띄우는 것이다. 모달을 모달답게, 토스트를 토스트답게 사용하려면 최상단에 띄워야 한다고 하는 글을 얼핏 본 것 같지만, 자잘한 관련 이슈를 해결하려면 무조건 최상단으로 올리는게 맞는 것 같다. 그게 어렵더라도 최소한 해당 컴포넌트 레벨에서 최상단으로 올려야 문제가 안생긴다. 나같은 경우는 크게 공지사항 내용과 댓글 영역, fixed 처리 된 댓글 작성 영역이 있었고 원래는 댓글 작성 영역이 댓글 영역에 포함되어 있었다. 그런데 fixed로 넣은 이미지가 노출되지 않는 문제가 발생했다. 그래서 이들을 분리해서 프래그먼트 안에 헤더, 공지사항 내용, 댓글, 댓글 작성 이런 식으로 배치했다. 댓글 작성 영역을 제일 상위로 올림으로써 문제를 해결했다.

결론을 위로 당겨써보자면, react query 를 사용하면 아래와 같은 장점이 있다.

1. 나는 이 때 새로 패치하겠어! 라고 선언적으로 프로그래밍 할 수 있기 때문에 코드가 간결해진다. 리덕스를...써보진 않았지만 기본적으로도 작성해야할 코드가 많은데 비동기 작업을 하려면 리덕스 사가나 썽크와 같은 라이브러리도 사용해야 하기 때문에 코드가 더 길어진다.
2. 원하는 시점에 서버의 상태를 업데이트 할 수 있다. (인터벌, 포커싱 될 때 등등)

그렇다고 react-query 만으로도 상태관리가 가능하냐? 하면 그건 아니다. 이 라이브러리는 서버에서 받아오는 데이터만을 다루기 때문에 전역 상태 관리는 따로 해야 한다. 대신 그 양이 줄어들기 때문에 가벼운 상태 관리 라이브러리를 사용해 볼 수는 있겠다.

React Query

React Query는 서버로부터 데이터를 가져오고, 그 데이터를 캐싱, 에러 핸들링 등 비동기 작업을 수월하게 할 수 있도록 도와주는 라이브러리이다.

먼저 React Query는 여느 라이브러리와 마찬가지로 최상단에서 프로바이더를 통해 무언가를 주입을 하고 시작한다.

import { QueryClientProvider, QueryClient } from "react-query";

const queryClinet = new QueryClient();

<QueryClientProvider client={queryClinet}>
  <App />
  </QueryClientProvider>

그 다음 사용법을 보도록 하자. 먼저 useQuery다.

const result = useQuery(키, 함수, 옵션);

첫번째 인자로 들어가는 키는 어플리케이션 전체에서 쿼리를 다시 가져오고, 캐싱하고, 공유하는데 내부적으로 사용된다. 두번째 인자로 들어가는 통신을 위한 함수로 프로미스를 반환한다. 옵션들에는 이런 것들이 있다.

refetchInterval: 지정한 시간 간격에 따라 데이터를 패칭 refetchOnWindowFocus: 브라우저에 포커싱 될 때마다 새로운 데이터 패칭 onSuccess: 패칭 성공 onError: 패칭 실패

result 에는 아주 다양한 상태들이 포함되어 있고 기본적인 상태는 아래와 같다.

isLoading: 아직 데이터를 받아오지 못함. isError: 에러가 발생함. isSuccess: 데이터를 받아옴.

아래는 간단하게 테스트해본 코드이다. path만 나와있는건 무시하자. axios baseurl 설정을 해놔서 그렇다.

  const { data, isLoading, isError } = useQuery("getPosts", async () => {
    const { data } = await axios.get("/post");
    return data;
  });

  if(isLoading) {
    return <h2>Loading...</h2>
  }

  if(isError) {
    return <h2>{error.message}</h2>
  }

  return (
    <>
      { data?.map(({ id, title }) => (
        <div key={id}>{title}</div>
      )) }
    </>
  );

그 다음은 useMutation이다. 이 훅은 POST, PUT, DELETE 요청을 할 때 사용을 한다.

const { mutate } = useMutation(함수, 옵션);

함수의 역할은 useQuery와 같고, mutate함수를 통해 api 호출 함수를 실행할 수 있다. 옵션에서는 뮤테이션의 진행상황에 따른 콜백함수를 작성할 수 있다. 보통 뮤테이션 성공 후 캐시를 초기화할 때 사용할 수 있다. 어...? 이거 완전 아폴로랑 비슷...

  const { mutate } = useMutation(value => {
    return axios.post("/post", value)
  }, {
      onSuccess: (data, variables) => {
      // 작업에 성공하면 getPosts에 매핑된 useQuery api 함수를 실행한다.
      queryClient.invalidateQueries("getPosts");
      // 만약 muation 에서 리턴된 값을 이용해 get 을 해야 하는 경우에는 setQueryData를 사용한다.
      queryClient.setQueryData(["getPosts", { id: 5 }], data);
    }
  })

  return (
    <>
      <button onClick={handleClick}>버튼</button>
    </>
  );

실행 컨텍스트는 실행할 코드에 제공할 환경 정보들을 모아놓은 객체이며, 아래와 같이 생겼다.

ExecutionContext = {
  Lexical Environment: [Lexical Environment],
  Variable Environment: [Lexical Environment],
  ThisBinding: [object]
}

• Variable Environment: 현재 컨텍스트 내의 식별자들에 대한 정보 + 외부 환경 정보. 선언 시점의 Lexical Environment의 스냅샷
• Lexical Environment: Variable Environment 를 복사한 객체
• This Binding: this가 바인딩 되야할 객체

Lexical Environment 타입은 아래와 같이 생겼다.

Lexical Environment = {
  enviroment record: {},
  outer enviroment reference: {}
}

enviroment record 에는 현재 Context에서 선언된 함수, 변수, 매개변수들이 저장되는 공간이다. outer enviroment reference 는 현재 Context 를 기준으로 외부 Context 를 참조하는 공간이다.

아래와 같은 코드가 있다고 해보자.

function sum(x, y) {
  var result = x + y;
  var etc = function() {
    console.log('good')
  }
  function msg() {
    return result;
  }
}
sum(10, 20)

우선 자바스크립트 엔진이 함수를 만났으니 함수 컨텍스트를 생성할 것이다. 그리고 this를 바인딩 해줘야 하는데, 기본적으로 함수의 this는 window이다. 그 다음, Lexical Environment 를 넣어준다.

{
  Decleartion EnvironmentRecord: {},
  Outer Environment Reference: null
}

먼저, DecleartionEnvironmentRecord 에 매개변수 x와 y가 들어간다. 그 다음, 함수 선언문을 가져오고, 함수 내부에서 사용할 수 있는 arguments 를 세팅한다. 그 후, 선언된 변수를 가져온다. 중간 정리를 해보자.

{
  Decleartion Environment Record: {
    x: 10,
    y: 20,
    msg: Function Reference,
    arguments: Arguments Object,
    result: undefined,
    etc: undefined,
  },
  Outer Environment Reference: null,
}

코드를 보면 알겠지만, msg 는 함수를 참조하고 있고, etc 는 undefined 이다. 컨텍스트가 생성이 되면 변수 선언이 먼저 되고, 할당이 함수 실행 후에 되기 때문이다.

자, 이제 함수를 실행하게 되면

• Outer Environment Reference 는 가장 가까운 상위 컨텍스트를 참조한다. 기본적으로는 window 일 것이다.
• var result = x + y; 가 실행되며 result 에 30 이 할당된다.
• var etc 는 우항의 함수를 참조한다.

호이스팅

위에서 보았듯이, 자바스크립트가 실행이 되면 먼저 컨텍스트 내부의 모든 변수를 수집한다. 즉, 함수를 실행하기 전에 자바스크립트 엔진은 해당 환경에 속한 변수들을 모두 알고 있게 되는 것이다. 이를 자바스크립트 실제 동작 방식과 다르지만, 변수들을 모두 최상단으로 끌어올린 것과 다를바 없다고 하여, 끌어올리다의 의미의 hoist 에 ing 를 붙여 호이스팅(hoisting) 이라고 한다.

this

기본적으로 자바스크립트 엔진이 this 를 바인딩 하는 메커니즘은 함수 실행 시의 좌항을 보는 것이다. 아래에서 this 바인딩에 대해 더 알아보자.

1. 기본바인딩

var name = 'foo';

function foo() { console.log(this.name) };

foo(); //  "foo"

기본적으로 함수는 window에 바인딩 된다.

2. 객체 또는 new 통한 바인딩

function foo() { console.log(this.name) };
var name = 'baz';
var obj = { name: 'foo', bar: foo };

obj.bar(); // "foo"

메소드와 함수의 차이 함수는 그 자체로 독립적인 기능을 수행하는 반면, 메서드는 자신을 호출한 대상 객체에 관한 동작을 수행한다. 어떤 함수를 객체의 프로퍼티에 할당한다고 해서 그 자체로 메서드가 되는 것이 아니라 객체의 메서드로서 호출한 경우에 메서드로 동작하고 그렇지 않으면 함수로 동작한다.

간단히 말해서, 함수 앞에 점이 있으면 메서드, 아니면 함수이다. 메서드의 this 는 점 앞의 마지막 객체를 this 로 한다. 즉, 위 코드에서 this 는 obj 이다.

function foo() { console.log(this.name) };
var name = 'baz';
var obj = { name: 'foo', bar: foo };
var obj2 = obj.bar;

obj2(); // "baz"

당연히도, 전역변수를 선언 후 함수를 참조하게 한다면, this 는 전역을 가리키게 된다.

function Person(name) { this.name = name; };
Person.prototype.hello = function() { console.log(this.name) };
var obj = new Person('foo');
obj.hello(); // "foo"

new를 사용하여 객체를 생성하면, this는 생성된 객체에 바인딩된다.

3. 명시적 바인딩 명시적으로 this를 바인딩 해줄 수 있다. 자바스크립트의 call, bind, apply 함수가 그런 역할을 한다. 위 세 함수의 차이점은 아래와 같다.

• bind 함수는 선언할 때에, apply 와 call 함수는 호출할 때에 this를 바인딩하고 인자들을 제공한다.
• apply 함수는 인자들을 배열로, bind와 call 함수는 인자들을 리스트로 제공한다.

참조

https://medium.com/@kkak10/lexical-environment-4e0cffcad98d

본 글은 공부하면서 작성한 글로, 너무 깊게는 들어가지 않으려 합니다. 그리고 많은 부분을 리액트와 연관지어 작성할 예정입니다.

데이터 타입의 종류

최신 ECMAScript 표준은 다음과 같은 자료형을 정리한다.

• 기본 자료형인 여섯가지 데이터타입
  • Boolean
  • Null
  • Undefined
  • Number
  • String
  • Symbol
• 객체 (Objects)

보통 기본형과 참조형이라 나누어 부르기도 하며, 객체는 object Array Function Date WeakMaps Maps Sets 등을 일컫는다.

변수 선언과 데이터 할당

변수(variable). 여기서 변수란 데이터 할당을 통해 변할 수 있는 어떤 것 이라 할 수 있다.

let foo;
foo = 1;
let bar = 1;

첫번째 줄에서는 변수 foo 를 선언하고 있으며, 두번째 줄에서는 변수 foo 에 데이터를 할당하고 있다. 세번째 줄은 선언과 할당을 동시에 하고 있다.

변수를 선언하면, 컴퓨터는 메모리에서 비어있는 공간을 확보하고, 이 공간의 이름을 foo 라고 지정한다. 그 다음, 변수에 데이터를 할당하면 데이터를 저장하기 위한 메모리 공간을 확보한 후 1을 저장하고, foo 는 해당 메모리의 주소를 참조한다.

만약, 10 이라는 데이터로 재할당 한다면, 10이라는 데이터가 있는지 체크한 후 없으면 메모리 공간을 확보해 10을 저장할 것이다. 그리고 foo 는 새로 만들어진 메모리의 주소를 참조하게 될 것이다.

그렇다면 객체를 할당할 때는 어떨까?

let foo = { name: 'John', age: 1 }

변수는 총 3가지다. foo, name, age 각 변수명을 가진 메모리 공간이 확보될 것이고, foo 는 name 과 age를 프로퍼티로 가진 데이터 그룹의 주소를 참조하게 될 것이다. 그리고 위 데이터 그룹은 name 과 age 라는 공간의 주소를 참조하게 될 것이다.

이와 같이 참조-참조를 하기 때문에 name 의 값을 바꾼다고 해도 foo 의 값에는 영향을 주지 못한다. foo 가 참조하는 주소값을 변경시키려면, let foo = { name: 'James', age: 1' } 과 같이 새로운 객체를 할당해야 한다.

불변성

리액트는 함수형 프로그래밍을 지향하고, 함수형 프로그래밍에서는 데이터가 변할 수가 없는데, 이를 불변성이라 한다. 불변성은 리액트 뿐만 아니라 Vue.js 나 Angular 등의 라이브러리나 프레임워크에서도 사용되는 개념이다.

객체는 참조를 통해 공유되고 있고, 그 상태는 언제든지 변경될 수 있기 때문에 문제가 발생할 여지가 있다. 객체를 참조하는 모든 장소에서 영향을 받기 때문이다. 이런 현상을 막기 위해 객체를 복사하여 새로운 객체를 생성한 후 변경해야 한다.

자바스크립트에서는 원본 객체의 불변성을 유지하게 도와줄 메서드로 Object.assign 을 제공하고 있다. 불변성을 유지하면 복제나 비교를 위한 조작을 단순화 할 수 있다. 하지만, Object.assign은 객체를 얕은 복사(shallow copy)를 한다. 즉, 바로 아래단계의 객체의 주소값만 복사하기 때문에, 중첩된 객체들의 주소값들은 복사하지 못한다.

깊은 복사(deep copy)를 하려면 재귀적으로 객체를 복사하는 메서드를 만들거나, 라이브러리를 이용하거나, JSON.parse(JSON.stringify(foo)) 과 같이 JSON 형식으로 바꾸고 다시 파싱을 해야 한다.

SPA 란 말 그대로 한개의 페이지를 가진 어플리케이션이다. 왜 SPA 로 개발하느냐고 묻는다면,

• 사용자 친화적
• 초기 렌더링 후 데이터만 받아오기 때문에, 상대적으로 서버 요청이 적음
• Virtual Dom
• 프론트 엔드와 백엔드 분리로 개발업무 분업화 및 협업이 용이
• 개발이 상대적으로 효율적

정도를 말할 수 있겠다.

기본적으로 SPA 는 클라이언트 사이드 렌더링이지만 그렇다고 SPA === CSR 은 아니다. 이제 아래에서 SPA 에서의 SSR 과 CSR 에 대해 알아보자

SSR(Server Side Rendering)

과거 그리고 현재도 그렇지만, 많은 웹사이트들은 페이지를 이동할 때마다 서버에 새로운 페이지에 대한 요청을 하는 방식을 택하고 있다.

이 방식이 SSR이다. 서버에서 렌더링을 마치고, Data가 결합된 HTML파일을 내려주는 방식이다. 새로운 페이지로 이동할 때마다 서버에 요청하여 페이지를 받아야 하기 때문에, 받아오는 시간동안 깜빡거리는 현상을 마주할 수 있다.

한편, SPA(Single Page Application) 기법이 대두 되면서 CSR 방식이 각광받기 시작했다.

CSR(Client Side Rendering)

CSR 방식은 최초 요청시에 HTML을 비롯해 CSS, Javascript 등 각종 리소스를 받아온다. 이후에는 서버에 데이터만 요청하고, 자바스크립트로 뷰를 컨트롤 한다. 당연히 초기 요청 때 SSR 보다 많은 리소스를 요청하기 때문에, 렌더링은 속도는 SSR이 더 빠르다. 하지만 이후 다른 페이지로의 이동시에는 SSR 보다 빠른 페이지 전환 속도와 더 나은 사용자 경험을 제공한다.

만약 인터넷 속도가 어어엄청 느리다면, 유저는 제대로된 화면을 한참 후에나 만나볼 수 있을 것이다. 일단 처음 받게될 HTML은 빈페이지일 테니까.

SEO(Search Engine Optimization) 문제

아무래도 리액트나 뷰를 사용하면서, CSR을 할 지 SSR을 할 지 고민하게 되는 이유는 SEO 때문이다. 물론 회사내에서만 사용하는 CMS라면 신경쓸 필요가 없지만 공식 홈페이지와 같이 일반 사용자에게 검색되어야 하는 사이트라면 SEO 때문에 SSR에 대해 생각하게 된다.

사실 갓구글은 크롤러 안에 자바스크립트 엔진이 들어있어서 크게 문제될게 없지만, 네이버나 다음은 다르다. 왜냐면...그들은 자바스크립트를 해석할 수 있는 엔진이 없어서 빈 페이지로 인식할테니까!

렌더링 퍼포먼스 외적인 측면도 다루었다. 흔히 많이들 하는 오해가 CSR은 SEO가 잘 되지 않는다라는 것인데, 많은 크롤러들이 JavaScript를 지원하지 않기 때문에 발생한 오해다. Google Bot(크롤러)은 JavaScript를 지원하기 때문에 CSR 사이트도 SEO가 잘 된다. 특히, 최신 버전의 Google Bot은 ES2015 이상의 최신 JavaScript도 지원한다. 또한 Full SSR 없이도 메타 태그들을 잘 활용하면 SEO를 잘 지원할 수 있다. https://hyunseob.github.io/2019/05/26/google-io-2019-day-3/

이를 해결하기 위해 SSR with Hydration 기법이 나왔는데, 대표적으로 React 진영의 Next.js와 Vue 진영의 Nuxt.js가 위 기법을 구현한 프레임 워크다. 즉, 처음엔 서버사이드 렌더링을 하고, 그 후 다른 페이지들에선 클라이언트 사이드 렌더링을 이용하는 방식이다.

직접 SSR 구현? Next.js 사용?

현재 사이드 프로젝트로 진행중인 서비스의 CMS 구현을 어느정도 마치고, 공식 홈페이지를 개발해야하는 상황이다. 유명한 개발 블로거들은 직접 SSR을 구현하는게 낫다고 하는데, 세부설정이 불편하기 때문이라고... 그 세부설정이 뭔지 모르겠는데, 오늘 아침 개발자 카톡방에서 SSR 이야기가 나와서 살짝 운을 띄웠더니 버전 업 되면서 세부 설정이 없어도 된다고 하더라. 도대체 세부 설정이 뭐지...? 여튼, 회사 공식홈페이지도 Next.js 로 했었는데 잘 모른채로 사용했던지라 이번에는 꼼꼼히 세팅해볼 생각이다.

간단하게 Next.js가 제공해주는 기능을 보고 넘어가자면

• 페이지 기반 라우팅 시스템 (동적 라우팅 지원)
• pre-rendering , 페이지별 정적파일 생성과 서버사이드 렌더링 지원
• 코드스플리팅
• prefetch(필요한 데이터를 미리 요청) 기능을 갖춘 클라이언트 사이드 라우팅
• CSS, Sass 기본 지원 및 다른 CSS-in-JS 라이브러리 지원
• HMR(Hot Module Replacement) 지원
• API routes to build API endpoints with Serverless Functions
• Fully extendable

음..마지막 두개는 어떻게 이해하기 쉽게 해석 해야할 지 모르겠어서, 원문 그대로 남겨둔다. 여튼, 위와 같이 편한 기능을 제공하기에 특별한 이유가 없다면 사용하는게 나을 것 같다. 한가지 불편한 점이 있다면, 선택적 핫로딩이 안된다는 점...

Next.js 9 패치노트 번역본 https://velog.io/@jakeseo_me/%EB%B2%88%EC%97%AD-Next.js-9-%ED%8C%A8%EC%B9%98%EB%85%B8%ED%8A%B8

자바스크립트 엔진은 자바스크립트 코드를 해석하고 실행하는 인터프리터이다. 대중적으로 알려진 엔진은 구글의 V8엔진인데, 아무래도 가장 많이 사용되는 크롬에서 사용되고, Node.js에서 사용되는 엔진이기도 하기 때문인 듯 하다.

텍스트하지만 렌더링 엔진과 마찬가지로 브라우저마다 다른 엔진을 사용한다.

• SpiderMonkey : 파이어폭스
• V8 : 크롬
• Webkit : 사파리
• Chakra : 익스플로러, 엣지

자바스크립트 엔진은 메모리 힙과 호출 스택으로 이루어져 있다.

• 메모리 힙 : 변수와 객체의 메모리 할당이 발생하는 곳
• 콜 스택 : 코드가 실행될 때마다 호출 스택이 쌓이는 곳

런타임

자바스크립트 엔진에서 제공해주지 않지만 자바스크립트 개발자가 사용하는 setTimeout 과 같은 API들이 있다. 이러한 API들은 브라우저에서 제공하는 Web API이다. 그리고 이런 Web API 의 호출을 제어하기 위한 콜백큐와 이벤트 루프가 있다.

콜스택

자바스크립트는 싱글 쓰레드 언어이기 때문에, 한번에 한가지 작업만 실행하게 된다. 콜 스택이란 프로그램에서 우리가 어디 있는지를 기록하는 자료 구조이다. 함수를 실행하면, 그 함수가 콜 스택의 가장 상단에 위치하게 된다. 그리고 함수의 실행이 종료 되면 그 함수는 스택에서 제거(Pop) 된다. 그리고 호출 스택의 각 항목을 스택 프레임이라고 한다.

스택 오버플로우

function foo() {
  foo();
}
foo();

위와 같은 함수를 호출하게 되면 콜스택 위에 계속 함수가 쌓일 것이다. 그리고 호출 스택의 실제 크기를 초과하게 되면 브라우저는 Maximum call stack size exceeded 라는 에러를 발생시키고 함수를 종료시킨다.

이벤트 루프

호출 스택에 처리 시간이 굉장히 오래 걸리는 함수가 있으면 어떻게 될까? 자바스크립트는 싱글 쓰레드 이기 때문에 함수가 종료될 때까지 다른 작업들이 모두 대기 상태가 될 것이다. 그리고 결국 브라우저는 웹 페이지를 종료할지 여부를 무든 오류메시지를 표시할 것이다.

이런 상황을 제어하기 위해 사용하는 것이 비동기 콜백이다. 즉, 코드 일부를 실행하고 나중에 실행될 콜백 함수를 제공하는 것이다. 비동기 콜백은 즉시 콜스택에 올라가는 것이 아닌, 특수한 시점에 실행이 되므로 스택안에 바로 올라가지 않는다.

그리고 이 콜백 함수들의 스케쥴을 관리하는 것이 이벤트 큐이다.

콜백 큐

자바스크립트 런타임은 콜백 큐를 가지고 있다. 이는 처리할 메시지 목록과 실행할 콜백 함수들의 리스트이다.

setTimeout 를 포함하고 있는 함수가 실행된다고 하면, 함수는 콜스택에 올라갈 것이고, setTimeout 은 콜백 큐에 밀어 넣어진다. 이벤트 루프는 콜스택과 콜백 큐를 감시하면서, 콜스택이 비워지게 되면 콜백 큐에 대기 중인 항목이 있는지 확인하고, 있으면 스택에 올린다.

자바스크립트 삽입 위치

브라우저는 렌더링 도중 자바스크립트를 만나게 되면 이에 대한 해석과 실행이 완료될 때까지 렌더링을 멈춘다. 그렇기 때문에, 렌더링이 정상적으로 끝난 후 실행하기 위해 바디 하단에 스크립트를 두는게 안정적이라는 말을 한다.

1. head에 삽입되는 경우

• 무거운 스크립트가 실행되는 경우 렌더링에 방해가 될 수 있다.
• 제이쿼리와 같은 설정을 위한 스크립트들이 사용된다.
• DOM이 필요할 경우 document.onload 를 사용하여, load 이벤트 발생 시, 실행되도록 할 수 있다.

2. 바디 하단에 삽입되는 경우

• 브라우저의 렌더링이 완료 된 후 실행되기 때문에, DOM을 조작할 수 있다.

하지만! 헤드 태그에서 발생할 수 있는 문제를 해결하기 위해 추가된 속성이 있다. 바로, async와 defer이다.

<script async src="myAsyncScript.js" onload="myInit()"></script>
<script defer src="myDeferScript.js" onload="myInit()"></script>

위와 같이 async 또는 defer 속성이 추가된 스크립트는 렌더링을 방해하지 않는다. async 속성은 외부 스크립트에만 사용할 수 있으며, 스크립트를 내려받는 즉시 실행된다. defer 속성은 비동기적으로 스크립트를 다운로드 하며, 렌더링이 완료된 후 스크립트를 실행한다.

참조

https://blog.asamaru.net/2017/05/04/script-async-defer/ https://junhobaik.github.io/js-script-position/ https://new93helloworld.tistory.com/358

렌더링이란 서버로부터 HTML 파일을 받아 브라우저에 뿌려주는 과정이다.

브라우저는 서버로부터 HTML 문서를 다운 받는다. 렌더링 엔진은 HTML 문서를 파싱해서 DOM 트리를 만든다.

그 다음, 외부 css 파일과 함께 포함된 스타일 요소를 파싱하여 CSSOM 트리를 만든다. 스타일은 브라우저의 자체 스타일, 사용자 정의 스타일, html 태그에 걸려있는 스타일 순서로 처리되며, 나중에 처리되는 스타일을 따르게 된다.

따라서, 인라인으로 들어가있는 스타일 속성이 우선순위를 가지는 것이다.

다음으로, DOM 트리와 CSSOM을 결합하여 렌더링 트리를 형성한다.

이때, 화면에 드러나지 않는 head 태그나 display 속성에 none 값이 할당된 요소는 렌더 트리에 포함되지 않는다.

다음은 기기의 뷰포트 내에서 노드들의 정확한 위치와 크기를 계산하는 과정이 진행된다. 이 단계가 레이아웃 단계이며, 리플로우라고도 한다.

페이지에서 각 객체의 정확한 크기와 위치를 파악하기 위해 브라우저는 렌더링 트리의 루트부터 시작하여 렌더링 트리를 순회한다.

이 작업이 끝나면, 이제 렌더링 엔진은 각 요소가 어디에 어떤 크기로 표현될지 알게 된다. 렌더링 엔진은 페인트 이벤트를 발생시켜 렌더링 트리를 화면에 그리고, 이 과정을 페인팅 또는 래스터화 라고 한다.

모든 HTML 을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 진행한다. 웹페이지에 접속했을 때, 페이지가 한꺼번에 뜨지 않고 점점 화면에 그려지는것이 이 때문이다.

렌더링 정리

이 과정을 정리해보자.

• HTML을 파싱하여 DOM 트리를 만든다.
• CSS를 파싱하여 CSSOM 트리를 만든다.
• DOM 과 CSSOM 을 결합하여 렌더링 트리를 만든다.
• 렌더링 트리에서 각 노드의 크기와 위치를 계산한다.
• 개별 노드를 화면에 그린다.

렌더링이 완료된 상태에서 사용자의 인터랙션에 의해 화면의 일부 영역이 변경된다면, 리플로우 또는 리페인트가 발생한다.

정확히 말하자면, 레이아웃이 변경될 경우 리플로우 리페인트 를 거치고 레이아웃에는 영향을 주지 않지만 가시성에는 영향을 주는 엘리먼트가 변경될 때는 리페인트 만 거치게 된다. (ex : opacity, background-color 등)

여기서 레이아웃의 변경이란 아래와 같은 경우를 말한다.

• DOM 엘리먼트 추가, 제거 또는 변경
• CSS 스타일 추가, 제거 또는 변경
• CSS 스타일을 직접 변경하거나, 클래스를 추가함으로써 레이아웃이 변경될 수 있다. 엘리먼트의 길이를 변경하면, DOM 트리에 있는 다른 노드에 영향을 줄 수 있다.
• CSS3 애니메이션과 트랜지션. 애니메이션의 모든 프레임에서 리플로우가 발생한다.
• offsetWidth 와 offsetHeight 의 사용. offsetWidth 와 offsetHeight 속성을 읽으면, 초기 리플로우가 트리거되어 수치가 계산된다.
• 유저 행동. 유저 인터랙션으로 발생하는 hover 효과, 필트에 텍스트 입력, 창 크기 조정, 글꼴 크기 변경, 스타일시트 또는 글꼴 전환등을 활성화하여 리플로우를 트리거할 수 있다.

따라서, 최적의 렌더링 성능을 얻기 위해서는 위 단계들을 최적화 해야 한다.

최적화 방법

리플로우 최소화 방법

1. 인라인 스타일 사용 X 인라인 스타일은 가독성을 해칠뿐 아니라, 수차례 리플로우를 발생 시킨다. 그에 반해 외부 스타일을 사용할 경우 한번만 리플로우를 발생시킨다.

2. 작업 그루핑 DOM 요소의 정보를 요청하고 변경하는 코드는 같은 형태의 작업끼리 묶어 실행시키는 것이 좋다.

function change() {     
  let width = document.getElementById("layer1").style.width;
  document.getElementById("layer2").style.width = width; 
  let height = document.getElementById("layer3").style.height; 
  document.getElementById("layer4").style.height = height; 
}

function change() {     
  let width = document.getElementById("layer1").style.width;
  let height = document.getElementById("layer3").style.height; 
  document.getElementById("layer2").style.width = width; 
  document.getElementById("layer4").style.height = height; 
}

3. 노출 제어 위에서 언급했다싶이 display 속성의 값을 none으로 하면, 렌더링 트리에서 노드가 빠지게 된다. 따라서 노드를 노출시킨채 스타일을 변경하는 것보다, 노드를 감추고 스타일을 변경한 후 노드를 노출 시키는 것이 리플로우와 리페인트 발생횟수를 줄이는 방법이다.

let element = document.getElementById("box1"); 

for(let i=50; i<100; i++) {     
  element.style.width = i + "px"; 
} 
for(let i=1; i<=50; i++) {  
  element.style.borderWidth = i + "px"; 
}

// 아래와 같이 렌더링 트리에서 빼준 다음, 스타일을 적용하고 다시 노출.
// 이 경우 두번의 리플로우 리페인트만 발생

let element = document.getElementById("box1");
element.style.display = "none"; 

for(let i=50; i<100; i++) {    
  element.style.width = i + "px"; 
} 
for(let i=1; i<=50; i++) {  
  element.style.borderWidth = i + "px"; 
} 

element.style.display = "block";

4. 노드 복제 변경하려는 요소의 노드를 복제한 후 복제된 노드에 작업을 하고, 교체를 해주게 되면 리플로우와 리페인트는 한번만 발생한다.

5. 캐싱 여기서 말하는 캐싱은 별도의 변수에 자주 사용하는 값을 저장하는 것이다. scrollWidth와 같은 값을 호출할 경우 리플로우를 유발하기 때문에, 반복 구문을 실행하기 전에 이를 변수에 담아 놓으면 리플로우 발생을 최소화 할 수 있다.

이 외에도 여러가지 최적화 방법이 있으니, 검색을 통해서 알아보기로 하자.

요소의 투명도를 조절하는 스타일 속성이며, 0.0부터 1.0 사이의 값으로 설정할 수 있다.

position

요소의 위치를 설정할 수 있다.

static : 기본 값이며, 마크업 순서대로 배치된다. top, left, right, bottom, z-index 값에 반응하지 않는다. relative : 현재 위치를 기준으로 이동할 수 있다. absolute : static 을 제외한 position 속성을 가진, 가장 가까운 부모를 기준으로 이동할 수 있다. fixed : 마크업 순서와 무관하게 배치된다. sticky : 스크롤 위치에 따라 relative 또는 fixed 로 전환한다. 즉, 평소엔 relative, 스크롤이 해당 요소의 위치에 오면 fixed로 전환.

z-index

요소의 깊이를 변경할 수 있다.static을 제외한 position 속성이 설정된 상태에서 사용할 수 있다. 음수가 설정될 경우 기본 요소보다도 아래 배치된다.

overflow

내부의 요소가 부모의 범위를 벗어날 때의 어떻게 처리할 지 지정할 수 있다.

vidible : 기본값으로, 넘치는 부분을 그대로 보여준다. hidden : 넘치는 부분을 감춘다. scroll : 스크롤을 생성한다. auto : 상황에 맞춰 스크롤을 생성한다.

transform

요소의 위치를 옮기거나 크기를 조절하고, 회전, 왜곡 시킬 수 있다.

translate(x, y) : 지정한 값 만큼 수평, 수직 이동시킨다. translate(x, y, z) : 지정한 값 만큼 수평, 수직, 앞뒤로 이동시킨다. translateX(x) : 지정한 값 만큼 수평 이동시킨다. translateY(y) : 지정한 값 만큼 수직 이동시킨다. translateZ(z) : 지정한 값 만큼 앞뒤로 이동시킨다.

이하는 한개씩만..

scale(x, y) : 지정한 값 확대/축소한다. 음수일 경우 해당 축을 기준으로 요소를 뒤짚는다.(invert) rotate(angle) : 지정한 각 만큼 수평, 수직방향으로 회전한다.

transition

한 스타일에서 다른 스타일로 변경한다. 시간을 조절함으로써 애니메이션 효과를 낼 수 있다.

transition: property, duration, timing-function delay

property : 트랜지션이 적용될 css 속성 (none, all, 속성이름) duration : 트랜지션 실행시간 timing-function : 트랜지션효과의 곡선형태

• liner : 같은 속도로 진행
• ease : 느리게 시작, 점점 빨라짐, 느리게 종료 (기본값)
• ease-in : 느리게 시작
• ease-out : 느리게 종료
• ease-in-out : 느리게 시작, 느리게 종료
• cubic-bezier(n,n,n,n) : 직접 함수를 정의해서 사용

delay : 지연시간

자세한 예는 cssreferecne.io 에서...

display는 요소의 종류를 선택하는 속성이다. block 형식은 한 줄 모두를 차지하며, 넓이와 높이 설정이 가능하다. inline 형식은 내용만큼 차지하며, 넓이와 높이 속성을 지정할 수 없다. 또한 margin 속성은 좌우로만 지정할 수 있다. inline-~ 형식은 inline 요소처럼 표현되지만 block 처럼 사용할 수 있다.

요즘 가장 자주 사용하는 속성은 flex가 아닐까 싶다. flex 속성은 요소의 크기가 불분명하거나 동적인 경우에도, 각 요소를 정렬할 수 있는 방법을 제공한다. flex는 Container, Itmes 두 개념으로 나뉜다. Container는 Items를 감싸는 부모 요소이며, 각 Items를 정렬하기 위해선 Container가 필수이다.

Container에는 display, justify-content, align-items 등의 속성이 사용되며, Items에는 order, flex, align-self 등의 속성이 사용된다.

참고 - CSS3 Flex 완벽가이드

자주 사용하는 속성들에 대해 알아보자.

flex-direction : Items의 주 축(main axis)을 설정합니다. row가 기본 값이다. column으로 설정할경우 주축이 세로 방향으로 바뀌며, 항목들은 열로 나열된다. *-reverse 로 지정하게 되면 시작 방향이 바뀌게 된다. flex-wrap : 기본 값은 nowrap이며, 항목들의 넓이의 합이 flex 박스의 넓이를 넘어섰을 때, 줄바꿈을 할지 결정한다. flex-flow : flex-direction 속성과 flex-wrap 속성을 합친 속성으로, flex-direction, flex-wrap 값 순서로 사용한다. flex-basis : 항목들의 넓이를 설정한다. flex 컨테이너의 flex-basis 기본 값은 'auto'이다. flex-grow : flex-grow 값을 양수로 지정하면 항목별로 주축 방향 크기가 flex-basis 값 이상으로 늘어난다. flex-shrink : flex-shrink 속성은 주축의 공간이 부족할 때 각 항목의 사이즈 줄이는 방법을 정의한다.

위 세 속성은 축약형으로 사용할 수 있으며 flex : flex-grow flex-shrink flex-basis 순서로 사용할 수 있다.

flex 축약형 표현에 사용할 수 있는 미리 정의된 축약 값들도 있다.

• flex: initial
• flex: auto
• flex: none
• flex: <positive-number>

flex 항목을 flex: initial로 지정하면 flex: 0 1 auto 로 지정한 것과 동일하게 동작한다. 이 경우, flex 항목들은 flex-grow가 0이므로 flex-basis값보다 커지지 않고 flex-shrink가 1이므로 flex 컨테이너 공간이 모자라면 크기가 줄어든다. 또, flex-basis가 auto이므로 flex 항목은 주축 방향으로 지정된 크기 또는 자기 내부 요소 크기 만큼 공간을 차지한다.

flex: auto 로 지정하면 flex: 1 1 auto로 지정한 것과 동일하며, flex:initial 과는 주축 방향 여유 공간이 있을 때 flex 항목들이 늘어나서 주축 방향 여유 공간을 채우는 점만 다르다.

flex: none으로 지정하면 flex: 0 0 auto으로 지정한 것과 동일하며 flex 컨테이너의 크기 변화에도 flex 항목 크기는 변하지 않고 flex-basis를 auto로 지정했을 때 정해지는 크기로 결정된다.

이 축약형은 더 축약해서 flex: 1 이나 flex: 2처럼 쓸수도 있는데, 이는 flex-grow 만 지정하고 나머지는 1 0으로 사용한다는 뜻이다. 따라서 flex: 2는 flex: 2 1 0와 동일하게 처리된다.

align-items : 교차축(direction이 row라면 y축)에 따른 항목들의 정렬 방법을 정한다.

• flex-start : 교차축의 시작 부분에 나열
• flex-end : 교차축의 끝 부분에 나열
• center : 중앙에 나열 기타로 baseline, stretch 가 있다.

align-self : align-items가 항목들의 정렬 방법을 정한다면, align-self는 항목의 정렬 방법을 정한다. justify-content : 주축의 방향에 따른 flex 항목들의 정렬 방법을 정한다.

• flex-start : 주 축의 시작 부분에 나열
• flex-end : 주 축의 끝 부분에 나열
• center : 중앙에 정렬
• space-between : 주축 방향 여유공간을 각 항목들 사이의 공간에 균등 배분
• space-around: 시작 부분 및 끝 부분과 flex 항목간 공간도 균등 배분에 고려하므로 시작 부분 및 끝 부분과 flex 항목 간의 공간의 크기를 1로 배분한다면 flex 항목 사이의 공간은 2로 배분
• space-evenly : 시작 부분과 끝 부분도 동일한 비율로 공간 배분

참고 - cssreference.io, flexbox의 기본개념

visibility

대상을 보이거나 보이지 않게 지정하는 속성으로 visible, hidden, collapse 등을 값으로 사용할 수 있다. display: none 과 visibility: hidden 을 비교하는 질문이 나올 수 있다. display: none은 공간을 차지하지 않고, visibility: hidden은 공간을 차지한다. 즉, display는 레이아웃의 변화를 야기하기 때문에 reflow, repaint 가 발생하지만, visibility 는 레이아웃에 영향을 주지 않으므로 repaint만 발생한다.

CSS란?

css란 Cascading Style Sheets의 약자로, HTML문서를 꾸밀 때 사용하는 스타일 시트 언어이다.

텍스트 관련 스타일

<div style="
    letter-spacing: 1.4; // 문자와 문자사이의 간격
        line-height: 1.2; // 줄 간격
        white-space: nowrap; // 텍스트와 함께 입력된 공백 처리 방법
        text-align: center; // left | center | right
        font-size: 14px; // 폰트 사이즈!
        font-weight: 400; // bold | lighter | bolder | 100~900
    ">
    </div>

white-space normal : 기본값으로 연속하는 공백을 하나로 처리, 자동으로 줄을 바꿈 nowrap : 연속하는 공백을 하나로 처리하고, 줄바꿈은 <br>에서만 일어남 pre : 연속하는 공백을 유지하며, 줄바꿈은 개행문자와 <br>에서만 일어남 pre-line : 연속하는 공백은 하나로 취급, 줄바꿈은 개행문자와 <br>에서만 일어나며, 한줄이 너무 길어서 넘칠 경우 자동으로 줄 바꿈 pre-wrap : 연속하는 공백을 유지하며, 줄바꿈은 개행문자와 <br>에서만 일어나며, 한줄이 너무 길어서 넘칠 경우 자동으로 줄 바꿈 break-spaces : pre-wrap과 비슷하며, 연속 공백이 줄 끝에 위치하더라도 공백을 차지함.

주로 overflow와 text-overflow와 함께 사용된다.

<div style="
  white-space: nowrap; 
  overflow: hidden; 
  text-overflow: ellipsis"
>
</div>

margin & padding

margin을 사용해 요소의 바깥쪽 여백을 설정할 수 있다. padding을 사용해 요소의 안쪽 여백을 설정할 수 있다. 안쪽 여백이란 콘텐츠와 테두리 사이의 공간이다. 출처 - https://ofcourse.kr/css-course/margin-padding-%EC%86%8D%EC%84%B1

margin이 바깥쪽 여백이다보니 서로 겹치는 경우가 발생할 수 있는데, 이를 마진 상쇄(Margin collapsing)라고 한다.

In CSS, the adjoining margins of two or more boxes (which might or might not be siblings) can combine to form a single margin. Margins that combine this way are said to collapse, and the resulting combined margin is called a collapsed margin. CSS에서 두 개 이상의 상자(형제일수도 있고 아닐수도 있음)의 인접한 여백은 결합하여 하나의 여백을 형성하고 이를 마진 붕괴라 한다. -W3C

자세한 설명은 CSS 마진 상쇄(Margin-collapsing) 원리 완벽 이해 을 참고하자.

border

border를 사용해 테두리를 설정할 수 있다.

<div style="border: 1px solid #ddd;"></div>

테두리 굵기(border-width), 스타일(border-style), 색(border-color) 중 선택하여 사용할 수 있으며, 순서는 영향을 주지 않는다. 테두리 경계의 모서리를 둥글게 만들고자 할 때는 border-radius를 사용한다.

<div style="
  width: 100px; 
  height: 50px; 
  border: 1px solid #f5a623;
  border-radius: 20px; 
  background-color: #f5a623;
"></div>

box-sizing

box-sizing 속성은 요소의 넓이와 높이를 계산하는 방법을 지정한다.

content-box : 기본 css 박스 크기 결정법을 사용하며, 요소의 너비를 100px로 설정하면 콘텐츠 영역이 100px의 너비를 가지며, border-width와 padding이 더해진다.

box-sizing : border와 padding을 요소의 크기로 고려한다. 너비를 100 픽셀로 설정하고 테두리와 안쪽 여백을 추가하면, 콘텐츠 영역이 줄어들어 총 너비 100 픽셀을 유지합니다. 대부분의 경우 이 편이 크기를 조절할 때 쉽다.

시맨틱(Semantic)은 "의미의, 의미론적인" 이라는 뜻, 즉 시맨틱 태그란 의미를 가지는 태그이다.

시맨틱 태그에 의해 컴퓨터가 HTML 요소의 의미를 보다 명확히 해석하고 그 데이터를 활용할 수 있는 시맨틱 웹이 실현될 수 있다. 시맨틱 웹이란 웹이 존재하는 수많은 웹페이지들에 메타데이터를 부여하여 기존의 잡다한 데이터 집합이었던 웹페이지를 의미와 관련성을 가지는 거대한 데이터 베이스로 구축하고자 하는 발상이다.

https://poiemaweb.com/html5-semantic-web

태그가 의미를 가짐으로써 검색엔진의 크롤링에게 사이트에 대한 정보를 비교적 정확히 제공할 수 있게 된다.

시멘틱 태그의 종류

form, table, img, 등이 있으며, HTML5에서 추가된 시맨틱 태그는 아래와 같다. header : 헤더를 의미 nav : 네비게이션을 의미 aside : 사이드에 위치하는 공간을 의미 section : 본문의 여러 내용 (article)을 포함하는 공간을 의미 article : 본문의 주 내용이 들어가는 공간을 의미 footer : 푸터를 의미

메타태그란?

메타태그는 웹 페이지의 보이지 않는 정보를 제공하는데 쓰인다. 페이지에 대한 설명, 제작자, 크롤링 정책 등의 정보를 제공할 수 있다.

SEO

SEO는 Search Engine Optimization의 약자로 검색 엔진 최적화를 의미한다. 메타태그를 이용해 description, keywords, author, subject, classification 등의 정보를 표기할 수 있으며, 검색엔진은 이런 정보를 적극적으로 활용한다.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="keywords" content="apple banna">
    <meta name="desciption" content="나의 블로그">
    <meta name="robot" content="noindex nofollow">
    <meta property="og:type" content="website">
    <meta property="og:title" content="페이지 제목">
    <meta property="og:description" content="페이지 설명">
    <meta property="og:image" content="http://www.mysite.com/myimage.jpg">
    <meta property="og:url" content="http://www.mysite.com">

https://junhobaik.github.io/meta-tag/

<meta charset="utf-8"> HTML5의 인코딩 지정 방법으로 보통 UTF-8(전세계 거의 모든 문자를 표현할 수 있는 문자 집합)을 값으로 지정하는 편이다.

<meta name="viewport" content="width=device-width, initial-scale=1"> 뷰포트는 화면에 보이는 영역을 뜻한다. 즉, 내가 보고 있는 모니터 화면 영역을 말하며, 스크롤로 봐야할 영역은 제외한다. 위 코드는 문서의 넓이는 기기의 넓이이며, 초기 화면 배율은 1로 한다는 의미이다.

<meta name="keywords" content="apple banna"> 해당 컨텐츠의 대표적인 키워드를 지정한다. 검색 엔진의 검색 결과에 반영될 수 있다. (구글은 반영 X)

<meta name="desciption" content="나의 블로그"> 해당 페이지에 대한 설명을 설정한다. 검색사이트에서 검색했을 때 제목 아래에 노출되는 부분이다

<meta name="author" content="bumhyun"> 웹 사이트의 소유자를 적는다.

<meta name="robot" content="noindex nofollow"> 인덱싱을 제어하는데 사용되며, 사용가능한 content는 index, noindex, follow, nofollow가 있다. index와 noinde는 페이지의 인덱스 여부를 말해주며, follow, nofollow는 페이지내의 링크를 크롤러가 따라갈 수 있는지 여부를 말해준다.

검색엔진이 검색 키워드에 대한 검색결과를 사용자한테 제공하기 위해서는 크롤러가 끊임없이 온라인 상의 문서를 수집해야하고, 크롤러가 수집한 문서를 인덱서가 잘 정리해서 인덱스 서버에 색인해 둬야 한다. 크롤러는 사이트와 사이트 사이의 링크를 타고다니며 문서를 수집하는 역할만 하며, 인덱서는 수집된 문서를 검색엔진이 사용자에게 결과물을 빠르고 쉽게 재공할 수 있도록 색인 또는 인덱스 역할을 한다. 참고 - 크롤링과 인덱싱의 차이

OpenGraph 오픈그래프는 웹페이지가 소셜 미디어 또는 오픈 그래프를 활용한 사이트로 공유될 때 사용되는 정보다.

침고 할만한 글 - Google 검색은 어떻게 동작하는가?

😄 HTML(Hypertext Markup Language)이란?

HTML이란 프로그래밍 언어가 아니다. 컨텐츠의 구조를 정의하는 마크업 언어이다.

HTML은 어떠한 형식으로 보이게 하거나 특정한 방식으로 동작하도록 하는 Element들로 이루어져 있다. 각 Element는 속성을 가질 수 있는데, 속성은 실제 컨텐츠로 표시되길 원하지 않는 추가적인 정보를 담고 있다. 각 속성 사이에는 공백이 있어야 하며, 속성의 이름 뒤에는 등호(=)가 와야 한다. 또한 속성의 값을 확실히 표현해주기 위해서는 인용부호(" 또는 ')가 있어야 하는데 Doublequote(")를 사용하는 편이다.

HTML 문서의 각 요소를 알아보자

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>My test page</title>
  </head>
  <body>
    <img src="images/firefox-icon.png" alt="My test image">
  </body>
</html>

DTD(Document Type Definition)이란?

문서 타입 정의는 HTML5, XHTML, HTML 의 세가지 문서 유형이 존재하며, 기술한 유형에 따라 마크업 문서의 요소와 속성들을 처리하는 기준이 되며 유효성 검사에 이용된다. 우리가 사용하는 HTML5는 DTD 참조가 필요없어서, 위 코드와 같이 간단히 선언할 수 있다. MDN 문서에는 아래와 같이 기술되어 있다.

최근에는 아무도 그런 것들에 대해 신경쓰지 않으며 그저 모든 것이 올바르게 동작하게 하기 위해 포함되어야 할 역사적인 유물일 뿐입니다. 지금은, 그게 알아야 할 전부 입니다.

html 이 요소는 페이지 전체를 감싸며, 루트 요소라고도 한다. lang 속성을 통해 문서에 사용된 언어를 지정할 수 있다.

head 이 요소는 페이지를 조회하는 사람들에게 보여주지 않을 컨텐츠의 컨테이너 역할을 한다. 여기에는 검색결과에 표시되기 원하는 페이지 설명, 스타일, 스크립트 등이 포함된다.

body 이 요소는 페이지 방문자들에게 보여주길 원하는 컨텐츠의 컨테이너 역할을 한다.

block 형식의 태그와 inline 형식의 태그에 대해 알아보자

inline : 줄바꿈 없이 내용만큼만 영역을 차지 ex) span, a, input, img, b, i, strong, em 등 글자 관련 태그 block : 내용의 길이와 상관없이 가로 한 줄을 모두 차지 ex) div, h1~h6, p, li, table, form

inline 형식의 태그는 block 형식의 태그를 감쌀 수 없다.

글자, 문단 관련 태그

<br> : 엔터와 동일하게 줄 바꾸는 태그 <p> : 문단을 띄울 때 사용, 연속으로 사용해도 한번만 적용 <p>~</p> : 문단을 묶을 때 사용 <div>~</div> : block 형식으로 공간을 분할 <span>~</span> : inline 형식으로 공간을 분할 <Hn>~</Hn> : n은 16까지, 숫자가 작을수록 글자가 크다. color 속성이 적용되지 않는다. ` 또는 : 굵은 글자 또는 : 이탤릭체 또는 : 밑줄글자: 가운데 줄이 그어진 글자: 윗첨자` : 아래첨자

이미지 삽입 태그

이미지를 삽입할 때 사용한다. src 속성에는 이미지의 위치, alt에는 이미지에 대한 설명을 넣을 수 있다. 이미지가 오류로 인하여 표시되지 못할 때나, 시각 장애가 있는 분들을 위해 이미지에 대한 설명을 적을 수 있는 alt 속성을 추가하는 편이 좋다.

<img src="이미지 위치" alt="이미지에 대한 설명">

이미지에 캡션을 붙일 때

<figure>
  <img src="apple.png" alt="사과">
  <figcaption>이것은 사과입니다.</figcaption>
</figure>

이미지에 여러개의 하이퍼링크를 연결시킬 때

<img src="apple.png" alt="사과" usemap="#map">
<map name="map">
  <area shape="rect | circle | poly" coords="좌표" href="">
</map>

하이퍼링크 태그

<a href="연결할 주소" target="표현방법">velog로 이동</a>

href 속성의 값으로는 http://velog.io와 같은 사이트나 프로젝트 내부의 파일 또는 특정한 위치 (ex: <a name="이름"></a> <a href="#이름">특정한 위치로</a> 에 연결할 수 있다. 주의할 점은 a태그의 name 속성은 id의 역할을 하기 때문에 다른 태그의 id와 a태그의 name이 같은 경우, 기능이 동작하지 않는다.

폼 태그

<form
  action="폼을 전송할 서버쪽의 스크립트 파일 지정"
  name="폼을 식별하기 위한 이름"
  method="폼을 전송할 방식, GET 또는 POST">
</form>

Form 안에서 사용되는 input의 주요 타입으로는 hidden, email, password, file 등이 있다. 사실 리액트나 뷰로 개발하다보면 잘 만들어진 UI Framework를 사용하기에..직접 form을 만들어 사용할 일은 잘 없다. 개인적으로는 blade template에 작업할 일이 좀 있어서 좀 사용하긴 했다.

인풋 태그

주로 쓰는 속성은 readonly, placeholder 정도...

현재 진행중인 프로젝트는 React와 Typescript, Mobx 를 사용하여 진행 중이다.

api를 공통으로 사용하는 페이지가 많아서, 공통 스토어를 두고 각 페이지에서 사용할 스토어들에서 상속을 받았다.

class SaleStore extends common {}
class PurchaseStore extends common {}

common 클래스에 있는 변수값만 각기 다르게 가지면 됐기에, 생성자를 통해 값을 넣어줬다.

export const storesContext = React.createContext({
  saleStore: new SaleStore(1),
  purchaseStore: new PurchaseStore(2),
  commonStore: new CommonStore(),
  authStore: new AuthStore(),
  sideMenuStore: new SideMenuStore(),
  dealStore: new DealStore(),
  clientsStore: new ClientsStore(),
  creditsStore: new CreditsStore(),
  productsStore: new ProductsStore(),
  systemsStore: new SystemsStore(),
  categoriesStore: new CategoriesStore(),
  brandsStore: new BrandsStore(),
  stocksStore: new StocksStore(),
  orderStore: new OrderStore(4),
  contractStore: new ContractStore(5)
});

export const useStores = () => React.useContext(storesContext);

그리고 각 페이지를 테스트 하는데, 왠걸? 스토어 하나를 돌려쓰는 것이었다.

뭐가 문제지?

첫번째 - 꼼수 사용. 스토어를 프로바이더에 넣기 전에 인스턴스를 다시 만들어서 넣어줌 - 실패 두번째 - 중앙스토어를 컨텍스트를 사용하는 방식으로 변경 - 당연히 실패

스택오버플로우에도 들어가보고, 레딧에 질문을 올리고, 깃허브에 이슈도 생성 레딧에서 착한분이 금방 댓글을 달아주셨는데..내가 올린 샘플코드가 문제 없이 잘 나온다고..

팀장님께 뭐가 문제인지 물어봤지만, 각기 새로운 인스턴스를 생성했는데 오버라이딩이 되는게 말이 안된다고..

결국 퇴근하고 집에와서,

세번째 - 그냥 다 까보자. 새로운 프로젝트를 만들고, 코드를 옮겨서 하나씩 다 지워나갔다.

그리고 찾은 원인!

store에서 내가 무슨 생각이었는지 모르겠지만 @computed 대신 @get을 아무런 의심없이 사용하고 있었다. 다른 스토어는 @computed를 사용했으면서... 후...이걸로 한 6시간 고민한 문제가 어이없이 해결됐다.

결론: 몹엑스 사용시 스토어에서 @get을 사용하면 클래스 상속이 제대로 안된다.

끗-

Mobx를 활용하여 로그인 기능을 구현해보겠습니다.

먼저, 스토어를 생성해보겠습니다.

src/store/authStore.ts

import { observable, action, computed } from "mobx";
import loginApi from "@/Views/Auth/api/authApi";
import { AuthData } from "@/common/interface/auth";

class AuthStore {

  @observable userData: authInfo | null = null;

  @computed get isLogged() {
    this.userData = JSON.parse(<string>localStorage.getItem('authInfo'));
    return !!this.userData;
  }

  @computed get getAccessToken() {
    return this.userData!.token;
  }

  @action
  async login(authData: AuthData) {
    let result = await loginApi.login(authData);
    localStorage.setItem('authInfo',JSON.stringify(authInfo.data.authInfo));
    return result;
  }

}

export default AuthStore;

interface authInfo {
  tokenType: string
  token: string
  userId: string | number
  lastLogged: string
}

이 예시에서는 스토어를 하나만 만들겠지만, 차후 늘어날 스토어들을 관리할 중앙 관리소를 만들겠습니다. 그리고 프로바이더를 사용해 스토어를 주입합니다.

src/store/index.ts


import AuthStore from "@/store/authStore";

export default {
  authStore = new AuthStore(),
}


src/index.tsx

import store from '@/store';
import { Provider } from 'mobx-react';

const app = (
    <Provider {...store}>
        <App />
    </Provider>
);

ReactDOM.render(app, document.getElementById('root'));

이제 스토어를 사용해보겠습니다. 컴포넌트에 inject를 사용해서 스토어를 주입하면 props로 사용할 수 있습니다. 만약 여러 스토어를 사용하고 싶다면, 'authSotre', 'dealStore' 이런 식으로 추가하시면 됩니다.

src/Views/Auth/Login.tsx


import React, { useState } from 'react';
import AuthStore from "@/store/authStore";

interface Props extends RouteComponentProps {
  authStore: AuthStore
}

const Login = inject("authStore")(observer(({authStore, history}: Props) => {

  const [authData, setAuthData] = useState<AuthData>({
    email: '',
    password: '',
  });

  async function tryLogin() {
    try {
      const result = await authStore.login(authData);
      if (result.status === 200) {
        history.push('/dashboard');
      }
    } catch (e) {
      console.log(e)
    }
  }

  return (
      <>
    </>
  )

  export default Login;

처음 다뤘던 프레임워크가 뷰였어서 그런지, 뷰엑스와 비슷한 몹엑스가 훨씬 직관적이고 편했습니다. 리덕스를 사용해보진 않았지만...보기만해도 너무 복잡해 보였습니다. 언젠가는 배우겠지만, 선택할 수 있다면 몹엑스를 계속 사용할 듯 합니다.

본 작업에 앞서, 페이스북 개발자 사이트에서 키를 발급받아야 합니다. 하지만 이 부분은 스킵하도록 하죠.

일단, 컴포넌트를 하나 생성해 줍니다.

const FbLogin = ({}) => {
  return (
    <Button>페이스북 로그인</Button>
  );
};  

그 다음, Facebook SDK를 불러오겠습니다.

useEffect(() => {
  setFBAsyncInit();
  loadSdkAsynchronously();
}, []);

function setFBAsyncInit() {
  (window as any).fbAsyncInit = () => {
    (window as any).FB.init({
      version: `v6.0`, // 작성일 기준 버전이 v6.0 입니다.
      appId: 'appId', // 발급받은 App ID 를 넣어줍니다.
      xfbml: true,
      cookie: true,
    });
  };
}

function loadSdkAsynchronously() {
  ((d, s, id) => { //이런것 까지 타입을...잡아야 하는지는 잘 모르겠습니다 ;ㅅ;
    const element = d.getElementsByTagName(s)[0];
    const fjs = element as Element;
    let js = element as any;
    if (d.getElementById(id)) {
      return;
    }
    js = d.createElement(s);
    js.id = id;
    js.src = `https://connect.facebook.net/en_US/sdk.js`;
    fjs.parentNode!.insertBefore(js, fjs);
  })(document, 'script', 'facebook-jssdk');
}

그 다음 버튼에 클릭이벤트를 추가하고

return (
  <Button onClick={checkLogin}>페이스북 로그인</Button>
);

페이스북에 로그인이 돼있는지 여부를 체크해봅니다.

function checkLogin() {
  (window as any).FB.getLoginStatus((checkResponse: Response) => {
    checkState(checkResponse)
  });
}

function checkState(checkResponse: Response) {
  if (checkResponse.status === 'connected') {
    // 로그인 돼있을 때 작업
  } else {
    // 로그인이 되어있지 않다면 ('not_authorized' | 'unknown')
    (window as any).FB.login((response: Response) => {
     // 로그인 하거나 회원가입 할 수 있는 팝업을 띄웁니다.
    })
  }
}

interface Response {
  status: 'connected' | 'not_authorized' | 'unknown'
  authResponse: null | AuthResponse
}

interface AuthResponse {
  accessToken: string,
  expiresIn: number,
  signedRequest: string,
  userId: string
  data_access_expiration_time: number
  graphDomain: string
}

마지막으로 유저정보를 받아오겠습니다. 저는 이름과 이메일을 받아오기 위해서 필드값으로 이메일과 이름을 넣었습니다. 인자를 넘기지 않을 경우 기본적으로는 이름과 아이디값이 넘어옵니다.

function checkState(checkResponse: Response) {
    if (checkResponse.status === 'connected') {
      getUser();
    } 
  ...
}

function getUser() {
  FB.api('/me', {fields: ['email', 'name']}, (response: userData) => {
    console.log(response)
  });
}

이렇게 페이스북 로그인 버튼 컴포넌트를 만들어봤습니다. 저처럼 라이브러리를 사용하기 꺼림칙한데 검색하니 라이브러리밖에 안나와서 고민중인 초보개발자 분들에게 조금이나마 도움이 되길 바랍니다.