휴대전화, 사업자번호 등 사용자가 입력한 값에 자동으로 하이픈(-)을 붙여주는 간단한 로직이 필요했습니다. 분명히 이전에도 설정했던 로직인데도 또 다시 머리를 싸매게되어 미래의 나를 위해 정리해둡니다.

요구사항

• props로 포맷 자리수를 배열로 받기 (예: [3, 4, 4], 네이밍 numberTextFormat)
• 해당 포맷 형식으로 하이픈 자동 삽입 (01012345678 → 010-1234-5678)
• type="text" + inputMode="numeric" (010 등 0으로 시작하는 값 반영)
• props로 setValue,onChange 등을 통해 포맷팅된 값을 전달

1차 시도: onChange에서 포맷팅

const formatNumberText = (raw: string, format: number[]) => {
  const result: string[] = []
  let cursor = 0

  for (const len of format) {
    const part = raw.slice(cursor, cursor + len)
    if (part) result.push(part)
    cursor += len
  }

  return result.join('-')
}

const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  const raw = e.target.value.replace(/\D/g, '')
  const formatted = formatNumberText(raw, numberTextFormat)
  // props로 받은 value, (formatted string을 파라미터로 받는) setValue
  setValue(formatted)
}

이 방식은 입력 자체는 잘 되지만, 예상치 못한 문제가 생깁니다. 010-123 상태에서 두번째 0을 지우려고 커서를 1 앞으로 이동하여 Backspace를 누르면, -가 지워지고 010123로 변경된 value는 다시 포맷팅되어, 의도한 대로 지워지거나 이동하는 것이 아니라 버벅이는 느낌이 듭니다. 따라서 사용자가 지우려던 하이픈 앞 숫자로 자연스럽게 이동하기 위해 입력 전후 하이픈의 개수 차이를 계산해서 커서를 보정해줘야 합니다.

2차 시도: 커서 위치 보정

const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  const prevFormatted = prevFormattedRef.current

  const maxLength = numberTextFormat.reduce((a, b) => a + b, 0)
  const raw = e.target.value.replace(/\D/g, '').slice(0, maxLength)
  const newFormatted = formatNumberText(raw, numberTextFormat)

  // 커서 위치 보정
  const cursor = e.target.selectionStart ?? newFormatted.length
  requestAnimationFrame(() => {
    const el = inputRef.current
    if (!el) {
      return
    }

    // 입력 전후 하이픈 개수 차이 → 커서가 밀려야 하는 거리
    const prevOffset = prevFormatted.slice(0, cursor).replace(/\d/g, '').length
    const newOffset = newFormatted.slice(0, cursor).replace(/\d/g, '').length
    const diff = newOffset - prevOffset

    const newCursor = cursor + diff
    el.setSelectionRange(newCursor, newCursor)
  })

  setValue(newFormatted)
  prevFormattedRef.current = newFormatted
}

이 방법으로도 충분하지만, 프로젝트에서는 파일, select 등 사용자에게 입력받는 컴포넌트들이 여러가지가 있었는데요. 이들의 공통적인 처리를 위하여 외부에서 change event를 받아 사용하고싶었습니다.

3차 시도: fake event 생성

const fakeEvent = {
  ...e,
  target: { ...e.target, value: newFormatted },
}
onChange(fakeEvent)

원래 있던 이벤트에 e.target.value만 변경하면 됐기 때문에, 위와 같이 이벤트를 만들어 onChange 함수를 호출하면 될 것이라 생각했습니다. 하지만 일부 DOM 속성들은 getter로만 존재하고 enumerable하지 않기 때문에 onChange 함수를 호출할 때에 e.target.id, name 등이 없었고, Uncaught TypeError: Illegal invocation 에러도 발생했습니다. 따라서 아래와 같이 Proxy 설정으로 우회가 필요했습니다.

const fakeEvent = Object.create(e)
Object.defineProperty(fakeEvent, 'target', {
  value: new Proxy(e.target, {
    get(target, prop) {
      return prop === 'value' ? newFormatted : target[prop as keyof HTMLInputElement]
    },
  }),
})
Object.defineProperty(fakeEvent, 'currentTarget', {
  value: new Proxy(e.target, {
    get(target, prop) {
      return prop === 'value' ? newFormatted : target[prop as keyof HTMLInputElement]
    },
  }),
})
onChange(fakeEvent as React.ChangeEvent<HTMLInputElement>)

이렇게 하면 value만 위장하고, id, name, dataset은 원래대로 유지됩니다.

결론

• 자연스러운 numeric input 포맷팅을 위해서는 커서 보정도 추가로 필요
• 외부에서 일반 onChange로 호출하려면 value만 오버라이드한 fake event 생성
• 같은 방식으로 YYYY-MM-DD, 카드번호, 사업자번호 등에 쉽게 응용 가능

아래는 textArea와 함께 사용한 코드 전문입니다.

const formatNumberText = (raw: string, format: number[]) => {
  const result: string[] = []
  let cursor = 0

  for (const len of format) {
    const part = raw.slice(cursor, cursor + len)
    if (part) result.push(part)
    cursor += len
  }

  return result.join('-')
}

const handleChange = (_e: React.ChangeEvent<HTMLInputElement | HTMLTextAreaElement>) => {
  _e.preventDefault()
  if (!numberTextFormat?.length) {
    onChange(_e)
    return
  }

  const e = _e as React.ChangeEvent<HTMLInputElement>
  const maxLength = numberTextFormat.reduce((a, b) => a + b, 0)
  const raw = e.target.value.replace(/\D/g, '').slice(0, maxLength)
  const newFormatted = formatNumberText(raw, numberTextFormat)
  const prevFormatted = value

  // fake event 생성
  const fakeEvent = Object.create(e)
  Object.defineProperty(fakeEvent, 'target', {
    value: new Proxy(e.target, {
      get(target, prop) {
        return prop === 'value' ? newFormatted : target[prop as keyof HTMLInputElement]
      },
    }),
  })
  Object.defineProperty(fakeEvent, 'currentTarget', {
    value: new Proxy(e.target, {
      get(target, prop) {
        return prop === 'value' ? newFormatted : target[prop as keyof HTMLInputElement]
      },
    }),
  })
  onChange(fakeEvent as React.ChangeEvent<HTMLInputElement>)

  // 커서 위치 보정
  const cursor = e.target.selectionStart ?? newFormatted.length
  requestAnimationFrame(() => {
    const el = inputRef.current
    if (!el) return

    const prevOffset = prevFormatted.slice(0, cursor).replace(/\d/g, '').length
    const newOffset = newFormatted.slice(0, cursor).replace(/\d/g, '').length
    const diff = newOffset - prevOffset
    const newCursor = cursor + diff

    el.setSelectionRange(newCursor, newCursor)
  })
}

Test Driven Development란

소프트웨어 개발 방법론 중 하나로, 개발 자체가 “테스트"에 의해 주도되는 방식이다. 제품의 기능 구현을 위한 코드와 별개로, 해당 기능이 정상적으로 움직이는지 검증하기 위한 테스트 코드를 먼저 작성한다.

TDD 개발 단계

1. ReadMe Driven Development : 요구사항 기술
2. Make it RED(fail) : 테스트 코드 작성
3. Make it GREEN(success) : 실제 코드 작성
4. Make it BLUE(refactoring) : 최소한으로 작성된 코드 리팩토링

왜 TDD를 사용하는가?

일반적인 개발방식을 사용하는 경우, 소비자의 요구사항이 처음부터 명확하지 않을 수 있어 처음부터 완벽한 설계는 어렵다. 또한 반복되는 재설계와 코드의 재작성은 제품의 품질을 떨어뜨린다. 작은 기능 수정에도 모든 부분을 다시 테스트해야 하므로, 테스트 비용이 증가한다. TDD는, 기능별로 테스트코드와 제품코드를 작성하므로 종속성과 의존성이 낮은 모듈화된 방식으로 개발하게 된다. 이는 재설계, 디버깅 시간을 단축시키고 추가 구현에 용이하다. (특히 기존 코드에 미칠 수 있는 영향을 최소화할 수 있다)

라이브러리 설치 및 소개

JEST

페이스북에서 만든 JavaScript 테스팅 라이브러리이다. react-native-cli로 프로젝트 구성시, 이미 dev dependency에 포함되어있다.

• describe() : 여러 개의 테스트 코드를 하나의 테스트 작업 단위로 묶어주는 API
• test() : 테스트 코드를 돌리기 위한 API. 하나의 테스트 케이스를 의미
• expect() : 테스트할 대상(기대 값)을 넣는 API
• beforeEach() : 각 테스트 코드가 돌기 전에 반복적으로 수행할 로직을 넣는 API

Enzyme

에어비앤비에서 만든 React 컴포넌트 테스팅 라이브러리이다. enzyme, enzyme-adapter-react, react-dom를 함께 설치한다.

• shallow: 간단한 컴포넌트를 메모리에 렌더링 (단일 컴포넌트를 테스트)
• mount: HOC나 자식 컴포넌트 까지 전부 렌더링 (다른 컴포넌트와의 관계 테스트 )
• render: 컴포넌트를 정적인 html로 렌더링 (컴포넌트가 브라우저에 붙었을 때 html로 어떻게 되는지 판단할 때 사용)

Detox

사용자 관점에서 End to End로 테스트하기 위한 라이브러리이다. android/ios 모두 지원하지만 우선은 ios에서만 테스트해보았다. applesimutils, detox-cli, detox, jest-circus를 함께 설치한다.

• 실제로 사용자 관점에서 테스트하기위한 async 기능 제공

ToDoList 테스트코드 작성

컴포넌트 렌더링 및 props 확인

아래와 같은 간단한 ToDo 리스트에 대한 테스트코드를 작성해보자!

먼저 앱을 처음 실행했을 때에 화면 제목으로 사용될 Text 컴포넌트 내에 "TODO TDD"라는 내용이 들어가있는지, AddToDo와 ToDoList가 존재하는지는 아래와 같이 작성할 수 있다.

describe('App', () => {
  const wrapper = shallow(<App></App>);
  test('snapshot test', () => {
    expect(wrapper).toMatchSnapshot();
  });
  it('is Text visible?', () => {
    expect(wrapper.find('Text').contains('ToDo TDD')).toBe(true);
  });
  it('is AddToDO visible?', () => {
    expect(wrapper.find('AddToDo')).toHaveLength(1);
  });
  it('is ToDoList visibla?', () => {
    expect(wrapper.find('ToDoList')).toHaveLength(1);
  });
});

AddToDo 컴포넌트는 TextInput과 버튼으로 구성되어있고, 버튼 클릭 시 TextInput 내부에 있는 내용으로 (props로 가지고 있는) OnAdded 함수를 호출한다. 내부에 해당하는 컴포넌트가 있는지 확인하는 동작은 위의 코드와 비슷하게 작성하면 되니, 함수 호출과 관련된 부분의 작성법은 아래와 같다. 테스트를 진행하기 전에 AddToDo를 렌더링하고 TextInput 내용을 작성하고 버튼을 누른다. 이후 it에서 OnAdded 함수가 불렸는지, 텍스트 내용을 가지고 불렸는지를 확인한다.

describe('AddToDo Interaction', () => {
  let wrapper;
  let props;
  const text = 'Add To Do Item';

  beforeEach(() => {
    props = {
      onAdded: jest.fn(),
    };
    wrapper = shallow(<AddToDo {...props}></AddToDo>);
    wrapper.find('TextInput').simulate('changeText', text);
    wrapper.find('Button').prop('onPress')();
  });

  it('should call the onAdded callback with input text', () => {
    expect(props.onAdded).toHaveBeenCalledTimes(1);
    expect(props.onAdded).toHaveBeenCalledWith(text);
  });
});

ToDoRenderITem에 대한 테스트 코드 작성도 비슷하다. 기본적으로 내부에 Text, Button들이 알맞게 자리하고 있는지, 초기 스타일은 어떻고 만약 props로 특정 데이터가 들어오면 어떤 다른 스타일을 가지고있는지를 확인한다. 이후 각 버튼이 클릭됨에 따라 적절한 함수가 알맞게 불렸는지를 확인할 수 있다.

// component rendering
describe('rendering', () => {
  let warpper;
  let props;

  beforeEach(() => {
    props = {
      item: {},
    };
    wrapper = shallow(<ToDoRenderItem {...props}></ToDoRenderItem>);
  });

  it('should render a Text', () => {
    expect(wrapper.find('Text')).toHaveLength(1);
  });

  it('should render two buttons', () => {
    expect(wrapper.find('Button')).toHaveLength(2);
  });

  describe('Uncompleted', () => {
    it('should have the default style', () => {
      expect(wrapper.prop('style')).toBe(styles.default);
    });
  });

  describe('Completed', () => {
    beforeEach(() => {
      props.item.completed = true;
      wrapper = shallow(<ToDoRenderItem {...props}></ToDoRenderItem>);
    });
    it('should have the completed style', () => {
      expect(wrapper.prop('style')).toBe(styles.completed);
    });
  });
});

// interaction
describe('interaction', () => {
  let wrapper;
  let props;
  beforeEach(() => {
    props = {
      item: {text: 'first ToDo', completed: false},
      index: 0,
      onCompleted: jest.fn(),
      onDeleted: jest.fn(),
    };

    wrapper = shallow(<ToDoRenderItem {...props}></ToDoRenderItem>);
  });

  it('Complete feature', () => {
    wrapper.find('Button').at(0).prop('onPress')();
    expect(props.onCompleted).toHaveBeenCalledTimes(1);
    expect(props.onCompleted).toHaveBeenCalledWith(props.index);
  });

  it('Delete feature', () => {
    wrapper.find('Button').at(1).prop('onPress')();
    expect(props.onDeleted).toHaveBeenCalledTimes(1);
    expect(props.onDeleted).toHaveBeenCalledWith(props.index);
  });
});

뭔가 세미나에서 이야기하다가 그럼 이 모든 코드를 하나의 파일로 작성해야 하냐는 질문을 받았는데, yarn test 명령어를 실행하면 해당 폴더 내의 모든 테스트코드 파일들이 실행되고 확인되니 컴포넌트별, 기능별로 알맞게 잘 나눠서 쓰면 된다

처음 파일을 실행하면 모든 테스트들이 실패했다고 나올 것이다. 앞에서 말했던 RED단계이다! 이제 테스트코드들을 통과할 수 있는 GREEN 단계를 진행하면 된다. (BLUE 단계는 이후 테스트 코드와 관계 없이 진행되는 단계임을 잊지말자) 만약 해당하는 테스트 코드를 다 통과할 수 있도록 코드를 작성했다면, yarn test 명령어를 통해 실행할 경우 아래와 같은 결과를 확인할 수 있을 것이다.

Detox를 통해 E2E 동작 확인하기

컴포넌트의 렌더링이나 내부 데이터 확인 등은 앞과 같이 확인할 수 있지만, 사용자가 실제로 서비스를 사용하는 시나리오들이 모두 정상적으로 동작하는지는 어떻게 확인할 수 있을까? Detox의 End To End 테스트 기능을 통해 TodoRenderItem을 사용자가 직접 추가/완료, 삭제하는 과정이 정상적으로 동작하는지를 확인해보도록 하자.

• 추가 및 완료 : 사용자가 입력 필드에 내용을 입력하고, 추가 버튼을 클릭하고, 미완료 상태의 ToDoRenderItem이 정상적으로 추가되었는지를 확인한다. 이후 완료 버튼을 클릭하면 해당 아이템이 완료 상태로 전환되었는지를 확인하면 완료된다.
• 삭제 : 앞과 비슷하게 입력 필드에 내용을 입력하고, 추가 버튼 클릭, 목록에 추가되는지를 확인한다. 이후 삭제 버튼을 클릭했을 때에 목록에 아이템이 삭제되어 표시되지 않는지를 확인한다.

describe('Interaction Test', () => {
  beforeAll(async () => { // 처음에 앱을 실행하고
    await device.launchApp();
  });
  beforeEach(async () => { // 매 테스트마다 리로드를 통해 혹시 모를 영향을 끼칠 요소들을 방지하자
    await device.reloadReactNative();
  });

  it('Completing ToDo Item should work!', async () => {
    const text = '입력 완료 여부 체크';
    await element(by.id('textInput')).tap();
    await element(by.id('textInput')).typeText(text);
    await element(by.id('addButton')).tap();
    await element(by.id('completeButton')).multiTap(1);
    await expect(
      element(
       // toDoList라는 아이템 내에 '입력 완료 여부 체크'라는 내용을 
       // 가진 텍스트가 있는지 확인하고, 
       // 그 아이디가 현재 testId로 'completed'를 가지고있는지 확인한다.
        by.id('completed').and(by.text(text)).withAncestor(by.id('toDoList')),
      ),
    ).toBeVisible(); 
  });

  it('Deleting ToDo Item should work!', async () => {
    const text = '입력 삭제 여부 체크';
    await element(by.id('textInput')).tap();
    await element(by.id('textInput')).typeText(text);
    await element(by.id('addButton')).tap();
    await element(by.id('deleteButton')).multiTap(1);
    await expect(
      element(by.text(text).withAncestor(by.id('toDoList'))),
    ).not.toBeVisible(); // not toBeVisible
  });
});

detox build -c ios로 빌드하고 detox test -c ios로 테스트하면 아래와 같은 결과를 확인할 수 있다. 테스트 커맨드 실행시 아래와같이 실제로 앱이 동작하면서 사용자가 텍스트 입력, 버튼을 클릭하는 것을 그대로 실행하면서 시나리오가 진행되는 것을 눈으로 보면서 테스트할 수 있다. 실행 중에 터미널을 확인하면 해당 테스트가 실행됨에 따라 실행이 정상적으로 완료되었다고 [OK] 문구가 추가되고, 테스트에 성공/실패했는지 여부를 자세하게 알려준다. QA 시간을 획기적으로 단축할 수 있어보여 개인적으로 너무 마음에 들었다.

중간에 코드를 바꾼 이후 리로드되어 자동으로 코드에 반영되어야 한다고 생각했는데, 정작 세미나에서 계속 안되어서 아예 detox build된 내용을 아예 날리고 확인하니 정상적으로 진행되었다. (게다가 xcode clean build를 위한 커맨드를 날리고 다시 빌드했었는데, 알고보니 그 클린 커맨드가 작동이 안되었었다.. xcode로 빌드된게 아니라나 뭐라나 ㅠㅠㅠ 엄청 당황했다!!) 안되면 그냥 detox 공식문서에서 하라는 대로 하자..!

꼭 TDD를 써야할 필요는 없다.

물론, 모든 프로젝트와 기타 모든 상황에서 TDD를 무조건 사용해야 하는 것은 아니다. TDD를 처음 도입할 때에는 이를 사용하지 않을 때보다 초기비용이 크게 들기 마련이다(테스트코드 작성). 또한 TDD는 버그를 사전에 발견할 수 있게 하는 것일 뿐, 버그 “해결"은 결국 개발자의 몫이라는 것도 잊어서는 안된다. 게다가 단순히 반복적으로 테스트코드를 복붙하고 의미없이 사용하는 것은 업무프로세스 증가로 이어지기만 할 뿐이다. TDD는 공동의 목표를 효율적으로 달성하기 위한 “도구”로, 잘 사용하는 것은 결국 우리들의 손에 달려있다는 것을 잊어서는 안된다

일반적으로 프론트엔드는 백엔드에서 swagger와 같은 문서 툴로 정의된 API 명세를 전달받게 됩니다. 자바스크립트에서라면 바로 fetch 혹은 axios로 api에 요청하는 코드를 작성하면 되지만, 타입스크립트의 경우 swagger에 명시된 타입을 바탕으로 추가적인 타입을 정의하는 단계가 필요합니다. 하나의 요청/응답에는 한두개부터 수십개까지의 타입 정의가 필요하며, 규모가 커지거나 변경사항이 있을 경우 생산성에 영향이 있을 수 있습니다. OpenAPI Generator는 OpenAPI Specification를 만족하는 API 명세(yaml 또는 json 파일)로부터 요청과 응답에 필요한 타입들과 호출 함수들을 자동으로 생성하여 이러한 문제를 해결할 수 있습니다.

OpenAPI Generator 실행

JDK가 함께 필요하기 때문에 설치되지 않은 경우 설치/환경변수 설정을 먼저 해주어야 합니다.

아래의 npx 명령어를 사용하여 추가적인 설치 없이 OpenAPI Generator을 사용할 수 있습니다.

> npx @openapitools/openapi-generator-cli generate -i <file> -g <generator> -o <directory>

개별적으로 npm, homebrew, scoop, docker를 사용하여 글로벌하게 설치할 수도 있습니다.(참고 : https://openapi-generator.tech/docs/installation)

> npm install @openapitools/openapi-generator-cli -g
> brew install openapi-generator
> scoop install openapi-generator-cli

OpenAPI Generator 실행 옵션

OpenAPI Generator CLI를 실행하는 옵션은 다음과 같습니다.

-i: 포함할 파일 목록 작성
-g: generator 이름
-o: 저장할 디렉토리 이름

OpenAPI Generator가 생성할 수 있는 generator에는 typescript-axios, javascript-fetch, javascript-axios, typescript-fetch 등이 있습니다. 더욱 많은 generator 리스트는 https://openapi-generator.tech/docs/generators/ 에서 확인할 수 있습니다.

Example

OpenAPI INITIATIVE에서는 몇가지 예제 데이터를 제공하고 있는데, 그 중 petstore.yaml 파일과 이를 바탕으로 타입과 호출 함수들을 생성해보겠습니다.

예시 데이터에서 OpenAPI Generator 실행

> cd example
> npx @openapitools/openapi-generator-cli generate \
    -i petstore.json \
    -g typescript-axios \
    -o typescript-axios/

위의 명령어를 실행하면 generated된 코드들을 typescript-axios 폴더에서 확인하실 수 있습니다.

프로젝트 관리: subtree

1. 상위 레포지토리에서 서브트리 원격 저장소 추가

git remote add subtree-test subtree-test.git

상위 레포지토리에서 서브트리를 fetch, pull, push 하기 위해 서브트리로 사용할 현재의 Git 저장소를 상위 저장소의 새로운 원격 저장소로서 추가합니다. 아래에서는 폴더의 이름을 원격 저장소의 이름과 동일하게 cm-api-specification로 지정하였으나, 각 상위 레포지토리에서 다르게 지정할 수 있습니다. 저장소 추가 후에는 git remote 명령어로 옳게 추가되었는지 확인합니다.

2. 상위 레포지토리에서 서브트리 추가

git subtree add --prefix subtree subtree-test master

명령어의 각 요소는 git subtree add --prefix <클론할 폴더> <원격 저장소의 이름> <브랜치 이름> <squash 여부> 순서입니다. --prefix 옵션은 서브트리를 클론할 폴더를 지정하고, 클론될 서브트리 원격 저장소의 이름, 체크아웃할 브랜치 이름을 지정하면 서브트리가 추가됩니다.

서브트리를 추가할 때에 subtree에 존재하던 기존의 모든 커밋을 가져오지 않으려면 squash 옵션을 뒤에 추가하면 됩니다. 단, --squash 옵션을 추가한 경우 이후 git subtree pull 명령어를 실행할 때에도 --squash 옵션을 마지막에 추가해주어야 합니다. 동일 레포지토리로 인식하지 못하고 fatal: refusing to merge unrelated histories 에러가 발생할 수 있습니다.

서브트리가 옳게 추가되면 상위 레포지토리의 폴더 구조는 아래와 같습니다.

상위 레포
├─ README.md (상위 레포지토리의 파일)
└─ subtree-test (서브트리 폴더)
   └─ README.md (서브트리의 파일)

3. 상위 레포지토리에서 서브트리 업데이트

상위 레포지토리에서 서브트리의 변경사항을 내려받고 업데이트하는 명령어는 아래와 같습니다.

> git remote update 또는 git fetch subtree-test master
> git subtree pull --prefix subtree subtree-test master

> git subtree push --prefix subtree subtree-test master

변경사항이 있는 경우 자동으로 머지 커밋이 생성될 수 있으며, 명령어가 짧지 않으므로 각 상위 폴더에서 npm 스크립트 등을 작성하여 사용하는 편이 좋습니다.

그 외

• 상위 레포지토리에서 서브트리 제거
  서브트리는 단순히 폴더로서 추가되어, git rm -r <폴더 이름> 명령어를 입력하면 됩니다.
• 상위 레포지토리에서 일부 폴더를 분리
  git subtree split -P {디렉터리} -b {브랜치명}

• for
  • 기본형

    for (let i = 0; i < 9; i++) {
     console.log(i)
    }

• forEach
  • Array의 prototype을 상속받은 객체가 사용할 수 있는 함수
  • 반복문이 아니라 '함수'. 인자로 함수를 받아 각 배열의 요소에 해당 함수를 적용한다
• for ... in
  • Object에 있는 key에 차례로 접근
  • Array에도 사용할 수도 있지만 일반적으로 Object를 제외한 객체에는 사용하지 말 것
  • for in으로 순회 시, prototype chain을 따라 확장 속성들도 함께 순회
    • 필요 시 Object.keys()로 확장 속성을 피해서만 반복 가능
• for ... of
  • 이터러블한 객체를 모두 순회 가능
  • 내부에 [Symbol.iterator]를 가진 객체라면 어떤 객체든 순회할 수 있으나, 없는 객체는 불가

Hash

• new Map()
  • map.entries()는 iterator 반환
  • map.delete() : 성공 시에만 true
  • map.set()
  • map.get()
  • map.forEach((value, key, map) => { /* ... */ })

    function solution(participant, completion) {
    var answer = '';
    const map = new Map();
    completion.forEach(completePlayer => {
       if (map.get(completePlayer))
           map.set(completePlayer, map.get(completePlayer)+1)
       else map.set(completePlayer, 1)
    })
    participant.forEach(participatedPlayer => {
       if (!map.get(participatedPlayer))
           answer = participatedPlayer
       else map.set(participatedPlayer, map.get(participatedPlayer)-1)
    })
    return answer;
    }

Set

let setA = new Set();
setA.add('a');
setA.add('b');
setA.add('a');
console.log([...setA.keys()]); // ['a', 'b']
console.log([...setA.values()]); // ['a', 'b']

List

• arr.indexOf(a) ==> 존재하지 않으면 -1 반환
• arr.lastIndexOf(a) ==> 존재하지 않으면 -1 반환
• arr1.concat(arr2) ==> 원본 배열 수정 없이 새로운 배열 반환
• arr.slice(start, end?) ==> 원본 배열 수정 없이 새로운 배열 반환
• arr.splice(start, n?) ==> 원본 배열에서 start~start+n-1까지를 삭제, 삭제된 배열값 반환
• arr.shift() ==> 원본 배열에서 첫 번째 요소를 제거하고, 제거된 요소를 반환
• arr.unshift(...args) ==> 원본 배열 왼쪽에 요소들을 추가하고, 추가된 배열의 길이를 반환

  • const array1 = [1, 2, 3];
    console.log(array1.unshift(4, 5)); // 5
    console.log(array1); // [4,5,1,2,3]

• arr.flat(n) ==> 원본 배열을 n차원만큼 flatten하게 바꿈. 빈 값은 자동 제거
• 리스트에서 특정 원소의 갯수 찾기
  • arr.filter(x => x==n).length
• 가장 큰 원소의 index 찾기
  • let i = arr.indexOf(Math.max(...arr));

Sort

• arr.sort()
  • sort 인자로 비교 함수가 없을 경우, 유니코드 순서에 따라 정렬됨
    • [1,2,3,10] => [1,10,2,3]
  • 숫자 오름차순 정렬 예시

    arr.sort(function(a, b)  {
      if(a > b) return 1;
      if(a === b) return 0;
      if(a < b) return -1;
    });

    arr.sort(function(a, b)  {
      return a - b
    });

Math

• Math.floor(3.9) => 3
• Math.ceil(3.1) => 4
• Math.round(3.5) => 4
• Math.min(...arr)
• Math.max(...arr)

Combinations

function combination(arr, selectNum) {
  const result = [];
  if (selectNum === 1) return arr.map((v) => [v]);

  arr.forEach((v, idx, arr) => {
    const fixed = v;
    const restArr = arr.slice(idx + 1); // 
    const combinationArr = combination(restArr, selectNum - 1);
    const combineFix = combinationArr.map((v) => [fixed, ...v]);
    result.push(...combineFix);
  });
  return result;
}

Permutations

function permutation(arr, selectNum) {
  let result = [];
  if (selectNum === 1) return arr.map((v) => [v]);

  arr.forEach((v, idx, arr) => {
    const fixer = v;
    const restArr = arr.filter((_, index) => index !== idx); // 
    const permuationArr = permutation(restArr, selectNum - 1);
    const combineFixer = permuationArr.map((v) => [fixer, ...v]);
    result.push(...combineFixer);
  });
  return result;
}

개발자가 사용자의 위치, 카메라, 사진, 파일 등의 데이터에 접근하기 위해서는 해당 접근에 대한 사용자 권한 승인이 필수적이다. 기기에 상관없이 모든 권한들이 통일되어있다면 더욱 좋았겠지만 애플과 안드로이드는 각자만의 권한 처리 방식을 사용한다. 특히 iOS 13버전/android API30에서 권한과 관련된 여러 업데이트들이 존재하는데, 몇가지 중요한 점들만 살펴본다면 아래와 같다.

1. iOS

• 사용자가 한번이라도 권한 요청을 거절하는 경우, 앱에서 권한 재요청이 불가하다.
  • (사용자가 설정 페이지로 이동하도록 하여 권한 승인을 자연스럽게 유도하자!)
• iOS 13버전에서 위치 정보 권한에 대한 always allow 유저 플로우가 변경되었다.
  • 처음 사용자에게 위치 권한을 요청하는 창에는 '앱 사용 중에만 허용', '한번 허용', '승인하지 않음' 세 가지 선택지만 존재한다.
  • 사용자가 '앱 사용 중에만 허용' 옵션을 선택하고 앱을 지속적으로 사용한다면, 시스템이 "Allow ~ to also access your location even when you are not using the app?"이라고 물어본다. 해당 권한 요청 시스템 모달에는 'Keep Only While Using' 옵션과 'Change to Always Allow' 옵션이 포함된다.
  • 항상 허용 옵션을 통해 위치 권한을 승인했더라도, 주기적으로 (3일에 한번씩) 추적된 위치정보를 맵으로 보여주면서 위치 권한을 유지할 것인지 묻는 모달이 뜬다.
• iOS 13버전에서 일회성 권한 승인 옵션 추가
  • single session에서만 권한을 grant한다. 사용자가 앱을 relaunch할 때마다 시스템 모달이 다시 뜨게된다.

2. Android

• 사용자가 권한을 거절하여도, 서비스에서 런타임 권한 설정을 재요청할 수 있다.
  • 단, 사용자가 한번이라도 이미 권한 승인 요청을 거절한 이후에는 '다시 묻지 않기' 옵션이 추가된다. (이를 선택하지 않으면 계속해서 권한 재요청 가능)
• 백그라운드, 포어그라운드 위치 정보 접근 권한이 나뉘어있다.
  • 앱이 실행되고 있을 때에만 접근 가능한 포어그라운드 위치 정보(ACCESS_FINE_LOCATION 및 ACCESS_COARSE_LOCATION)와 백그라운드에 있을 때에도 접근 가능한 ACCESS_BACKGROUND_LOCAITON이 구별된다.
  • ACCESS_COARSE_LOCAITON은 네트워크만을 이용하여 단말기 위치를 구분하고, ACCESS_FINE_LOCATION은 GPS와 네트워크를 함께 사용하여 더욱 정확한 위치 정보를 제공한다.
  • 개발자가 FINE LOCATION에 대한 권한을 요청하더라도, 시스템은 사용자가 COARSE LOCATION에 대한 정보만을 제공할 수 있도록 하고 있다. 따라서 manifest에서 두가지 권한을 모두 요청하거나 덜 민감한 정보인 COARSE LOCAITON 권한만을 요청해야 한다. (아래의 그림 참고. ACCESS_FINE_LOCATION 권한만 요청하는 경우 Android 31-API12-부터는 무시된다)
• Android 30(API11)에서 일회성 권한 승인 옵션 추가
  • 단 iOS와는 다르게 권한 유지가 일정 시간동안 유지되어, 앱을 재실행해도 권한이 승인되어있는 경우가 발생하기도 한다.
  • 오랜 시간동안 앱을 사용하지 않은 경우, 시스템이 강제로 앱의 (민감한) 런타임 권한을 삭제한다.
  • iOS와 비슷하게 항상 허용 옵션이 기본 시스템 권한 모달에 옵션으로 포함되어있지 않다. 항상 허용 옵션이 필요한 권한의 경우에만 사용자가 설정페이지로 이동할 수 있는 링크가 시스템모달 본분에 포함된다.

react-native-permissions, react native에서 사용자 권한 관리하기

다행히 react native에서도 권한 요청 및 확인을 할 수 있도록 하는 react-native-permissions라는 라이브러리가 존재한다. docs가 매우 자세하게 나와있기는 하지만, 영어보다 한국어가 편한 나 포함 사람들을 위해 사용방법을 코드예시와 함께 정리해보았다.

1. 라이브러리 설치

yarn add react-native-permissions 명령어를 통해 설치한다. (만약 react native 버전이 63 미만이라면 linking 설정이 추가로 필요하다. 이건 내가 안쓰니까 패스)

2. 안드로이드 manifest 권한 설정

android/apps/src/main/AndroidManifest.xml에 사용할 권한을 아래와 같이 추가합니다. 앞서 말했듯이 ACCESS_FINE_LOCATION을 사용하기 위해서는 ACCESS_COARCE_LOCATION이 필수로 필요하다는 것을 잊지 않도록 한다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.myawesomeapp">

  <!-- 🚨 Keep only the permissions used in your app 🚨 -->

  <uses-permission android:name="android.permission.ACCEPT_HANDOVER" />
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
  <uses-permission android:name="android.permission.ACCESS_MEDIA_LOCATION" />
  <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />
  <uses-permission android:name="android.permission.ANSWER_PHONE_CALLS" />
  <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />
  <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
  <uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
  <uses-permission android:name="android.permission.BODY_SENSORS" />
  <uses-permission android:name="android.permission.CALL_PHONE" />
  <uses-permission android:name="android.permission.CAMERA" />
  <uses-permission android:name="android.permission.GET_ACCOUNTS" />
  <uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS" />
  <uses-permission android:name="android.permission.READ_CALENDAR" />
  <uses-permission android:name="android.permission.READ_CALL_LOG" />
  <uses-permission android:name="android.permission.READ_CONTACTS" />
  <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
  <uses-permission android:name="android.permission.READ_PHONE_NUMBERS" />
  <uses-permission android:name="android.permission.READ_PHONE_STATE" />
  <uses-permission android:name="android.permission.READ_SMS" />
  <uses-permission android:name="android.permission.RECEIVE_MMS" />
  <uses-permission android:name="android.permission.RECEIVE_SMS" />
  <uses-permission android:name="android.permission.RECEIVE_WAP_PUSH" />
  <uses-permission android:name="android.permission.RECORD_AUDIO" />
  <uses-permission android:name="android.permission.SEND_SMS" />
  <uses-permission android:name="android.permission.USE_SIP" />
  <uses-permission android:name="android.permission.WRITE_CALENDAR" />
  <uses-permission android:name="android.permission.WRITE_CALL_LOG" />
  <uses-permission android:name="android.permission.WRITE_CONTACTS" />
  <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
  <uses-permission android:name="com.android.voicemail.permission.ADD_VOICEMAIL" />

  <!-- … -->

</manifest>

3. iOS 권한 설정

처음에는 iOS의 권한 handler가 아무것도 설치되어있지 않다. ios/Podfile에 아래와 같이 추가하려는 권한에 대한 permission handler을 추가하고 ios 폴더에서 pod install명령어를 실행한다.

target 'YourAwesomeProject' do

  # …

  permissions_path = '../node_modules/react-native-permissions/ios'

  pod 'Permission-AppTrackingTransparency', :path => "#{permissions_path}/AppTrackingTransparency"
  pod 'Permission-BluetoothPeripheral', :path => "#{permissions_path}/BluetoothPeripheral"
  pod 'Permission-Calendars', :path => "#{permissions_path}/Calendars"
  pod 'Permission-Camera', :path => "#{permissions_path}/Camera"
  pod 'Permission-Contacts', :path => "#{permissions_path}/Contacts"
  pod 'Permission-FaceID', :path => "#{permissions_path}/FaceID"
  pod 'Permission-LocationAccuracy', :path => "#{permissions_path}/LocationAccuracy"
  pod 'Permission-LocationAlways', :path => "#{permissions_path}/LocationAlways"
  pod 'Permission-LocationWhenInUse', :path => "#{permissions_path}/LocationWhenInUse"
  pod 'Permission-MediaLibrary', :path => "#{permissions_path}/MediaLibrary"
  pod 'Permission-Microphone', :path => "#{permissions_path}/Microphone"
  pod 'Permission-Motion', :path => "#{permissions_path}/Motion"
  pod 'Permission-Notifications', :path => "#{permissions_path}/Notifications"
  pod 'Permission-PhotoLibrary', :path => "#{permissions_path}/PhotoLibrary"
  pod 'Permission-PhotoLibraryAddOnly', :path => "#{permissions_path}/PhotoLibraryAddOnly"
  pod 'Permission-Reminders', :path => "#{permissions_path}/Reminders"
  pod 'Permission-Siri', :path => "#{permissions_path}/Siri"
  pod 'Permission-SpeechRecognition', :path => "#{permissions_path}/SpeechRecognition"
  pod 'Permission-StoreKit', :path => "#{permissions_path}/StoreKit"

end

이후 ios/프로젝트이름/Info.plist에 권한에 대한 설명을 추가한다. 해당 string은 시스템 권한 설정 모달의 메시지로서 사용된다. 복붙하다가 카메라 권한 요청 모달에 갤러리 접근 메시지가 뜨는 불상사가 없도록 하자. XCode에서 직접 설정도 가능하다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>

  <!-- 🚨 Keep only the permissions used in your app 🚨 -->

  <key>NSAppleMusicUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSBluetoothAlwaysUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSBluetoothPeripheralUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSCalendarsUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSCameraUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSContactsUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSFaceIDUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSLocationAlwaysUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSLocationTemporaryUsageDescriptionDictionary</key>
  <dict>
    <key>YOUR-PURPOSE-KEY</key>
    <string>YOUR TEXT</string>
  </dict>
  <key>NSLocationWhenInUseUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSMicrophoneUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSMotionUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSPhotoLibraryUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSPhotoLibraryAddUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSRemindersUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSSpeechRecognitionUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSSiriUsageDescription</key>
  <string>YOUR TEXT</string>
  <key>NSUserTrackingUsageDescription</key>
  <string>YOUR TEXT</string>

  <!-- … -->

</dict>
</plist>

4. 실제 권한 check, request 코드 작성하기

react-native-permissions의 권한 체크/요청에 따른 결과는 아래 표를 따른다.

권한 체크/요청 플로우는 아래와 같다.

1. 권한 체크 요청
2. 해당 feature가 기기에서 사용 가능한지 확인 (불가하면 UNAVAILABLE)
3. 해당 feature가 기기에서 요청 가능한지 확인 (불가하면 GRANTED, LIMITED,BLOCKED)
4. DENIED 상태를 확인한 후, 권한 승인 요청
5. 권한 승인 시 GRANTED, iOS에서 거절 시 BLOCKED, Android에서 거절 시 DENIED, Android에서 '다시 보지 않기' 옵션 선택 시 BLOCKED

해당 플로우를 따라 아래와 같이 코드로 작성할 수 있다. check 결과가 DENIED일 때에 request를 실행했으며, 그 결과가 GRANTED가 아닐 경우 LIMITED, BLOCKED와 같이 취급하도록 하였다. (LIMITED의 경우 권한 종류에 따라 달라지는데, 해당 프로젝트에서는 앱 사용 중에만 위치 정보에 접근하기 때문에 따로 케이스를 분리하지는 않았다)

let requested: PermissionStatus;
const checked = await check(needPermission);
switch (checked) {
  case RESULTS.UNAVAILABLE:
    return handlePermissionError(
      strings.PERMISSION_UNAVAILABLE,
      essential
    );
  case RESULTS.GRANTED:
    return handlePermissionSuccess();
  case RESULTS.DENIED:
    requested = await request(needPermission);
    if (requested === RESULTS.GRANTED) {
      return handlePermissionSuccess();
    }
  case RESULTS.LIMITED:
  case RESULTS.BLOCKED:
  default:
    return handlePermissionError(strings.PERMISSION_BLOCKED, essential);
}

우아하게(?) 권한 관리하기

iOS와 Android 모두 권한 요청 시도가 있을 때에는, 위의 그림과 같이 사용자에게 해당 권한이 왜 필요하고 어떻게 사용되는지 전달하는 것을 권유하고있다. 그러나 모든 개별 권한에 맞춤형 페이지를 만드는 것도 어려웠고, 실제 그 기능을 사용할 때에 (보통 한 두개의) 권한에 대한 설명 메시지를 간략하게 보여주는 것 만으로도 충분히 사용자에게 권한 요청에 대한 이유를 설명할 수 있을 것이라고 생각했다. 아래는 dot slash dash라는 어플인데, 이런 방식으로 앞에 시스템 권한 요청 모달이 뜨면 뒤쪽에 해당 권한에 대한 설명이 보이도록 위의 함수를 업데이트했다.

react native 앱의 최상단에 모달을 삽입하고 해당 모달을 관리하는 mobx store을 사용하여, 앞에서 짰던 권한요청 함수가 실행될 때에 open 여부와 message를 변경하는 getPermission 함수를 작성하였다. 함수는 permission 이름을 받아, 기기가 iOS인지 Android인지를 확인하고 그에 맞는 권한을 체크/요청한다. 권한이 승인된 경우에는 인자로 받은 onSuccess 함수를 실행하고, 권한이 거절되면 (essential 여부에 따라 설정페이지로 이동하며) onFailed 함수를 실행하도록 구성하였다.

const androidPermissions: PermissionsPerOS = {
    location: PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION,
    camera: PERMISSIONS.ANDROID.CAMERA,
    photo: PERMISSIONS.ANDROID.READ_EXTERNAL_STORAGE,
};
const iosPermissions: PermissionsPerOS = {
    location: PERMISSIONS.IOS.LOCATION_WHEN_IN_USE,
    camera: PERMISSIONS.IOS.CAMERA,
    photo: PERMISSIONS.IOS.PHOTO_LIBRARY,
};
const permissionsPerOS =
    Platform.OS === strings.PLATFORM_IOS ? iosPermissions : androidPermissions;

const getPermission = async (
    permission: PossiblePermission,
    onSuccess?: () => void,
    onFailed?: () => void,
    essential = false
): Promise<boolean> => {
    const needPermission = permissionsPerOS[permission];
    permissionModalStore.setMessage(PERMISSION_REQUEST_MESSAGE[permission]);
    permissionModalStore.setOpen(true);

    const handlePermissionSuccess = () => {
        if (onSuccess) onSuccess();
        permissionModalStore.setOpen(false);
        permissionModalStore.setMessage('');
        return true;
    };

    const handlePermissionError = (message: string, openSetting = false) => {
        if (openSetting) goToSettings(message);
        if (onFailed) onFailed();
        permissionModalStore.setOpen(false);
        permissionModalStore.setMessage('');
        return false;
    };

    let requested: PermissionStatus;
    const checked = await check(needPermission);
    switch (checked) {
        case RESULTS.UNAVAILABLE:
            return handlePermissionError(
                strings.PERMISSION_UNAVAILABLE,
                essential
            );
        case RESULTS.GRANTED:
            return handlePermissionSuccess();
        case RESULTS.DENIED:
            requested = await request(needPermission);
            if (requested === RESULTS.GRANTED) {
                return handlePermissionSuccess();
            }
        case RESULTS.LIMITED:
        case RESULTS.BLOCKED:
        default:
            return handlePermissionError(strings.PERMISSION_BLOCKED, essential);
    }
};

여러 권한 한번에 요청하기

앱을 사용하다가 사진을 첨부하거나, 근처 매장을 찾는 등의 경우에는 한 두개의 권한에만 승인 요청이 발생한다. 그러나 앱을 처음 깔거나, 앱을 실행할 때마다(앱에 따라서는..좋지 않은 플로우기는 하다) 앱에서 필요한 설정들을 설명하고 한번에 승인을 요청하기도 한다. 이러한 권한 요청들을 리스트로 받아, 리스트 순서대로 권한을 요청하는 getPermissions 함수를 작성해보자. Promise들을 순차적으로 실행 보장하기 위해 재귀적인 방법을 쓰기도 하지만 아래 함수에서는 reduce와 async/await를 사용하였다.

const getPermissions = async (
    permissions: PossiblePermission[],
    onSuccess?: () => void,
    onFailed?: () => void,
    essential = false
): Promise<void> => {
    const permissionsResult = permissions.reduce(
        async (previousPermission, currentPermission) => {
            const previousPermissionResult = await previousPermission;
            const currentPermissionResult = await getPermission(
                currentPermission
            );
            previousPermissionResult.push(currentPermissionResult);
            return previousPermissionResult;
        },
        Promise.resolve<boolean[]>([])
    );

    permissionsResult.then((result) => {
        if (result.every(Boolean) && onSuccess) onSuccess();
        if (!result.every(Boolean) && onFailed) {
            if (essential) goToSettings(strings.PERMISSION_BLOCKED);
            onFailed();
        }
    });
};

아래는 실제로 getPermissions(['location', 'camera', 'photo']) 함수를 실행했을 때 확인할 수 있는 결과이다.

외부 호스팅 환경을 통한 JavaScript의 비동기 처리

그렇다면 어떻게 자바스크립트에서는 비동기 처리를 하고 있는 것일까. 다들 한번쯤은 setTimeout과 같은 기능을 써보았을텐데, 싱글 스레드만으로 비동기처리를 한다는 것이 도저히 상상이 가지 않는다. 내 머리가 잘못 된건가 아니면 자바스크립트가 사실은 싱글스레드가 아닌 것인가..?!

다행히 둘다 아니다. 자바스크립트의 비동기처리는 브라우저와 같은 외부 호스팅 환경에 의존한다. 외부 호스팅 환경의 Web API, Callback Queue, Event Loop가 비동기 처리를 위해 이용된다.

처음 자바스크립트 콜스택에 setTimeout 함수가 들어오면 자바스크립트 엔진은 이를 수행한다. 자바스크립트 엔진은 Web API를 통해 호스팅환경에게 타이머를 실행하도록 넘기는 것으로 함수 실행을 마치고, 완료된 setTimeout 함수는 콜스택에서 지워진다. 브라우저는 이후 타이머가 완료되면 (setTimeout과 함께 전달되었던) 콜백을 콜백큐에 넘긴다. 이벤트루프는 반복해서 콜스택이 비어있는지를 확인하는데, 비어있는 경우에 콜백큐의 첫번째 이벤트를 콜스택에 밀어넣는다.

setTimeout 코드 예시

console.log('Hi')
setTimeout(function A() {
  console.log('Hello Again')
},1000)
console.log('Bye')

setTimeout이 포함된 예시코드가 어떻게 동작하는지 단계별로 알아보자.

1. 코드가 실행되면, 가장 첫번째 줄인 console.log(‘Hi’)가 콜스택에 추가된다. 이를 JS엔진이 실행하여 콘솔에 hi가 출력되면 콜스택에서 console.log가 삭제된다.
2. 다음줄인 setTimeout(~)가 콜스택에 추가되고 실행된다. 자바스크립트 엔진은 WebAPI를 통해 브라우저에 타이머를 생성한다. 브라우저에서 카운트다운이 이어서 처리된다. 자바스크립트 엔진은 WebAPI 호출을 완료하였기 때문에 카운트다운이 되고있는지와는 상관없이 콜스택에서 setTimeout을 제거한다.
3. Bye를 출력하는 함수가 콜스택에 추가되고, Hi와 동일하게 콘솔에 출력된 후 콜스택에서 제거된다.
4. 시간이 지나 타이머가 완료되면 브라우저는 setTimeout의 콜백함수였던 A를 콜백큐에 밀어넣는다. 이벤트루프는 현재 Bye까지 출력되어 콜스택이 비어있기 때문에 A함수를 콜백큐에서 콜스택으로 밀어넣는다.
5. A함수가 실행되면 콜스택에 console.log("Hello Again") 함수 블록이 추가된다. 3번이 끝나면서 비어있던 콜스택에 A 함수 블럭이 쌓이고 그 위에 Hello Again을 출력하는 함수블럭이 또 있는 상태가 된다. 자바스크립트 엔진은 콘솔창에 Hello Again을 출력하는 것으로 console.log 함수를 완료하고, 이에 따라 console.log 함수 블럭과 하단의 A 함수 블럭이 차례대로 콜스택에서 제거된다.

WebAPI 타이머 사용 시 주의점

주의해야할 점은 실제 콜백함수가 언제 실행될지 아무도 장담할 수 없다는 것이다. 위에서는 1000ms 이후에 콜백을 실행해달라고 코드를 작성했지만, 브라우저는 단순히 1000ms 타이머가 완료되면 콜백큐에 해당 콜백을 넣어준다. 콜백 큐에는 이미 추가된 이벤트들이 존재할 수도 있고, 언제 콜스택이 완전히 비어 이벤트루프가 콜백큐의 함수를 실행할 수 있을지는 아무도 모른다. setTimeout에 대한 MDN 글에서 콜백 딜레이, 비활성 탭의 타임아웃, 추적 스크립트 스로틀링, 페이지 로드 등 타이머 실행 지연에 대한 자세한 설명을 확인할 수 있다.

마이크로 태스크 큐 : 모든 콜백이 시간 순으로 실행되는 것은 아니다

Promise는 자바스크립트에서 비동기 처리를 쉽게 처리하기위한 객체이다. MDN에서는 미래의 어떤 시점에 결과를 제공하겠다는 '약속'(프로미스)이라고 간단하게 설명하고 있다. Promise는 resolve되면 다음 then의 함수를 이행한다.

그렇다면, 아래 코드를 실행하면 어떻게 될까? setTimeout과 Promise가 하나의 코드에 존재한다. setTimeout은 0초의 시간간격을 두고 있고 Promise또한 바로 resolve했기 때문에, setTimeout과 Promise 모두 즉시 콜백 함수를 콜백 큐에 넣게 될것이다.

setTimeout(()=>{console.log("A")},0)
Promise.resolve()
  .then(()=>{console.log('B')})
  .then(()=>{console.log('C')})

정답은 B-C-A 순이다. Promise는 마이크로 태스크로 취급되기 때문이다.

콜백 큐에 들어가는 task들에는 우선순위가 존재한다. 비동기처리를 하는 데에 모든 task들이 FIFO 수준으로 처리되기에는 부족했을 것이다. 따라서 일반 (macro) task보다 먼저 실행되어야 하는 microTask를 구분하기 시작했다. 위에서 설명했던 콜백 큐가 macroTask들만 가진 큐와 microTask만으로 구성된 큐로 분리된 것이다. 이벤트 루프는 자바스크립트의 콜스택이 비었는지 확인하고, 만약 비었다면 (일반)태스크 큐 대신 마이크로 태스크 큐의 함수들을 먼저 실행한다.

Promise는 일반적으로 마이크로 태스크로 취급된다. 물론 특정 브라우저에서는 Promise가 일반 태스크로 취급되는 경우도 있다고 한다. 우선 크롬과 사파리가 아니면 상관 없는게 아닐까 ㅎㅎ.. 각 태스크큐의 종류와 해당하는 태스크들은 다음과 같다.

• microtask queue : Promise, queueMicrotask, MutationObserver
• (macro)task queue : setTimeout, setInterval
• RAF queue : requestAnimationFrame

과거 ThreeJS를 통해 3D 애니메이션을 만들 때에 setInterval 대신 requestAnimationFrame을 사용했었는데, 오랜만에 보니까 반갑기도 하고,,, 해당 내용은 ThreeJS 포스팅을 하면서 내용을 추가하거나 함께 정리해보아야겠다!

(참고 : https://www.typescriptlang.org/docs/handbook/2/basic-types.html)

동적 타입 언어, 자바스크립트

자바스크립트는 인터프리터 언어이면서 동적 타입 언어로, 런타임 환경에서 한줄한줄씩 코드를 읽고 실행하며 값이 할당되는 과정에서 값의 타입에 의해 변수의 타입이 결정된다. 런타임에서 코드가 실행될 때 해당하는 값이 어떤 동작과 능력을 가지고 있는지를 확인하고, 불가능하다면 TypeError를 반환한다.

예시에서는 message가 Hello World라는 문자열 값이지만, 중간에 숫자나 boolean 등의 값으로 재할당이 일어나면서 변수의 타입 또한 변경될 수 있다. 두번째/세번째 줄의 실행 결과는 해당 코드가 실행되는 당시의 message의 값에 따라 달라지게 되며 message가 호출 가능한지, toLowerCase라는 프로퍼티를 가지는지(string 타입인지), 만약 가진다면, toLowerCase를 호출 가능한지 등을 평가하고 실행이 완료될 것이다.

let message = "Hello World!";
message.toLowerCase();
message(); // TypeError: message is not a function

실행 시점에서 string과 number과 같은 원시 타입은 typeof 연산자를 통해 각 값들의 타입을 확인할 수 있지만, 함수의 파라미터와 같은 경우에는 그 타입을 장담할 수 없다. 아래 예시 함수에서는 x가 호출 가능한 프로퍼티인 flip을 가져야만 정상적으로 동작한다. 그러나 함수가 실제로 호출되는 그 순간의 x값과 타입에 따라 정상작동 여부가 평가되기 때문에 코드를 실행 전에 동작을 예측하기 어렵다.

function fn(x) {
  return x.flip();
}

공식문서의 내용을 그대로 옮겨보자면, _타입_이란 어떤 값이 fn으로 전달될 수 있고, 어떤 값은 실행에 실패할 것임을 설명하는 개념이다. JavaScript는 오직 동적 타입만을 제공하며, 코드를 실행해야만 어떤 일이 벌어지는지 비로소 확인할 수 있다.

A type is the concept of describing which values can be passed to fn and which will crash. JavaScript only truly provides dynamic typing - running the code to see what happens.

타입스크립트

위의 문제를 해결하기 위해, 코드를 실행하기 전에 이러한 버그를 미리 발견할 수 있는 정적 타입 검사기 TypeScript가 도입되었다. _정적 타입 시스템_은 사용된 값들의 형태와 동작을 정하고, 이 정보들을 기반으로 프로그램이 제대로 작동할지에 대하여 알려준다. 아래 코드를 (자바스크립트로 실행하기 전에) 타입스크립트로 실행하면 런타임에 발생했을 에러를 런타임 이전에 확인할 수 있다.

const message = "hello!";
message(); // This expression is not callable. Type 'String' has no call signatures.

또한, 타입스크립트는 자바스크립트 실행 시 런타임 에러는 발생하지 않지만 무언가 이상한 경우도 사용자에게 알려주어 휴먼에러를 방지(!)하기도 한다. JS에서는 객체에 존재하지 않는 프로퍼티에 접근하면 에러를 반환하는 것이 아니라 undefined를 반환하지만, 타입스크립트의 정적 타입 시스템은 (오류를 발생시키지 않는 “유효한” JS 코드라도) 오류로 간주할 수 있다.

// 미선언 속성
const user = {
  name: "Daniel",
  age: 26,
};
user.location; // Property 'location' does not exist on type '{ name: string; age: number; }'.

// 오타
const announcement = "Hello World!";
announcement.toLocaleLowercase(); // Error
announcement.toLocalLowerCase(); // Error
announcement.toLocaleLowerCase();

// 미호출 함수 : ()로 호출하는 것을 잊었을 때
function flipCoin() {
  return Math.random < 0.5; // Operator '<' cannot be applied to types '() => number' and 'number'.
}

// 논리 오류 : 실행되지 않는 블록
const value = Math.random() < 0.5 ? "a" : "b";
if (value !== "a") {
  // ...
} else if (value === "b") { 
  // This condition will always return 'false' since the types '"a"' and '"b"' have no overlap.
  // ...
}

실제 타입스크립트는 크게 ts파일을 js파일로 컴파일(번역의 의미를 강조하여 트랜스파일이라고도 한다)하는 기능과, 이제까지 우리가 이야기했던 타입 시스템 기능을 가진다. 타입스크립트와 자바스크립트의 관계성, 타입스크립트의 기본적인 특성을 조금 더 자세하게 살펴보도록 하자!

Item1. Relation between Typescript and Javascript

타입스크립트는 타입이 정의된 자바스크립트의 상위집합(superset)이다.

문법적으로 오류가 없는 자바스크립트 프로그램은 타입스크립트 프로그램이라고 할 수 있다. 단순히 main.js 파일을 main.ts 파일로 바꾸어도 정상적으로 동작한다. 그러나 모든 타입스크립트는 자바스크립트가 아닌데, 타입스크립트 파일(ts, tsx)을 컴파일하면 타입과 관련된 구문들이 모두 삭제되고 자바스크립트 파일(js, jsx)이 생성되는 것을 알고있다면 이해가 편할 것이다.

아래는 유효한 타입스크립트 프로그램이지만, 노드로 바로 실행하면 unexoected token ":이 있다는 오류를 출력한다.

function greet(who: string) {
  console.log('Hello', who)
}

해당 파일을 컴파일하면 타입과 관련된 부분은 모두 삭제되고 아래와 같은 자바스크립트 프로그램으로 변환된다. (아래 코드로 작성된 자바스크립트, 타입스크립트 파일 모두 유효하다.)

function greet(who) {
  console.log('Hello', who)
}

타입 체커를 통해 문제를 찾아낼 수 있다.

타입 추론을 통한 문법적 오류 탐색

문법적 유효성과 동작의 유효성은 다른 문제이지만, 많은 자바스크립트의 런타임 문제가 타입 체커만으로도 개선될 수 있다.(약 15%의 문제가 개선된다는 설문조사가 있다고 한다) 아래 코드는 JS로 실행하는 경우 런타임에서 "city.toUppercase is not a function"이라는 타입에러가 발생한다. toUpperCase 함수의 오타이지만 실제 해당 코드가 실행될 때에나 오류를 알 수 있다. 반면 타입스크립트의 타입체커는 city 변수의 값을 통해 타입을 추론하여 "toUppercase 속성이 string속성에 없습니다. toUpperCase를 사용하시겠습니까"라고 런타임 이전에 알려준다.

let city = 'new york city';
console.log(city.toUppercase()); // 오타 -> toUpperCase()

의도와는 다르게 작성된 잘못된 코드 탐색

실제 오류는 발생하지 않지만 의도와는 다르게 작성된 코드 또한 존재한다. 아래 예시는 name, capital 속성을 가지고 있는 state에서 오타로 capitol 속성을 부르는 경우이다. 실제 코드를 실행하면 에러 없이 undefined를 세번 프린트하게 되지만, 런타임 이전에 타입 체커는 "capitol 속성이 없으며 capital을 사용할 것이냐"라고 물어봐주어 개발자의 의도와 실제 코드 동작이 달라지는 경우를 방지해준다.

const states = [
  { name: 'Alabama', capital: 'Montgomery' },
  { name: 'Alaska', capital: 'Juneau' },
  { name: 'Arizona', capital: 'Phoenix' },
]
for (const state of states) {
  console.log(state.capitol)
  // ~~~~~~~ Property 'capitol' does not exist on type
  //         '{ name: string; capital: string; }'.
  //         Did you mean 'capital'?
}

의도를 분명하게 나타내기 위한 명시적 타입 선언 가능

아래 코드는 위의 코드와 똑같아보일 수 있으나, states의 정의에서 오타가 생긴 경우이다. 타입 체커는 capital이 옳은 속성 명인지 capitol이 옳은 속성 명인지 모른다. 따라서 State의 타입 선언이 없었다면 state의 타입을 name과 capitol이라는 속성을 가진 객체로 추론하여 console.log 부분에서 "capital 속성을 capitol로 바꾸시겠습니까?" 하고 물어봤을 것이다. 반면 State 타입 선언이 존재하는 경우, states를 정의하는 과정에서 의도에 맞는 코드인지 묻는 아래와 같은 제안을 확인하게 된다.

interface State {
  name: string
  capital: string
}
const states: State[] = [
  { name: 'Alabama', capitol: 'Montgomery' },
  // ~~~~~~~~~~~~~~~~~~~~~
  { name: 'Alaska', capitol: 'Juneau' },
  // ~~~~~~~~~~~~~~~~~
  { name: 'Arizona', capitol: 'Phoenix' },
  // State 정의가 있을 때에 의도를 명확하게 전달할 수 있다.
  // ~~~~~~~~~~~~~~~~~~ Object literal may only specify known
  //         properties, but 'capitol' does not exist in type
  //         'State'.  Did you mean to write 'capital'?
  // ...
]
for (const state of states) {
  console.log(state.capital)
  // State 정의가 없었다면??
  // ~~~~~~~ Property 'capital' does not exist on type
  //         '{ name: string; capitol: string; }'.
  //         Did you mean 'capitol'?
}

관계성 한눈에 보기

타입스크립트는 자바스크립트에서 발생하는 런타임오류를 줄이기 위해 도입되었으며,크게 컴파일 기능 + 타입 체크 기능으로 구성된다. 아래 그림에서 자바스크립트와의 관계성을 한번에 확인할 수 있다. 타입과 관련된 구문들이 존재하지 않는 타입스크립트만 자바스크립트라 할 수 있으며(컴파일 전후 동일), 모든 타입스크립트/자바스크립트가 타입 체크를 통과하지는 않는다. (사용자가 capital을 선언하고 capitol을 부르는 코드를 의도했을 수도 있지 않은가!)

타입 스크립트는 자바스크립트를 모델링한다

타입스크립트는 자바스크립트 기반으로 제작되었기 때문에, 아래와 같이 기본적인 타입 변환과 같은 특징들을 그대로 계승한다.

const x = 2 + '3' // OK, type is string
const y = '2' + 3 // OK, type is string

단, (위에서 봤던 정의되지 않은 속성에 접근을 막는 것과 같이) 의도치 않은 코드가 런타임오류로 이어질 수 있어 자바스크립트에서는 정상적으로 동작하는 코드에도 타입 에러를 표시하기도 한다. 책의 저자는 아래와 같이 null과 7을 더하거나 불필요한 매개변수를 추가해서 함수 호출을 하는 것을 당연하게 여긴다면 타입스크립트를 쓰지 말라고 한다.(돌려까는 기술인가..!ㅋㅋ)

const a = null + 7 // Evaluates to 7 in JS
// ~~~~ Operator '+' cannot be applied to types ...
const b = [] + 12 // Evaluates to '12' in JS
// ~~~~~~~ Operator '+' cannot be applied to types ...
alert('Hello', 'TypeScript') // alerts "Hello"
// ~~~~~~~~~~~~ Expected 0-1 arguments, but got 2

모든 런타임 오류를 잡아낼 수 있지는 않다

타입스크립트는 타입시스템을 기반으로 설계되었기 때문에, 아래와 같이 타입 체크를 통과하더라도 여전히 런타임에서 오류가 발생할 수 있다. 타입 체커를 통과했더라도 에러가 발생하는 경우는 any를 사용할 수록 빈번하게 발생하는데, 이는 item5에서 더욱 자세하게 이야기하고 있다.

const names = ['Alice', 'Bob']
console.log(names[2].toUpperCase()) // TypeError: Cannot read property 'toUpperCase' of undefined

Item2. typescript settings

타입스크립트 설치 후 tsc --init 실행 시, 설정 파일은 자동으로 생성된다. 대부분의 설정들은 어디서 소스파일을 찾을지 어떤 종류의 출력을 생성할지 등을 제어하는 데에 그치지만, 일부 설정은 타입스크립트 언어 자체의 핵심 요소들을 제어하기도 한다.

noImplicitAny

noImplicityAny는 변수의 타입 추론이 any로 되는 것을 방지한다. 아래 코드는 해당 설정이 false로 되어있을 때에는 문제가 없다. 그러나 noImplicitAny 설정이 true로 되어있을 때에는 "Parameter '~' implicitly has an 'any' type"라는 에러가 발생한다.

function add(a, b) {
  return a + b
}
add(10, null)

타입이 추론된 값이 any가 되었을 때에만 오류이므로 아래처럼 타입을 명시한다면 해당 오류를 해결할 수 있다. 단, any를 매개변수에 사용하게 되면 타입체커는 제 기능을 제대로 할 수 없다. (item6에서 다시 말하겠지만 자동완성이나 변수명 바꾸기 등에서도 제외된다 ㅠㅠ)

function add(a: any, b: any) {
  return a + b
}
function sub(a: number, b: number) {
  return a - b
}

타입스크립트는 타입 정보를 가질 때에 가장 효과적이기 때문에 되도록이면 noImplicityAny를 true로 설정하고 변수에 any가 아닌 타입을 명시하는 것을 습관화해아한다. 해당 설정은 왜 있는지 의문을 가질 수도 있는데, 윗윗 예시에서와 같이 타입 정보가 아예 없으면 js 코드와 동일하다는 것을 깨달을 수 있다. 이미 JS로 작성된 프로젝트에 TS를 마이그레이션할 때를 제외하고는 noImplicitAny false를 사용하지 않도록 하자!

strictNullChecks

const x: number = null
// tsConfig: {"noImplicitAny":true,"strictNullChecks":true}일 때에만
//    ~ Type 'null' is not assignable to type 'number'

strictNullChecks는 null과 undefined를 모든 타입에서 허용할지를 설정한다. 단 해당 설정은 noImplicitAny가 true로 설정되었을 때에만 작동한다.(하긴 아니라면 이곳저곳에서 any로 타입이 추론되어 null 체크가 무의미할 듯 하다) 만약 의도적으로 null이나 undefined를 허용하려면 const x: number | null = null;로서 설정할 수 있다. 해당 변수가 null일 가능성이 있을 때에 속성에 접근하기 위해서는 if로 null이 아님을 확인하거나 !를 통해 null이 아니라고 assert할 수 있다.

const el = document.getElementById('status')
el.textContent = 'Ready'
// ~~ Object is possibly 'null'

if (el) {
  el.textContent = 'Ready' // OK, null has been excluded
}
el!.textContent = 'Ready' // OK, we've asserted that el is non-null

Item3. Understand That Code Generation Is Independent of Types

타입스크립트 컴파일러는 크게 두가지 역할을 한다.

1. 최신 타입스크립트/자바스크립트를 부라우저에서 동작할 수 있도록 구버전의 자바스크립트로 트랜스파일 (default ES3, target 변경 가능)
2. 코드의 타입오류 체크

이 두가지는 서로 독립적이다. 때문에 타입 오류가 있어도 자바스크립트로의 컴파일에는 문제가 없고, 타입 체크에 통과한다 하더라도 자바스크립트 실행 시 런타임 에러가 발생할 수 있다.

타입 오류가 있는 코드도 컴파일 가능

let x = 'hello'
x = 1234

위의 코드에서 x는 'hello'를 기반으로 스트링 타입이라고 추론된다. 타입체커는 '1234' 형식은 'string' 형식에 할당할 수 없다는 타입 에러를 띄우지만, tsc를 통해 컴파일하면 정상적으로 js로 변환된다. 타입스크립트 오류는 문제가 될 만한 부분들을 알려 주지만, 빌드를 멈추지는 않는다.

책의 저자는 웹 애플리케이션을 만들면서 일정 부분에 타입 에러가 발생해도 여전히 타입스크립트는 컴파일된 산출물을 생성하기 때문에, 문제가 된 오류를 수정하지 않아도 애플리케이션의 다른 부분을 테스트할 수 있다는 장점을 언급했다. 이런 타입오류가 발생했을 때에 컴파일을 막기 위해서 noEmitOnError 설정을 변경할 수 있다!

런타임에는 타입 체크가 불가능하다

"~~"는 형식만 참조하지만, 여기서는 값으로 사용되고 있습니다."라는 에러를 몇번 접해본 적이 있어, 이마를 탁 치게 되었다.

interface Square {
  width: number
}
interface Rectangle extends Square {
  height: number
}
type Shape = Square | Rectangle

function calculateArea(shape: Shape) {
  if (shape instanceof Rectangle) {
    // ~~~~~~~~~ 'Rectangle' only refers to a type,
    //           but is being used as a value here
    return shape.width * shape.height
    //         ~~~~~~ Property 'height' does not exist
    //                on type 'Shape'
  } else {
    return shape.width * shape.width
  }
}

instanceof 체크는 런타임에 일어나지만, Rectangle과 같은 인터페이스, 타입, 타입 구문은 자바스크립트로 컴파일되는 과정에서 제거된다. 따라서 런타임에서까지 타입 정보를 유지하기 위한 방법이 필요한데, 보통 아래의 세가지 방법을 주로 사용한다.

1. 속성 체크 속성 체크는 런타임에 접근 가능한 값에만 관련되지만, 타입체커 또한 shape의 타입을 Rectangle로 보정해주기 때문에 에러가 사라진다고 한다.

   interface Square {
   width: number
   }
   interface Rectangle extends Square {
   height: number
   }
   type Shape = Square | Rectangle
   function calculateArea(shape: Shape) {
   if ('height' in shape) {
    shape // Type is Rectangle
    return shape.width * shape.height
   } else {
    shape // Type is Square
    return shape.width * shape.width
   }
   }

2. 태그 속성 사용 1번 방법과 비슷한 방법으로, 타입 정보를 런타임에도 접근 가능한 '태그'로서 명시적으로 저장하는 방법이 있다. 런타임에도 타입 정보를 유지할 수 있기 때문에 자주 사용되는 기법이라고 한다.

   interface Square {
   kind: 'square'
   width: number
   }
   interface Rectangle {
   kind: 'rectangle'
   height: number
   width: number
   }
   type Shape = Square | Rectangle
   

function calculateArea(shape: Shape) { if (shape.kind === 'rectangle') { shape // Type is Rectangle return shape.width * shape.height } else { shape // Type is Square return shape.width * shape.width } }

3. 타입과 값 모두 사용할 수 있는 클래스형 사용하기
타입은 컴파일에 사라지기 때문에 런타임에 접근 가능한 값을 사용하는 방식이다. 아래와 같이 타입을 클래스로 만들면 된다! ```type Shape = Square | Rectangle```에서는 Rectangle이 타입으로 참조되지만, ```shape instanceof Rectangle```에서는 값으로 참조된다. 이 내용은 item8에서 조금 더 자세하게 다룬다.
```js
class Square {
  constructor(public width: number) {}
}
class Rectangle extends Square {
  constructor(public width: number, public height: number) {
    super(width)
  }
}
type Shape = Square | Rectangle

function calculateArea(shape: Shape) {
  if (shape instanceof Rectangle) {
    shape // Type is Rectangle
    return shape.width * shape.height
  } else {
    shape // Type is Square
    return shape.width * shape.width // OK
  }
}

타입 연산은 런타임에 영향을 주지 않는다

아래 예시의 컴파일 전후 코드를 살펴보면 바로 이해할 수 있다. string 또는 number 타입인 값을 항상 number로 정제하려 할 때, 1번 코드는 타입 체커에서는 number로 가정되고 오류 없이 통과하지만, 이것이 변환된 2번의 자바스크립트 코드에서는 정제 과정이 없다. 실제 동작을 위해서는 3번 코드처럼 자바스크립트 런타임 타입을 체크하고 변환을 수행해야 한다.

// 1. 컴파일 전
function asNumber(val: number | string): number {
  return val as number;
}

// 2. 컴파일 후
function asNumber(val) {
  return val;
}

// 3. TOBE
function asNumber(val: number | string): number {
  return typeof val === 'string' ? Number(val) : val;
}

런타임 타입과 선언된 타입은 다를 수 있다

아래 코드에서 value는 boolean으로 선언되어 default 부분은 실행되지 않아야 한다. 따라서 타입스크립트는 접근할 수 없는 코드라는 에러를 찾아내야 하는데, 실제로는 (strict모드로 설정하더라도) 그렇지 않다. 자바스크립트 코드로 컴파일되면 타입선언값이 지워지고, API의 반환값으로 setLightSwitch 코드를 실행했을 때에 value가 문자열값이 되는 등의 경우가 있을 수 있기 때문이다.

function setLightSwitch(value: boolean) {
  switch (value) {
    case true:
      turnLightOn()
      break
    case false:
      turnLightOff()
      break
    default:
      console.log(`I'm afraid I can't do that.`)
  }
}

타입스크립트 타입으로는 함수를 오버로드할 수 없다.

C++과 같은 언어는 동일한 이름에 매개변수만 다른 여러 버전의 함수를 허용한다. 타입스크립트에서는 타입과 런타임 동작이 무관하기 때문에, 아래와 같은 함수 오버로딩은 불가능하다. (실제 컴파일된 코드를 예상하면 이해가 쉽겠지만, 똑같은 코드가 단순히 두번 반복된 코드일 뿐이다)

function add(a: number, b: number) {
      // ~~~ Duplicate function implementation
  return a + b
}
function add(a: string, b: string) {
      // ~~~ Duplicate function implementation
  return a + b
}

아래와 같이 타입 수준에서만 오버로딩을 지원하고 타입체커를 정상적으로 통과하지만, 해당 부분은 컴파일되면 없어진다는 것을 유념해야 한다. 실제 함수의 구현은 하나뿐이다.

function add(a: number, b: number): number
function add(a: string, b: string): string

// 실제 구현체
function add(a, b) {
  return a + b
}

const three = add(1, 2) // Type is number
const twelve = add('1', '2') // Type is string

타입스크립트 타입은 런타임 성능에 영향을 주지 않는다

계속 반복해왔듯이, 타입과 타입 연산자는 자바스크립트로 컴파일될 때 모두 제거되어 런타임에는 (당연히 성능을 포함하여) 아무런 영향을 주지 못한다. 타입스크립트 컴파일에서도 성능을 위한 몇가지 커스터마이징을 제공하기도 한다. 빌드도구에서 transplie only 설정을 통해 타입체크를 건너뛰고 컴파일만 실행할 수도 있으며, tsc --target 옵션을 통해 컴파일 타겟 버전을 설정하여 호환성과 성능 정도를 조절할 수 있다.

Item4. Get Comfortable with Structural Typing

One of TypeScript’s core principles is that type checking focuses on the shape that values have. This is sometimes called “duck typing” or “structural typing”.

타입스크립트 공식문서에는 “타입스크립트의 코어 원리 중 하나는 타입 체킹을 형태(Shape)에 중점을 두며, 이것을 "덕 타이핑" 또는 "구조적 서브타이핑" 이라고 부른다” 라고 말하고 있다. JS는 덕 타이핑 기반으로, 함수의 매개변수 값이 제대로 주어진다면 그 값이 어떻게 만들어졌는지/어떤 타입인지 신경쓰지 않는다. TS 또한 이런 기본 코어 동작들을 모델링하여 비슷하게 작동한다. "객체 적합성"이 객체의 실제 타입이 아니라 특정 메소드와 속성이 존재하는지에 의해 결정된다. ~ 타입이 정해지면 타입의 속성들이 정해지는 것이 아니라, 타입의 속성들이 정해지면 타입이 정해진다고 생각하면 조금 더 이해가 쉬울까? 모 블로그에서는 타입 검사 측면과 다형성 측면의 관점을 분리해서 생각하라고 첨언한다 ~

interface Vector2D {
  x: number
  y: number
}
function calculateLength(v: Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y)
}
interface NamedVector {
  name: string
  x: number
  y: number
}
const v: NamedVector = { x: 3, y: 4, name: 'Zee' }
calculateLength(v) // OK, result is 5

위의 코드를 보면 바로 이해가 갈 것이다. v는 NamedVector지만 Vector2D가 가지는 number타입의 x와 y속성을 가지고 있기 때문에, calculateLength 함수 호출이 가능하다. 여기서 중요한 점은, Vector2D와 NamedVector 사이의 관계를 따로 선언하거나, 네임드벡터를 위한 별도의 calculateLength 함수를 구현하지 않아도 정상적으로 타입체크가 일어난다는 점이다. 객체 적합성(또는 호환성)을 위해서는 타입 선언에 나열된 속성들을 전부 가지고 있기만 하면 되고, 더 많이 가지고 있어도 상관없다!

구조적 타이핑이 문제를 일으키기도 한다

함수를 작성할 때 호출에 사용하는 매개변수의 속성들이 매개변수의 타입에 선언된 속성만을 가질 것이라고 생각하기 쉬운데, 이로 인해서 오류 및 의도와는 다르게 작동하는 경우가 발생하기도 한다.

함수의 구조적 타이핑

interface Vector2D {
  x: number
  y: number
}
interface Vector3D {
  x: number
  y: number
  z: number
}
function calculateLength(v: Vector2D) {
  return Math.sqrt(v.x * v.x + v.y * v.y)
}
function normalize(v: Vector3D) {
  const length = calculateLength(v)
  return {
    x: v.x / length,
    y: v.y / length,
    z: v.z / length,
  }
}
normalize({x:3, y:4, z:5}) // {x:0.6, y:0.8, z:1}, 길이가 1이 넘는다

위와 같이 Vector3D의 크기를 1로 맞추기 위해 normalize라는 함수를 만들었다고 하자. calculateLength는 x와 y값만 고려하기 때문에 이때 x가 3, y가 4, z가 5인 3D벡터를 정규화하면 1보다 길이가 더 긴 벡터를 아웃풋으로 갖게 된다. 타입스크립트가 구조적 타이핑을 지원하지 않았다면 calculateLength 호출 시 에러를 띄웠겠지만, 구조적 타이핑을 지원하기 때문에 Vector3D가 vector2D와 호환되면서 에러 없이 z가 길이 계산에서 무시된 것이다. 사실 이 부분을 보면서 그냥 단순한 휴먼에러가 아닌가? 싶었지만 타입스크립트 설정 변경을 통해 이러한 문제를 해결할 수 있다고 한다..!!

의도와는 다르게 동작하는 예시가 하나 더 있다. 위의 케이스에서 caculateLength의 문제점을 깨달은 사람이 Vector3D인 v의 속성들을 모두 돌면서 length를 계산하도록 코드를 고쳤다고 하자. 아래 for 루프에서 axis들은 분명 x, y, z 중에 하나이고 coord는 숫자가 되어 오류 없이 코드가 작동해야 하는데, 타입스크립트는 "string은 Vector3D의 인덱스를 사용할 수 없고 coord는 암시적으로 any타입이 된다"는 오류를 낸다.

interface Vector3D {
  x: number
  y: number
  z: number
}
function calculateLengthL1(v: Vector3D) {
  let length = 0
  for (const axis of Object.keys(v)) {
    const coord = v[axis]
    // ~~~~~~~ Element implicitly has an 'any' type because ...
    //         'string' can't be used to index type 'Vector3D'
    length += Math.abs(coord)
  }
  return length
}

이는 함수를 작성할 때 구조적 타이핑을 잊고 Vector3D의 속성을 제한해서 생각했기 때문에 나타나는 실수이다. const vec3D = { x: 3, y: 4, z: 1, address: '123 Broadway' }를 예시로 들면 이해가 쉬운데, 이때 calculateLengthL1(vec3D)를 실행하면 NaN을 리턴한다. 구조적 타이핑으로 인해 v는 어떤 속성이든 가질 수 있고, axis는 "x"|"y"|"z" 타입이 아니라 string 타입을, coord는 any타입을 갖게된다. 이런 경우는 루프를 사용하기보다는 앞에서와 같이 속성들을 각각 더하는 구현이 옳다.

function calculateLengthL1(v: Vector3D) {
  return Math.abs(v.x) + Math.abs(v.y) + Math.abs(v.z)
}

클래스의 구조적 타이핑

구조적 타이핑은 함수 뿐만 아니라 클래스 관련 할당시에도 일어난다.

class C {
  foo: string
  constructor(foo: string) {
    this.foo = foo
  }
}

const c = new C('instance of C')
const d: C = { foo: 'object literal' } // OK!

위 코드에서 c는 C가 값으로 사용되었고 d에서는 C가 타입으로 사용되었는데, d는 정상적으로 C타입에 할당된다. C가 가지고있는 모든 속성을 포함하고 있기 때문에 구조적 타이핑에 따라 d는 C타입과 호환될 수 있는 것이다.

아래 코드는 인프런의 타입스크립트 스터디에서 해당 내용을 정리한 것이다.

class C {
  foo: string
  constructor(foo: string) {
    this.foo = foo
  }
  method() {}
}
class E {
  method() {}
}
class D extends E {
  foo: string
  constructor(foo: string) {
    super()
    this.foo = foo
  }
}

const c = new C('instance of C')
const d: C = { foo: 'object literal' } // error. 'method' 속성이 '{ foo: string; }' 형식에 없지만 'C' 형식에서 필수입니다.
const e: C = { foo: '', method() {} } // foo, method 속성이 모두 있으면 okay.

const f: C = new D('') // prototype chain 상에 method가 존재하면 okay.
const g = Object.create({ method() {} }, { foo: { value: '' } }) // g: any
const h: C = g // C type 강제(assert)하여 okay.
const i: { foo: string; method: () => void } = Object.create({ method() {} }, { foo: { value: '' } })
const j: C = i // { foo, method } 타입을 강제하여 okay.

구조적 타이핑은 유닛테스트에도 도움이 된다

테스트를 작성할 때에도 구조적 타이핑을 통해 쉽게 처리할 수 있다. 데이터베이스에 쿼리하고 결과를 처리하는 getAuthors가 다음과 같다고 하자. DB가 어떻게 이루어져있는지 명확하게 선언하지 않고 runQuery 메소드를 정의한것만으로도, DB 데이터의 타입을 선언하고 mocking할 수 있다.

참고로, 모킹이란 데이터베이스 또는 외부 API에 의존하는 코드를 테스트해야 할 때에, 실제 데이터베이스와 연동하거나 실제 외부 API를 호출하는 대신 외부에 의존하는 부분을 임의의 가짜로 대체하는 테스팅 기법이다.

타입스크립트는 만약 우리가 명시적으로 인터페이스들을 자세히 서술했다면 DB가 인터페이스를 충족하는지를 확인했을 것이다. 그러나 우리의 테스트코드는 실제 DB에 대한 정보나 해당 라이브러리가 불필요하다. 구조적 타이핑의 추상화를 통해서, 우리는 DB의 구현과 테스트로직을 분리할 수 있다. (물론 라이브러리간의 의존성 또한 분리할 수 있다! item 52를 확인하는 그날까지!)

interface Author {
  first: string
  last: string
}
interface DB {
  runQuery: (sql: string) => any[]
}
function getAuthors(database: DB): Author[] {
  const authorRows = database.runQuery(`SELECT FIRST, LAST FROM AUTHORS`)
  return authorRows.map(row => ({ first: row[0], last: row[1] }))
}
test('getAuthors', () => {
  const authors = getAuthors({
    runQuery(sql: string) {
      return [
        ['Toni', 'Morrison'],
        ['Maya', 'Angelou'],
      ]
    },
  })
  expect(authors).toEqual([
    { first: 'Toni', last: 'Morrison' },
    { first: 'Maya', last: 'Angelou' },
  ])
})

Item5. Limit Use of the any Type

타입스크립트의 타입 시스템은 점진적이고 선택적이다. 코드에 타입을 조금씩 추가할 수도 있고, 언제든지 타입 체커를 해제할 수도 있다. 이 기능들은 any 타입을 통해 가능하다. 그러나 any는 타입스크립트의 장점들을 사용하지 못하게 하고, 위험성 또한 가지고 있다. 타입스크립트에 익숙하지 않다면 any 타입이나 as any와 같은 단언문을 사용하고 싶고 남용하게 되겠지만, 이들의 위험성과 불편함을 살펴보도록 하자.

타입 불안정성

let age: number
age = '12'
// ~~~ Type '"12"' is not assignable to type 'number'
age = '12' as any // OK

타입 체커는 선언에 따라 age를 number로 판단한다. age를 any로 단언한다면 지금 당장 타입 체커는 통과할 수 있다. 그러나 이후 런타임age += 1를 실행했을 때에 age의 값이 의도와는 다르게 “121”라는 문자열을 갖게 될것이다.

타입 시그니처(타입 선언) 무시

함수를 작성할 때는 (noImplicitAny 설정에 따라) function contract-이하 시그니처-를 명시해야 한다. 호출하는 쪽은 약속된 타입의 입력을 제공하고, 함수는 약속된 타입의 출력을 반환한다. 그러나 any 타입을 사용하면 이런 약속을 어길 수 있다.

function calculateAge(birthDate: Date): number {
  return 0
}
let birthDate: any = '1990-01-19'
calculateAge(birthDate) // OK

앞의 예시에서 birthDate 매개변수는 string이 아닌 Date타입이어야 한다고 약속했다. 그러나 any 타입을 사용하면 calculateAge의 시그니처를 무시할 수 있다. 자바스크립트에서는 암시적으로 타입이 변환되기 때문에 이런 경우 특히 문제가 될 수 있다.

언어 서비스 미제공

아래와 같이 자동완성 기능이나 이름 변경 기능 또한 사용할 수 없다!

코드 리팩토링 시, 버그를 유발한다.

interface ComponentProps {
  onSelectItem: (item: any) => void
}
function renderSelector(props: ComponentProps) {
  /* ... */
}

let selectedId: number = 0
function handleSelectItem(item: any) {
  selectedId = item.id
}

renderSelector({ onSelectItem: handleSelectItem })

any 타입을 사용하면 버그 발견 또한 어려워진다. 어떤 아이템을 선택할 수 있는 웹 애플리케이션을 만든다고 위의 코드와 같이 가정해보자. 애플리케이션에는 onSelectItem 콜백이 있는 컴포넌트가 있을 것이다. 만약 onSelectItem함수가 item 객체를 모두 받지 않고 필요한 부분만 전달하도록 컴포넌트를 개선한다고 하자. 여기서는 id만 필요하니, 아래와 같이 제일 우선 상단의 ComponentProps을 변경하게 될 것이다.

interface ComponentProps {
  onSelectItem: (id: number) => void
}
function renderSelector(props: ComponentProps) {
  /* ... */
}

let selectedId: number = 0
function handleSelectItem(item: any) {
  selectedId = item.id
}

renderSelector({ onSelectItem: handleSelectItem })

문제는 여기서 발생한다. ComponentProps만 변경했을 뿐인데 타입 체크를 모두 통과한다. handleSelectItem이 any 매개변수를 받기 때문에, item 매개변수에 item 객체가 아닌 숫자 id를 직접 전달받아도 타입 체크를 통과한다. 물론 편집기에서는 문제가 없다고 나오지만 실제 런타임에서는 item.id 구문을 실행할 때에 number의 id속성을 찾게 되면서 오류가 발생한다.

이 외에도, any 타입은 타입 설계를 불명확하도록 하거나 런타임에 타입 오류를 발견하게 되는 문제를 유발한다.

간단한 페이지 하나 그냥 쓰자 했다가 '../../../.."를 보는 순간 바로 해결하기로 마음먹었다 ㅋㅋㅋㅋ 다음에 기억 안나면 다시 보기!

craco w/ craco-alias

0. 패키지 설치

   $ yarn add @craco/craco
   $ yarn add craco-alias -D

1. path 정보 입력

   // tsconfig.paths.json
   {
    "compilerOptions": {
        "baseUrl": "./",
        "paths": {
            "@src/*": ["src/*"],
            "@assets/*": ["src/assets/*"],
            "@components/*": ["src/components/*"],
            "@context/*": ["src/context/*"],
            "@pages/*": ["src/pages/*"]
        }
    }
   }

2. craco 설정

   // craco.config.js
   const CracoAlias = require('craco-alias');
   

module.exports = { plugins: [ { plugin: CracoAlias, options: { source: 'tsconfig', baseUrl: './', tsConfigPath: 'tsconfig.paths.json', }, }, ], };

3. tsconfig 설정

// tsconfig.json { "compilerOptions" : { ... }, "include": [ "src", "craco.config.js" ], "extends": "./tsconfig.paths.json" }

4. eslint 설정

// .eslintrc.json { "rules" : { ... }, "settings": { "typescript": {}, "import/resolver": { "node": { "extensions": [".js", ".jsx", ".ts", ".tsx"] } } } }

### craco w/o craco-alias
craco-alias 없이도 alias 설정이 가능하다. 1, 3, 4번 단계는 위와 동일하고 craco 설정만 추가한다.

0. 패키지 설치

$ yarn add @craco/craco

2. craco 설정

// craco.config.json const path = require('path');

module.exports = { webpack: { alias: { '@': path.resolve(dirname, 'src/'), '@assets': path.resolve(dirname, 'src/assets'), '@components': path.resolve(dirname, 'src/components'), '@pages': path.resolve(dirname, 'src/pages'), '@context': path.resolve(__dirname, 'src/context'), }, }, };

모노리스 아키텍쳐에서부터 마이크로 프론트엔드까지

모노리스 아키텍쳐

기존의 개발 방식으로, 각각의 기능들을 개발한 후 하나의 앱으로 패키징하여 배포하는 것을 말한다. 일반적으로 하나의 레포지토리 내에 하나의 큰 앱만 존재하여, 코드 공유가 쉽고 형식 통일과 배포 관리에 용이하다는 장점이 있다.

여러 팀으로 구성되는 대규모 프로젝트에서 문제가 될 수 있다. 예를 들어 계정/상품 확인/장바고니/배송/결제 기능이 포함된 인터넷 쇼핑몰에서, 결제 기능을 개발하기 위해 로그인 개발이 먼저 완료되어야 하는 등 개발 병목현상이 발생한다. 결제 시스템에서 문제가 생기더라도 상품 확인 및 장바구니를 포함한 모든 기능을 사용하지 못하게 되는 에러 확산이 발생하기도 한다.

전체 서비스가 하나의 프레임워크와 언어에 제한되는 경우도 생긴다. (사실 이 예시는 어떻게든 연결하는 레이어를 담으면 되는게 아닌가 싶기는 하지만.. https://wooaoe.tistory.com/57 요기 블로그 왈) 블록체인 모듈은 nodeJS를 일반적으로 사용하는데, 서버를 스프링을 통해 서비스를 시작하는 경우 이를 통해 연동해야 한다. 또한 수정하지 않은 다른 기능들을 포함한 전체 서비스 빌드가 필요하고, 작은 변경에도 높은 테스트 비용이 발생한다.

SOA : service oriented architecture, MSA : micro service architecture

이런 문제를 해결하기 위해서 프론트와 백단이 나뉘기도 하고, 공통모듈을 기반으로 개별 모듈들의 의존성을 줄인 SOA와 아예 모듈들을 분리하여 API로 통신하는 마이크로 서비스 아키텍쳐가 제안되기도 했다. (참고 : https://www.redhat.com/ko/topics/cloud-native-apps/what-is-service-oriented-architecture)

마이크로 서비스에서, 앞서 말한 인터넷 쇼핑몰의 경우 로그인/결제/리뷰/장바구니 등등의 각각의 서비스는 개별적으로 모듈화되어 독립적으로 테스트 및 배포가 이루어진다. 서비스 구현 기술과는 상관없이 API를 사용하여 통신하기 때문에 서비스별로 기술스택이 달라도 상관이 없다. 특히 대규모이면서 레거시 코드가 대부분인 프로젝트에서, 이와 구분하여 새로운 기술스택을 사용한 기능 개발에 제한이 없다는 장점이 있다.

백엔드에서 MSA가 마구마구 사용되던 것에 반해, 프론트엔드는 모노리스 상태를 최근까지 유지해오던 경향이 있었다. 최근(ㅇ..ㅓ..최근의 약간 이전..?) 프론트 엔드 추세는 사용자 인터랙션이 일어나면 최소한의 리렌더링을 통해 기능하는 Single Page Application를 구성하는 것이었기 때문이다. 백엔드에서 겪었던 문제와 비슷하게, 시간이 지남에 따라 규모가 커지고 여러 팀이 함께 하나의 서비스를 개발하게 되면서 점차 유지관리가 어려워짐에 따라 대규모프로젝트에서 마이크로 프론트엔드가 도입되기 시작했다. (물론 내가 참여하는 대부분의 프로젝트는 대규모가 아니다 ㅎㅁㅎ,,)

마이크로 프론트엔드

마이크로 프론트엔드란 결국 프론트엔드에서 개별 팀이 담당하는 비즈니스 영역을 모듈화하여 완전히 구분하는 것을 말한다. 한 앱의 각각 일부 앱만 담당하는 것이 아니라, 각 팀 내에서 데이터베이스에서부터 사용자 인터페이스에 이르기까지 end-to-end를 완료하는 것이다.

마이크로 프론트엔드를 구성하는 방법에는 서버 템플릿 통합, 빌드타임 통합, iframe를 통한 런타임 통합, JS를 통한 런타임 통합, Web Components를 통한 런타임 통합 방식이 있다. 이 중에서 토스에서도 사용하고 있고, lerna를 통해 쉽게 사용할 수 있어 보이는(?) 빌드타임 통합 방식에 대해 조금 더 이야기해보려 한다.

토스의 마이크로 프론트엔드 도입기 : 의존성 지옥과 긴 빌드타임

토스는 8~9명으로 구성된 사일로가 하나의 기능 개발을 담당한다고 한다. 각 사일로마다 개별적인 서비스를 구현하기 때문에 21년 세미나 당시 25개 이상의 리액트 서비스가 존재했다. 새로운 프로젝트는 자연스럽게 기존에 존재하던 프로젝트에 추가되는 형태로, 각 서비스는 웹팩의 엔트리포인트로 구분되기는 하지만, 하나의 패키지에서 하나의 웹팩설정으로 한번에 빌드되는 구조였다.

이로 인해 의존성 지옥과 너무 긴 빌드타임이라는 문제점이 발생했다. 서로 코드를 공유하지 않는 A와 B 서비스, 그리고 두 서비스가 공유하는 X라는 의존성 패키지가 존재한다고 하자. A는 이미 개발이 완료되어 정상적으로 서비스되던 중 B를 개발하다 보니 (이미 A에서 사용하던) X 패키지에서 버그 발견하게 되었다. 이때 B의 개발을 위해 X의 버전을 올리면 A에서 에러가 발생하거나 작동이 달라지는 경우가 종종 발생했다.

토스는 이를 해결하기 위해 기존의 거대한 소스코드를 독립적인 패키지로 분리하고 각각을 빌드하기로 결정하였는데, 레포지토리를 구분해서 사용하자니,,, 공통 코드의 공유 어려움, 사용 라이브러리의 파편화, 복잡한 서비스 관리 등의 문제가 발생하여 결국 모노레포를 도입하게 되었다. (아래 그림ㅋㅋㅋㅋㅋ 미쳤나봨ㅋㅋㅋㅋ 너무 웃곀ㅋㅋㅋ)

모노레포 : 의존성 지옥의 구원자

모노레포는 무엇이고, 어떤 좋은 점을 갖고 있길래 토스 뿐만 아니라 Google, Facebook 및 Twitter와 같은 대기업이 사용할까?

일반적으로 자주 사용했던 멀티레포 방식은 여러 레포지토리에 패키지들을 분산시켜서 사용한다. 장점 :

• Repository 별 Owner를 지정 : 수월한 패키지 관리
• 각 레포지토리별 빠른 CI Build : 하나의 Repository는 하나의 Continuous Integration 구성
• 패키지의 명확한 분리로 인한 유연성 향상 : Repository 상 서로 연계 관계가 없기 때문에 추가, 수정, 유지 관리 편리

단점 :

• 중복된 설정 및 반복된 설치 : 모든 공통된 설정과 모듈들을 반복적으로 설정/설치해야 함
• 이슈의 분산 : 각 다른 레포지토리가 연관되어있는 이슈 트래킹 관리 어려움
• Dependency Hell : 여러 패키지들이 사용하는 같은 모듈에서 (의도됐든 의도되지 않았든) 버전 차이 발생 및 충돌 발생 가능
• 중복 코드의 가능성 : 중복된 설정 및 반복된 설치와 비슷하게 레포지토리가 분리되어 공통된 코드가 중복될 가능성이 커짐

반면, 모노레포란 하나의 저장소에서 여러 프로젝트를 관리한다. (기존의 멀티레포의 단점을 장점으로, 장점을 단점으로 가진다) 장점 :

• 공통 항목 단일화 : eslint, Build, Unit Test 등 공통된 설정 및 필요한 node module을 한 번의 설치와 한 번의 설정으로 모든 패키지가 사용할 수 있다.
• 쉬운 Package 공유
• 단일 이슈 트래킹 : 모노레포 내 연관된 패키지들에 관한 (분산될 필요 없는) 이슈 트래킹
• 효율적인 의존성 관리

단점 :

• Repository의 거대화 : 분산되어 있던 모든 리소스를 하나의 레포로 합치면서,,
• 느린 CI Build : CI가 하나로 구성된다는 장점 == 규모가 커짐에 따라 분산된 CI 빌드보다 속도가 느릴 수밖에 없음
• 무분별한 의존성 : Package 간 의존성 관리가 쉽지만, 오히려 과도한 의존성 관계 발생 가능

제로빌드 : 긴 빌드시간을 줄이자!

토스에서는 빌드시간을 줄이기 위해서 yarn berry의 zero-install이 작동하는 방식을 차용했다.

(yarn berry와 node modules도 한번 정리해야 하긴 하는데,, 간략하게 정리하면 yarn berry는 기존의 yarn과는 다르게 의존성을 압축 파일로 관리하고 숫자가 적어 Git으로도 의존성을 충분히 관리할 수 있다. 이렇게 의존성을 아예 버전 관리에 포함하는 것을 Zero-Install이라고 한다. 새로 저장소를 복제하거나 브랜치를 바꾸었다고 해서 yarn install을 실행하지 않아도 되고, 이로 인해 CI/CD도 쉬워진다는 이점이 있다. 참고 : https://toss.tech/article/node-modules-and-yarn-berry)

빌드 시간을 줄이기위해서 변경사항이 없는 패키지는 빌드를 하지 않도록 변경했다! 모노리스 방식에서는 이런 방식을 사용하기 어려웠지만, 마이크로 프론트엔드 아키텍쳐에서는 소스코드 변경이 있는 패키지만 새로 빌드하면 됐기 때문에 쉽게 도입할 수 있었다. 기존 빌드의 결과물을 아예 git에 저장하여 언제든 pull만 받으면 최신 빌드 결과를 사용할 수 있도록 하였다.

무조건 모노레포를 사용해야 할까?

모노레포가 좋다는건 알겠는데,, 그럼 무조건 마이크로서비스/모노레포를 선택해야 할까?

정답은 너무 당연하게, NO! 이들은 어느 정도 복잡성을 가진 (각 서비스/패키지로 구별되는) 시스템에서 유용하다. 실제로는 여러 개의 서비스를 나누고 관리하는 것 또한 비용이기 때문에 오히려 생산성에 방해가 될 수도 있다. 특히 프로젝트 초반에는 실제로 사용자들에게 유용한 기능을 빠르고 정확하게 만드는 것이 중요할 때가 많고, 비교적 규모가 적은 프로젝트에서는 서비스 간에 경계를 명확하게 나누는 일이 어렵기도 하다.

결론 : 소규모 프로젝트 내 빠른 개발을 위해서는 모노리스/멀티레포 구성이 더 수월한 경우가 있음!

Lerna : 모노레포를 쉽게 만들어보자!

lerna는 다중의 패키지가 있는 모노레포 자바스크립트 프로젝트의 test, build, release 같은 작업을 최적화 시켜주는 툴이다. 여러 패키지의 의존성을 묶어주는 역할과 각 패키지별 버전 업데이트를 도와준다.

lerna로 init한 프로젝트의 최상위에는 packages 폴더와 package.json, lerna.json이 존재한다. packages에는 각각의 서브 패키지들이 들어가며, package.json는 기존과 같이 script를 통해 (개별적으로 혹은 동시에) 패키지의 스크립트를 실행할 수 있도록 한다. lerna.json에서는 lerna관련 옵션값들이 저징되어 있는데, package의 폴더 지정이나 npm/yarn 지정 및 bootstrap 등을 지정할 수 있다.

Lerna의 여러 커맨드

• lerna init : 새로운 lerna 저장소 생성
• lerna bootstrap : 각 패키지별로 겹치는 dependency를 연결하면서 모든 패키지들의 의존성 설치 ex) @foo/server와 @foo/client에서 같은 lodash 라이브러리를 사용한다면, 겹치는 의존성은 연결되어서 루트 디렉토리의 node_modules에 설치되고, 겹치지 않는 의존성은 각각의 패키지 프로젝트의 node_modules에 설치
• lerna import : 에 해당하는 패키지를 커밋 히스토리와 함께 packages/으로 import해준다. 손쉽게 모노레포 완성!
• lerna publish : 업데이트된 패키지의 새로운 배포 생성 (버전 업데이트, git 및 npm에서 모든 패키지 업데이트)
• lerna chanced : 지난 배포 이후 어떤 패키지에 변화가 있었는지 확인
• lerna run : 각 패키지들의 package.json에 정의된 script들을 실행

현재 토이프로젝트로 만들고 있는 보드게임에서는 react native와 react native web을 통해 앱과 웹을 한번에 만들고 있는데, 모노레포 내에서 여러 의존성 충돌이 발생하여 해결하는데 애를 먹었었다. 어떤 것들이 문제였는지, 어떻게 해결했는지 미래의 내가 다시 기록해주길 바라면서,, (똑같은 문제 다시 보면 적어놔야지,,, mmazzarolo님 사랑합니다 https://github.com/mmazzarolo/react-native-universal-monorepo)

오늘은 여기까지!

참고) https://www.youtube.com/watch?v=FQoNY2W0s4E https://toss.im/slash-21/sessions/2-5 https://github.com/Pyrolistical/microapps.git https://soobing.github.io/micro-frontends/ https://martinfowler.com/articles/micro-frontends.html#TheExampleInDetail

과거)) 인터프리터 언어의 컴파일?

시작하기 전에 간단하게 짚고 넘어가자면, 컴파일 언어는 실행 전 별도로 소스코드를 컴파일하여 기계어로 변환하기 때문에 실행시간이 비교적 빠르고 인터프리터 언어는 코드를 실행할 때에 인터프리터가 기계어로 번역하고 실행기 때문에 비교적 느립니다.

javascript는 인터프리터 언어이지만 코드를 해석하고 실행하는 엔진에서 각자 인터프리터 방식으로 구현될 수도 있고, 컴파일러 방식으로 구현될 수도 있습니다. 특히 과거 V8 엔진의 경우 자바스크립트 수행 속도를 개선하기 위해 자바스크립트 코드를 (바이트 코드를 거치지 않고) 머신코드로 번역하여 사용하는 컴파일러 형식을 사용했습니다.

• full-codegen : a simple and very fast compiler that produced simple and relatively slow machine code.
• Crankshaft : a more complex (Just-In-Time) optimizing compiler that produced highly-optimized code.

풀코드젠은 자바스크립트를 머신코드로 변환하여 빠르게 실행할 수 있도록 해주는 일종의 컴파일러이고 크랭크샤프트는 풀코드젠으로 코드가 실행된 뒤, 자바스크립트의 추상구문트리를 최적화하여 static single-assignment, SSA form으로 변환하는 옵티마이저입니다.

V8 엔진은 내부적으로 여러 쓰레드를 사용하는데, 메인 쓰레드에서는 코드를 컴파일하고 실행하고, 프로파일러 쓰레드에서는 어떤 메서드에서 시간이 오래 걸리는지 알려주며, 그 외에도 가비지 컬렉터 등을 위한 여러 쓰레드가 있습니다. 크랭크샤프트는 풀코드젠으로 코드가 실행된 이후 프로파일러 쓰레드가 충분한 데이터를 얻게된 이후, 그 데이터들을 바탕으로 최적화를 실행합니다.

크랭크 샤프트의 최적화 기법

1. 인라이닝

크랭크샤프트의 최적화는 미리 가능한 많은 코드를 인라이닝(inlining)하는 것에서부터 시작합니다. 인라이닝이란 호출 지점(함수가 호출된 곳의 코드 위치)을 호출된 함수의 내용으로 바꾸는 단순한 과정으로, 이후의 최적화 과정에서 사용됩니다.

2. 히든 클래스

이후 크랭크 샤프트는 히든클래스를 생성합니다. 자바스크립트는 프로토타입 기반의 언어이기 때문에 실질적인 클래스라는 것은 없으며 각 객체는 복제 과정을 통해 생성되는데, 객체 속성 값의 위치를 메모리에 저장하기 때문에 속성값을 읽어오는 것이 자바나 C#같은 언어에서보다 코스트가 큽니다. (자바에서는 모든 객체 속성이 컴파일 전에 고정된 객체 레이아웃에 의해 설정되고 런타임에서는 동적으로 추가되거나 제거될 수 없기도 하고 자바스크립트에서 해시함수를 이용해서 메모리 상에서 객체 속성의 위치를 매번 찾아내는 것이 코스트가 크기도 함) 따라서 크랭크샤프트는 자바와 비슷하게 런타임에 객체에 포함되는 속성들을 미리 결정하는 방식을 사용합니다.

Point라는 예시를 통해 히든클래스가 어떻게 만들어지는지 살펴보겠습니다. 일단 new Point(1, 2)가 실행되면 V8은 이라는 C0 히든클래스를 생성합니다. C0은 첫번째 클래스 단계를 표현하기 위한 임의의 이름이며, Point에 아직 아무 속성도 정의되지 않았으므로 C0은 비어있습니다.

첫 번째 구문인 this.x = x가 수행되면 V8은 C0을 기반으로 C1이라는 두 번째 히든 클래스를 생성합니다. C1은 x속성을 찾을 수 있는 메모리상의 위치에 대한 설명을 포함하고 있으며, 생성되었던 C0 클래스에도 만약 x속성이 추가되면 객체가 가리키는 히든 클래스가 C0에서 C1으로 전환되어야 한다는 내용이 포함됩니다.

this.y = y가 수행될 때도 동일한 동작이 반복됩니다. C2라는 새로운 히든클래스가 생성되고, C1에 y속성이 포인트 객체에 추가되면 C2로 변경되어야 한다는 클래스전환이 추가되며, 포인트 객체의 히든 클래스는 C2로 업데이트됩니다.

여기서 중요한 점은 히든클래스 전환은 객체에 속성이 추가되는 순서에 의존적이라는 것입니다. 예시를 보면 p1과 p2는 모두 객체에 a와 b속성을 추가로 가지지만 서로 다른 순서로 선언되었습니다. 이들은 결과적으로 같은 속성들을 가지게 되지만, 각 개체는 서로 다른 히든클래스를 가리키게 됩니다. 오른쪽 파란 그림으로 확인할 수 있듯이 p1에서는 속성 a가 먼저 추가되고 p2의 경우 b가 먼저 할당되면서 전환 경로도 달라지고, 서로 다른 히든클래스를 사용하게 됩니다. 이와 같은 경우에 같은 히든클래스를 재사용할 수 있도록 속성을 같은 순서로 초기화하는 것이 성능상으로 훨씬 좋습니다.

3. 인라인 캐싱

마지막 최적화 방법 중 하나인 인라인 캐싱은 앞서 말한 히든클래스와도 관련이 있습니다. 특정 객체에 메소드가 호출될 때마다 V8엔진은 특정 속성에 접근하기 위한 오프셋을 계산하기 위해 해당 객체의 히든클래스를 뒤져봐야 합니다. 동일한 히든 클래스의 동일한 메소드의 호출을 두 번 성공하고나면 V8은 히든클래스를 찾는 것을 생략하고 단순하게 스스로 해당 객체 포인터에 속성 오프셋을 더해 놓습니다. 이후 해당하는 메소드에 대한 모든 호출이 있을 때마다 V8엔진은 히든클래스가 변하지 않았다고 가정하고 이전에 캐싱해두었던 오프셋을 이용해 직접 메모리 주소로 이동하고, 이를 통해 실행 속도는 크게 증가합니다. 앞의 예제처럼 타입은 같지만 런타임에서 만들어지는 히든클래스가 다른 객체의 경우(C4와 C6) 인라인캐싱 조건인 “동일한 히든 클래스"를 만족하지 않기 때문에, 최대한 히든클래스를 공유할 수 있도록 하는 것이 성능에 유리합니다

현재)) 이그니션과 터보팬

V8엔진은 5.9버전에서 크게 바뀌었는데, 파이프라인의 변화를 통해 성능 향상과 더불어 자바스크립트 응용프로그램들에서 메모리를 현저하게 절약할 수 있게 되었다고 합니다. 새로운 파이프라인은 인터프리터인 이그니션과 최적화 컴파일러인 터보팬으로 구성되어 있습니다.

저는 몰랐지만 타 블로그에서 V8은 8기통 엔진을, Ignition은 엔진에 시동걸 때 사용하는 점화기, TurboFan 또한 (실행 중 코드가? 너무 뜨거워졌을 때 최적화를 통해) 과열된 상태를 식혀준다는 의미가 있다고 합니다.

Ignition은 기존의 Full-codegen을 대체하는 인터프리터입니다. 기존의 Full-codegen은 전체 소스 코드를 한번에 머신코드로 컴파일하면서 메모리 사용량이 컸는데, 모바일에서 특히 문제가 도드라졌다고 합니다. 이를 해결하기 위해 인터프리터 방식으로 돌아와 자바스크립트코드를 한줄한줄 실행할 때마다 머신코드 이전 단계인 바이트코드 상태로 컴파일하는 이그니션을 사용하게 되었습니다. 이를 통해 메모리 사용량 감소 뿐만 아니라, 파싱하기에도 편해졌으며, 터보팬에서 최적화를 할 때에 바이트코드만 고려하면 됐기 때문에 터보팬에서의 최적화 또한 훨씬 편리해졌다고 크롬 모바일팀에서 발표했습니다. (실제로 7개의 컴퓨터 아키텍쳐를 지원하기 위해서 사용되던 코드가 만육천 줄에서 3천줄로 감소했다고 함. 초기 실행에는 시간이 약간 걸리지만 바이트코드로라도 변환한 이후부터는 c++에 근사하는 성능을 낼 수도 있다고 함. 단, 잘짜진 코드만 ㅎㅎ;;)

터보팬의 경우 이그니션에서 만들어진 바이트 코드를 기반으로, 크랭크샤프트에서 최적화 단계에서 사용하던 히든클래스와 인라인 캐싱을 통해 최적화를 진행합니다. (최적화의 시작은 프로파일러 쓰레드가 메인 쓰레드를 감시하다가 일정 기준 이상 동일한 함수가 호출되면 시작됩니다.)

기본적인 동작 방식은 여기까지입니다! GC나 React Native에서 사용하는 헤르메스 엔진 등등 스터디에서 다뤘던 내용은 한참 남아있는데, 모두 다 정리할 생각을 하니 막막하네요.. 천천히 한걸음부터 해보겠습니다!! 😁😁

1. 타입 힌트
2. 컴프리헨션 (List Comprehension, Dict Comp., Set Comp., Generator Expression)
3. 제너레이터, range
4. 여러 함수들 (enumerate, 나눗셈 연산자, print와 string formating, pass, locals, 스타일 가이드)
5. 참조 시 주의할 점
6. 리스트, set, dict 기본 연산자

1. 타입 힌트

파이썬의 경우 동적 타이핑 언어(인터프리터 언어)임에도 불구하고, 대규모 프로젝트에서도 가독성을 높이기 위한 타입힌트 기능이 있다. (그러나 강제 규약이 아니어서 사용자가 타입 힌트를 보고도 잘못 할당하는 경우가 있을 수 있음. mypy을 설치하여 실행 이전에 확인하는 기능을 사용할 수 있다.)

2. 컴프리헨션 (List Comprehension, Dict Comp., Set Comp., Generator Expression)

리스트, 집합, 딕셔너리 등 선언 시, 반복문과 조건문을 생성자 내부에서 사용하여 쉽게 정의하는 것

# 반복 및 조건문
[n*2 for n in range(1, 10+1) if n % 2 == 1] # [2,6,10,14,18]

# if문들은 and로 묶여 모두 만족하는 경우에만 실행
[i for i in range(5) if i%2==0 if i%4==0] # [0,2,4]

# if, else를 함께 쓰는 경우에는 반복문 왼쪽에
[i if i%2==0 else 'odd' for i in range(5)] # [0,'odd',2,'odd',4]

# 다중 조건문 실행결과
[(i,j) for i in range(2) for j in range(3)] # [(0, 0), (0, 1), (0, 2), (1, 0), (1, 1), (1, 2)]

# 두가지 모두 동일한 실행 결과를 리턴
[(i,j) for i in range(3) if i%2 == 0 for j in range(3)]
[(i,j) for i in range(3) for j in range(3) if i%2 == 0]
# [(0, 0), (0, 1), (0, 2), (2, 0), (2, 1), (2, 2)]

# Set, Dict에서도 동일하게 작동한다.
[j for i in range(3) for j in range(3)] # [0, 1, 2, 0, 1, 2, 0, 1, 2]
{j for i in range(3) for j in range(3)} # {0, 1, 2}
{i:j for i in range(3) for j in range(3)} # {0: 2, 1: 2, 2: 2}

# 손쉽게 key와 value를 swap할 수 있다
a = {1: 'one', 2: 'two'}
{value:key for key,value in a.items()} # {'one': 1, 'two': 2}

# Generator도 쉽게 생성할 수 있다.
# 호출 가능한 범위를 벗어나게 되면 StopIteration 에러 발생
gen = (x**2 for x in range(10))
print(gen) # <generator object <genexpr> at 0x105bde5c8>
print(next(gen)) # call 1 # 0
print(next(gen)) # call 2 # 1
# ...
print(next(gen)) # call 11

# Generator Expression으로 생성하는 경우에도,
# yield로 생성하는 일반적인 경우와 똑같이 sum을 사용할 수 있다. (iterable 객체)
gen = (x**2 for x in range(10))
sum_of_squares = sum(gen) # 285

3. 제너레이터, range

루프의 반복 동작을 제어할 수 있는 루틴 형태. 대량의 값을 생성하는 등의 동작에서 사용된다. 모든 값들을 메모리에 보관하지 않고 제너레이터만을 저장하고 실행시마다 값을 생성해내어 메모리를 크게 아낄 수 있다. yield를 통해 제너레이터 값을 내보낼 수 있으며, 함수는 종료되지 않고 다음 yield가 불리게 되는 때에 다시 실행된다.

def test_generator():
    yield 1
    yield 'string'
    yield True
gen = test_generator()
type(gen) # <class 'generator'>
next(gen) # 1
next(gen) # 'string'
next(gen) # True
next(gen) # StopIteration 에러 발생

두 객체는 서로 다른 객체이며, 각기 따로 동작한다.

h = test_generator()
i = test_generator()
h == i # False
h is i # False
next(h) # 1
next(i) # 1

range는 제너레이터 방식을 활용하는 대표적인 함수이다. range()를 통해 range 클래스 객체를 생성할 수 있으며, 생성 조건만 정해두고 필요할 때마다 숫자를 생성한다. 아래 두 예시는 서로 다른 방식으로 100만개의 수를 출력하지만 데이터 타입과 메모리 점유율에서 차이가 있음을 알 수 있다. 미리 생성하지 않은 값은 인덱스에 접근 시 바로 생성하도록 구현되어 있기 때문에 리스트와 거의 동일한 느낌으로 사용할 수 있다.

a = [ n for n in range(1000000)]
b = range(1000000)
len(a) # 1000000
len(b) # 1000000
type(a) # <class 'list'>
type(b) # <class 'range'>
b # range(0, 1000000)
import sys
sys.getsizeof(a) # 8448728
sys.getsizeof(b) # 48

4. 도움이 되는 여러 함수들 (enumerate, 나눗셈 연산자, print와 string formating, pass, locals, 스타일 가이드)

enumerate() : 인덱스와 값 모두 처리하기

a = [2,4,6,8]
for idx,val in enumerate(a):
    print(idx,val)

나눗셈 연산자 : //는 몫, %는 나머지를 반환. divmod는 몫과 나머지를 한번에 반환한다.

5 // 3 # 1
5 % 3 # 2
divmod(5,3) # (1, 2)

print : sep, end 지정 가능. string formating을 함께 사용하면 더욱 편리하다

print("aa", "bb", "cc", sep="~~", end="@@finish@@")
# aa~~bb~~cc@@finish@@ # 이후 줄바꿈 없이 다음 줄이 연이어서 프린트된다.

idx = 3
val = "three"
print("{0}: {1}".format(idx,val)) # 3: three
print(f"{idx}: {val}") # 3: three

pass : 코드의 전체 골격을 잡아놓고 내부 함수들을 나중에 만들기 위해 아무 역할도 하지 않는 널 연산을 반환.

locals : locals()는 현재 로컬 스코프에 정의된 모든 변수를 반환한다. print하여 알고리즘 디버깅 시에 유용하게 사용 가능하다. pprint를 import하여 pprint.pprint(locals())를 통해 예쁘게 정렬된 로컬 변수들을 출력할 수 있다!

인덴테이션 : 파라미터가 시작되는 부분에 맞추거나, 다음 줄과 헷갈리지 않도록 인덴트 추가하기

네이밍 컨벤션 : 스네이크 케이스를 추천

스타일 가이드 : 불명확한 것이 없도록 한다. 함수의 변수 기본값으로 mutable한 객체를 사용하는 대신 immutable 객체 사용하기, True False 판별 시에는 implicit한 방법으로 간결하게 표현하기

# Good
def foo(a, b=None):
    if b is None:
        b = []
    pass

def foo(a, b: Optional[Sequence] = None):
    if b is None:
        b = []
    pass

if not users:
    print('no users')

if foo == 0:
    self.handle_zero()

if i % 10 == 0:
    self.handle_multiple_of_ten()

# Bad
def foo(a, b=[]):
    pass

def foo(a, b: Mapping = {}):
    pass

if len(users) == 0:  # foo != [] 등으로 체크하는 것도 비추, not users로 의미 전달 명확하게
    print('no users')

if foo is not None and not foo: # 0인 것을 암시적 False 대신 정수로 처리하는 것이 명확
    self.handle_zero()

if not i % 10: # 1 % 10 == 0과 같이 명시적으로 값을 비교하는 것이 좋다
    self.handle_multiple_of_ten()

5. 참조 시 주의할 점

C++와 다른 참조와 비교 C++의 경우 참조형에 재할당이 일어나더라도 가리키는 메모리 주소가 변하지 않는다. 반면, 파이썬은 원시타입이라는 것이 따로 존재하지 않고 모든 것이 객체-불변객체 or 가변객체-로 이루어져 있는데, 새로운 불변객체를 할당하게 되면 새로운 객체를 참조하게 되어 가리키는 메모리 주소가 달라지고 가변객체의 경우 참조 대상의 변수도 변경할 수 있게 되어 아래와 같은 결과를 가진다. 파이썬의 리스트는 모든 아이템의 레퍼런스 주소값을 개별적으로 모두 소유하고 있다. https://del4u.tistory.com/27 설명 굿 (참고로, new_list = old_list[::] 또는 new_list = list(old_list)을 사용하여 새로운 리스트를 가리킬 수 있다.)

참고로 파이썬이 느린 이유 중 하나로, 단순히 정수형의 덧셈 연산을 하는 경우에도 C나 Java와 달리 객체에서 타입코드를 찾는 등 부가연산이 존재하기 때문이다.

// C++
int a = 10;
int &b = a;
b = 7;
std::cout << a << std::endl; // 7

# python
a = 10
b = a
b = 7
print(a, id(a),id(b)) # 10, 4550522560, 4550522464

a = [1, 2, 3]
b = a
b[2] = 5
print(a) # [1, 2, 5], 리스트의 경우 각각이 

is와 == is는 id()값을 비교하는 함수, ==는 값을 비교하는 연산자이다. None은 값 자체가 정의되어있지 않아 is로만 비교가 가능하다!!

6. 리스트, set, dict 기본 연산자

https://www.ics.uci.edu/~pattis/ICS-33/lectures/complexitypython.txt 내용 중 일부