Pewww

블로그 주소 이전

Pewww — Fri, 2 Sep 2022 10:55:48 +0900

블로그 주소가 이전되었습니다!

https://medium.com/@yunjae.jung

JIRA 위키에서 티켓의 시간 추적 되돌리기

Pewww — Tue, 26 Jan 2021 13:55:13 +0900

위키에서는 티켓에 대한 예상, 남은 시간, 기록된 시간에 대한 정보를 제공하는 시간 추적 기능을 제공합니다.

티켓 페이지

프로젝트를 진행하며 작업 시간(= 기록된 시간)을 실수로 3시간이 아닌 33시간으로 등록했다면 어떻게 이전 상태로 되돌릴 수 있을까요?

위키의 티켓 페이지에는 활동이라는 카테고리가 존재하며,

1. 모두

2. 댓글

3. 작업 기록

4. 이력

5. 활동

위와 같이 총 5가지의 탭으로 나뉩니다.

티켓과 관련된 작업 내용들은 모두 히스토리로 남게 되며, 우리는 이를 이력 탭에서 확인할 수 있습니다.

이력 탭

말 그대로 모든 작업 이력들에 대한 정보를 확인할 수 있지만, 해당 탭에서는 각 이력에 대한 수정이 불가능합니다.

따라서, 실제 수정이 목적이라면 이력이 아닌 작업 기록이라는 탭으로 이동해야합니다.

작업 기록 탭

얼추 보면 이력 탭에서 보던 리스트의 형태와 비슷해 보이지만, 위에서 작업 시간을 기록한 것과 같이 유저가 실제로 작업에 대한 액션을 취한 기록들만을 노출합니다.

그렇기에, 상태를 '할 일'에서 '진행 중'으로 변경하거나 댓글을 남기는 등의 행위는 모두 작업 기록이 아닌 이력 탭에 남게 됩니다.

작업 기록 탭에서는 수정이나 삭제, 공유 기능을 제공하기 때문에 사용자는 이를 이용하여 작업 시간을 이전 상태로 되돌리거나 커스텀하게 수정하는 것이 가능해집니다.

삭제 버튼 클릭 시 아래 사진과 같이 남은 예상 시간을 설정할 수 있는 팝업이 노출되며,

삭제 팝업

삭제가 완료됐을 때, 입력한 예상 시간 정보를 기반으로 시간 추적 정보가 원래대로 돌아온 것을 확인할 수 있게 됩니다.

원본 상태로 돌아온 페이지

크롬 퍼포먼스 탭과 debugger 키워드로 효율적인 디버깅하기

Pewww — Tue, 24 Nov 2020 19:49:28 +0900

메쉬코리아 팀 블로그로 글을 이전하였습니다!

아래 링크 확인 부탁드리겠습니다.

https://medium.com/mesh-korea-fe-team-blog/effective-debugging

ES2020 Optional Chaining과 void operator

Pewww — Sat, 18 Apr 2020 18:45:44 +0900

이번 ES2020에서 새로 추가된 Optional Chaining은 "?."를 사용하여 객체의 속성 값에 대해 접근할 수 있게 해줍니다.

이미 타입스크립트 3.7 버전에서 구현된 기능이기 때문에, 기존에 타입스크립트를 사용하시던 개발자분들은 그리 낯설지 않은 문법일 것 입니다.

참조하는 대상이 null이나 undefined가 아니라면(= nullish 하지 않다면) 속성에 대한 접근이 가능하며, 만약 nullish 할 경우 undefined를 반환합니다.

function getProp(obj) {
  return obj?.a;
}

// A
const obj = {
  a: 1
};

getProp(obj); // 1

// B
const obj2 = null;

getProp(obj2); // undefined

일반적인 객체 형식이 아닌 함수의 호출에도 역시 사용이 가능하며, 방법은 동일합니다.

function add(x, y) {
  return x + y;
}

const num = add?.(2, 3);

console.log(num); // 5

함수가 존재한다면 실행하고 아니면 undefined를 반환합니다.

자바스크립트에서는 런타임시에 프로퍼티를 체크하기 때문에

const user = {
  name: 'Pewww',
  gender: 'male'
};

// A와 B 모두 Uncaught TypeError: Cannot read property 'zonecode' of undefined 발생

// A
const {
  address: {
    zonecode
  }
} = user;

// B
const zonecode = user.address.zonecode;

와 같이 user의 address가 존재하지 않는 상황에서 zonecode에 접근할 경우 에러를 출력하며, 이를 방지하기 위해

const {address} = user;
const {zonecode} = address || {};

나

const zonecode = user.address && user.address.zonecode;

와 같은 코드를 작성합니다.

접근해야 할 대상이 많지 않을 땐 크게 신경쓰지 않아도 되지만, 객체의 중첩이 아래와 같이 깊어질 경우 구문은 지저분해질 수 밖에 없고 곧 가독성에 타격을 줍니다.

const obj = {
  a: {
    b: {
      c: {
        d: {
          e: 'Hello'
        }
      }
    }
  }
};

// Before
const e = obj.a && obj.a.b && obj.a.b.c && obj.a.b.c.d && obj.a.b.c.d.e;

// After
const e = obj?.a?.b?.c?.d?.e;

다소 뜬금 없을 수도 있지만, Optional Chaining이 적용된 코드가 Babel을 통해 transpiling을 거쳤을 때 어떻게 변화하는지 확인하고 싶어 테스트를 해봤습니다.

const obj = {
  a: 1
};

const a = obj?.a;

다음과 같은 코드가

const obj = {
  a: 1
};

const a = obj == null ? void 0 : obj.a;

의 형태로 변화하는 것을 보고 문득 void 0은 무엇이고 어떤식으로 동작을 하는지, undefined 대신 사용된 이유가 무엇일지 궁금해졌습니다.

void는 연산자로써 뒤에 나타내는 표현식을 실행하고 undefined를 반환합니다.

보통 구문은 아래와 같이 void expression의 형태를 띄고,

void console.log(5); // 콘솔에 5 출력 후 undefined 반환
void 120 + 110; // 120 + 110 계산 후 undefined 반환

괄호의 유무의 따라 주어진 식의 평과 과정이 달라질 수 있습니다.

// undefined == '10'과 같음, 따라서 false 반환
void 10 == '10';

// void true와 같음, 따라서 undefined 반환
void (10 == '10');

IIFE를 사용할 때 void를 사용하면, function 키워드를 선언문이 아닌 표현식 처럼 간주하도록 강제하는 것 역시 가능합니다.

void function ceilNum(num) {
  const result = Math.ceil(num);
  console.log(result);
}(5.3);

// 콘솔에 6 출력

a 태그에 링크 기능을 제거하기 위해 사용하기도 하지만,

<a href="javascript:void(0)">
  https://pewww.tistory.com
</a>

Mozila에서 이벤트 처리기와 같은 대체제를 사용하라는 것으로 봐선 javascript: 의사 프로토콜의 사용을 그리 권장하진 않는 듯 합니다.

그렇다면 왜 Babel은 undefined가 아닌 void 0을 사용한 것일까요?

undefined는 전역 객체의 속성이며, 초기 값은 undefined 그 자체의 원시 값입니다.

최신 브라우저에서 undefined는 ECMAScript 5 명세에 따라 설정과 쓰기가 불가능한 속성이지만, 오래된 브라우저에서는 전역에서의 값의 할당이 가능했습니다.

물론 현재도 undefined는 예약어(https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Lexical_grammar#키워드) 가 아니기 때문에 지역 변수로써 선언될 수는 있지만, 역시 좋은 방법은 아니며 반드시 피해야 하는 구문이라고 MDN은 설명하고 있습니다.

function compareUndefined() {
  const undefined = 5;
  const num = 5;

  return num === undefined;
}

const result = compareUndefined();

console.log(result); // true

이러한 특징들을 봤을 때, babel이 void 연산자를 사용한 이유는 아마 이 점이 아닐까 싶습니다.

"Undefined 그 자체로서의 의미를 보장하기 위해."

즉, 의미에 대한 불변성의 유지를 위한 것이죠.

상황에 따라 나타내는 값이 달라질 수 있는 undefined 대신 void 0을 사용함으로써, 데이터 (= transpile된 결과물) 의 정확성을 보장하고 혹시 모를 예외나 변수들을 미리 차단하는 것으로 보입니다.

물론, 단순히 개인적인 의견이기 때문에 실제 의도와 다를 수 있다는 점 알아주셨으면 합니다...

어쨌든 이번 ES2020에 꽤나 흥미로운 문법들이 많이 추가되었던데, 잘 적응해서 실제 코드에 활용해봐야겠습니다.

글 읽어주셔서 감사합니다 :D

RTL로 HOC with React-Hooks 테스트 하기

Pewww — Sun, 15 Mar 2020 23:15:18 +0900

이번 포스팅에서는 React-Testing-Library (줄여서 RTL) 를 활용한 HOC 테스트에 대해 정리해보려 합니다.

리액트 컴포넌트 테스트를 위해 보통 Enzyme나 RTL을 사용하는데,
Enzyme가 Implementation Driven Test 방법론을 따르며 어플리케이션이 어떻게 동작하는지에 대해 초점이 맞춰진 반면,

RTL은 Behavior Driven Test (행위 주도 테스트) 방법론을 기반으로 어플리케이션을 사용하는 사용자의 행동에 초점을 맞추고 있습니다.

어쨌든, 예시로 들어볼 코드는 아래와 같습니다.

// loginRequired.tsx

import * as React from 'react';
import {useSelector} from 'react-redux';
import Page401 from '../components/errors/Page401';

const loginRequired = (Target: React.ComponentType) => {
  const LoginRequired = (props) => {
    const {access} = useSelector(({session: {access}}) => ({
      access
    }));

    return !access ? (
      <Page401/>
    ) : (
      <Target {...props}/>
    );
  };

  LoginRequired.displayName = 'LoginRequired';
  LoginRequired.getInitialProps = Target.getInitialProps;

  return LoginRequired;
};

export default loginRequired;

loginRequired 로그인이 필요한 페이지들에서 사용되는 HOC 이며, 비로그인 상태의 유저가 페이지에 접근할 시 401 에러 페이지를 보여주는 역할을 합니다.

해당 코드에서 저희가 테스트에 중점을 둬야 할 부분은 딱 2가지라고 할 수 있습니다.

useSelector hooks를 통해 access를 받아오는지
받아온 access에 따라 각각 다른 페이지/컴포넌트를 보여주는지

이 두 부분에 중점을 둬서 테스트 코드를 작성해보면, 아래와 같이 나타낼 수 있을 것 같습니다.

// loginRequired.test.tsx // A

import * as React from 'react';
import {useSelector} from 'react-redux';
import {renderHook} from '@testing-library/react-hooks';
import loginRequired from '../loginRequired';
import {render} from '@testing-library/react';

const AccessedComp = () => ( // B
  <div>로그인 된 상태입니다.</div>
);

jest.mock('react-redux', () => ({ // C
  useSelector: jest.fn()
}));

jest.mock('next/router', () => ({ // D
  useRouter: () => ({
    pathname: '/test',
    asPath: '/test?message=hello'
  })
}));

const mockUseSelector = useSelector as jest.Mock; // C

describe('loginRequired 테스트', () => {
  it('access가 null일 때 Page401 반환', () => {
    mockUseSelector.mockImplementation(callback => callback({ // E
      session: {
      	access: null
      } 
    }));

    const {
      result: {
        current: {
          access
        }
      }
    } = renderHook( // F
      () => useSelector(({session: {access}}) => ({
        access
      }))
    );

    expect(access).toBeNull();

    const Comp = loginRequired(AccessedComp);
    const wrapper = render(<Comp/>); // G

    expect(wrapper.getByText('로그인 후 이용 가능한 서비스입니다.')).toBeInTheDocument(); // H
  });

  it('access가 null이 아닐 경우(= 로그인 된 상태일 때) 받은 컴포넌트 그대로 출력', () => {
    mockUseSelector.mockImplementation(callback => callback({
      session: {
        access: 'Access Token'
      }
    }));

    const {
      result: {
        current: {
          access
        }
      }
    } = renderHook(
      () => useSelector(({session: {access}}) => ({
        access
      }))
    );

    expect(access).not.toBeNull();

    const Comp = loginRequired(AccessedComp);
    const wrapper = render(<Comp/>);
    
    expect(wrapper.getByText('로그인 된 상태입니다.')).toBeInTheDocument();
  });
});

이제 주석 처리한 부분들에 대해 차근차근 설명해보겠습니다.

테스트를 위한 컴포넌트도 해당 파일 내에 같이 존재하기 때문에 확장자를 .ts가 아닌 .tsx로 설정하였습니다.

로그인 된 상태일 때 보여지는 임시 컴포넌트입니다.

해당 테스트의 목적은 access의 상태에 따라 다른 페이지/컴포넌트를 보여주는 것이기 때문에, 컴포넌트의 props나 state, 복잡한 정도 등은 고려할 필요가 없다고 판단하여 위와 같이 간단히 작성하였습니다 :D

Mocking은 유닛 테스트를 작성할 때, 해당 코드가 의존하는 부분을 가짜로 대체하는 기법을 말합니다.

보통 테스트하려는 코드가 의존하는 부분을 사용자가 직접 생성하기 부담스러운 경우 (Database, API...) 많이 사용하는데, useSelector에도 충분히 활용될 수 있을 것 같아 Mocking 작업을 진행하였습니다.

아래와 같이 next.js의 useRouter hooks를 사용하는 구성 요소를 테스트 하고자 할 때,

const Comp = () => {
  const {asPath} = useRouter();
  .
  .
  .
};

TypeError: Cannot destructure property 'asPath' of 'undefined' or 'null'.

의 에러를 반환하는 것을 확인할 수 있습니다.

useRouter는 React.useContext를 사용하여 《next server / dist / lib / router-context》 에서 컨텍스트를 사용하기 때문에, 이를 해결하려면

import {RouterContext} from 'next-server/dist/lib/router-context';

const wrapper = render(
  <RouterContenxt.Provider value={router}
    <Comp/>
  </RouterContext.Provider>
);

처럼 Wrapping 하는 것이 중요합니다.

다만, jest.mock 함수를 이용하여 useRouter 자체를 Mocking 하는 작업 역시 가능하기 때문에, 해당 방법을 사용하여 테스트 코드를 작성하였습니다.

https://jestjs.io/docs/en/mock-function-api#mockfnmockimplementationfn

Jest · Delightful JavaScript Testing

Delightful JavaScript Testing

jestjs.io

해당 링크에서 확인하실 수 있듯이, mockImplementation 함수를 사용하면 실제 사용하고자 하는 함수를 재구현하는 것이 가능합니다.

useSelector가 각 케이스 마다 다른 state를 반환해야 하므로 (-> access의 상태) 함수 역시 다르게 구현하였습니다.

react-hooks에 대한 테스트를 진행할 때 사용하는 "react-hooks-testing-library"에서 제공하는 함수입니다.

renderHook은 hooks의 파라미터와 반환하는 값을 확인하기 위해 사용하여, 더욱 자세한 내용은 아래의 API 문서를 참고하시면 좋을 것 같습니다.

https://react-hooks-testing-library.com/reference/api#renderhook

API Reference

Simple and complete React hooks testing utilities that encourage good testing practices.

react-hooks-testing-library.com

컴포넌트의 렌더링을 하고자 할 때 render 함수를 이용합니다.

해당 함수를 호출할 시 DOM과 관련된 다양한 쿼리들과 container 에 대한 정보를 제공받을 수 있는데, 여기서 container는 해당 컴포넌트의 최상위 DOM을 가리킵니다. (document.body에 추가된 container를 렌더링한다고 합니다.)

getByText() 함수는 받은 TextMatch를 토대로 일치하는 DOM이 있는지 검색하여 HTMLElement 타입의 값을 반환합니다.

해당 함수를 사용하면 내가 원하는 DOM을 선택할 수 있고, TextMatch는 Matcher 타입이기 때문에 String, RegExp, MatcherFunction 셋 중 어느 타입의 값을 넘기더라도 문제가 없습니다,

여기서, MatcherFunction의 타입은 아래와 같습니다.

type MatcherFunction = (content: string, element: HTMLElement) => boolean;

따라서, 해당 구문은 access의 존재 여부에 따라 서로 다른 컴포넌트가 Document 내에 존재하는지를 테스트 한다는 의미를 담고 있습니다.

다만, toBeInTheDocument 함수는 jest에서 기본적으로 제공하는 속성이 아니기 때문에, 사용하기 위해서는 jest.config.js 파일에서 따로 jest-dom에 대한 설정을 해야 합니다.

아래 링크를 참고하시면 됩니다 :D

https://stackoverflow.com/questions/56547215/react-testing-library-why-is-tobeinthedocument-not-a-function

react-testing-library why is toBeInTheDocument() not a function

Can anyone help me please , I am really stuck on this. Here is my code for a tooltip that toggles the css property display: block on MouseOver and on Mouse Out display: none it('should show and ...

stackoverflow.com

이상 RTL로 HOC with React-Hooks 테스트 작성하기에 대한 포스팅이었습니다.

물론 상황에 따라 작성하는 방법은 언제든 달라질 수 있겠지만, 테스트를 하는 목적과 의도가 명확하다면 코드를 작성하는데에 있어서 큰 어려움은 없을 것 같습니다.

수정되어야 하거나 개선되어야 할 부분이 있다면 언제든 코멘트로 남겨주세요 :D

감사합니다!

esModuleInterop 속성을 이용한 Import 에러 해결

Pewww — Sun, 15 Mar 2020 21:47:09 +0900

함수의 테스트를 진행하다,

import difference from 'lodash/difference';

difference();

의 구문으로 인해

TypeError: difference_1.default is not a function

라는 에러가 발생한 것을 확인했습니다.

이번 포스팅에서는 관련된 내용에 대해 정리해 볼 예정입니다.

lodash에서는 CommonJS 스펙의 require를 사용합니다.

따라서, 위 코드와 같이 CommonJS 모듈을 ES6 모듈 코드베이스로 가져오려고 할 때 문제가 발생합니다.

해당 문제를

// 1
require(~~~);

// 2
import * as ~~~

의 구문을 사용하여 해결할 수도 있지만,

moment ( https://www.npmjs.com/package/moment ) 와 같이, * 를 사용하여 import 하려는 대상의 타입이 Object가 아닌 경우에는 ES6의 모듈 사양에 호환되지 않게 됩니다.

우리는 이 때, tsconfig의 컴파일 옵션 중 --esModuleInterop flag의 수정을 통해 이를 해결할 수 있습니다.

// tsconfig.json - 저의 경우는 jest.tsconfig.json 입니다 :D

{
  "compilerOptions": {
    "module": "commonjs",
    "esModuleInterop": true,
    ...
  },
  ...
}

esModuleInterop 속성이 위의 코드 처럼 true로 설정될 경우, ES6 모듈 사양을 준수하여 CommonJS 모듈을 가져올 수 있게 됩니다.

해당 옵션을 통해 위에서 예시로 들었던 코드는 아래와 같이 트랜스파일링 되며, 그 결과 정상적으로 import 하는 것이 가능해집니다.

// Before
import difference from 'lodash/difference';
difference();

// After
const difference = __importDefault(require('lodash/difference'));
difference();

* 타입스크립트의 Compiler Options에 대한 정보를 좀 더 알고 싶다면

https://www.typescriptlang.org/docs/handbook/compiler-options.html

Handbook - Compiler Options

A very high-level overview of the compiler options in TypeScript

www.typescriptlang.org

해당 링크를 참고하시면 좋을 듯 합니다 :D

포스팅 봐주셔서 감사합니다!

수정되어야 할 부분이 있으면 언제든 코멘트로 남겨주세요~

Jest를 이용한 Reducer 테스트

Pewww — Mon, 9 Mar 2020 23:53:56 +0900

이번에는 Jest를 이용한 Reducer 테스트에 대해 포스팅해보려 합니다.

다만, 테스트를 위한 세팅에 대해서는 따로 설명하지 않을 예정이니 이 점 참고 부탁드립니다.

내용이 간단하여 어려운 점은 없을 것 같습니다 :D

원칙

https://redux.js.org/recipes/writing-tests/#reducers

Redux

# Writing Tests

redux.js.org

"리듀서는 액션을 이전의 상태에 적용한 후 새로운 상태를 반환해야 한다."

함수의 유닛 테스트와 같이 state와 action만 테스트 케이스에 따라 넘겨주고, 변경된 알맞은 값을 반환하는지, 그에 맞게 상태를 잘 변경하는지에 대해 테스트 코드를 작성하면 됩니다.

예시

다만 A 부분에서 현재 액션 생성 함수에 대한 테스트도 진행하고 있는데, 이미 redux-actions를 사용하고 있기 때문에 해당 라이브러리를 믿고 오히려 테스트 케이스를 작성하지 않는 것도 하나의 방법이 될 수 있을 것 같습니다.

redux-mock-store를 활용하여 개선해보기

https://github.com/dmitry-zaets/redux-mock-store

dmitry-zaets/redux-mock-store

A mock store for testing Redux async action creators and middleware. - dmitry-zaets/redux-mock-store

github.com

redux-mock-store는 리덕스의 비동기 액션 생성자와 미들웨어의 테스트를 위한 Mock Store입니다.

위에 링크로 걸어둔 redux.js.org에서도 async action creators에 대한 테스트를 진행할 때 해당 라이브러리를 사용하고 있는 모습을 확인하실 수 있습니다.

실제 공식 예제에서 볼 수 있듯이, (Synchronous actions)

addTodo 액션이 올바른 payload를 반환하는지에 대한 테스트를 진행하는 것을 볼 수 있습니다.

* redux-mock-store는 상태를 업데이트 하지 않고 디스패치에 전달된 작업만 기록하기 때문에, store.dispatch() 구문 실행 후 store.getState()로 변경된 상태를 확인하는 것이 불가능합니다.

해당 라이브러리가 리듀서 관련 로직이 아닌 액션 관련 로직을 테스트하도록 설계되었기 때문에 이는 어쩔 수 없는 부분이 아닌가 생각합니다.

다만, 액션과 리듀서를 결합한 복잡한 테스트의 경우 "redux-actions-assertions"를 참고할 수 있다고 하는데 실제로 사용해 본 적이 없어 설명은 어려울 것 같습니다.. : (

어쨌든, 위의 food.test.ts 테스트 코드 중

해당 부분을 redux-mock-store를 활용하여 아래와 같이 개선이 가능합니다.

설명

실제 redux에서 configureStore함수는 reducer와 store를 연결하고자 할 때 사용합니다.

해당 코드의 역할 역시 동일합니다.

기존에는 action creator와 reducer에 대한 테스트 코드가 같은 describe 내에 존재하였습니다.

성격이 다른 케이스들을 분리하는 것이 추후 유지보수를 하기에도 편리할 것 같아 describe 역시 분리하여 테스트 코드를 작성하였습니다.

공식 레포의 예제와 같이 saveFood 작업이 올바른 payload를 반환하는지 테스트합니다.

store.dispatch() 구문을 실행할 때의 action은 인스턴스 내부 배열에 저장되어 실행되기 때문에 getActions() 역시 배열을 반환합니다.

따라서 toEqual Matcher를 사용해 값을 비교하였습니다.

저장된 액션들을 초기화하는 역할을 합니다.

store.getActions() 구문에 대해 각각 비교하는 것이 나을 것 같아 해당 코드를 추가하였습니다.

결과

테스트 커버리지

마치며

Reducer가 순수 함수이기 때문에 테스트 코드를 작성하기 훨씬 수월했던 것 같습니다.

앞으로는 이런저런 테스트 코드 작성 방법과 예제들에 대한 포스팅도 진행해 볼 생각입니다.

수정되어야 할 부분이 있으면 언제든 코멘트로 남겨주세요 :D

react-waypoint를 이용한 Infinite-scrolling 구현

Pewww — Sun, 10 Nov 2019 17:52:31 +0900

들어가며

피드 관련 기능을 개발할 때 Infinite-scrolling을 구현해야 할 일이 있었습니다.

구현할 때 react-waypoint를 활용했었는데, 이번 시간에는 구현 원리와 과정을 설명해볼까 합니다.

react-waypoint: https://github.com/civiccc/react-waypoint

civiccc/react-waypoint

A React component to execute a function whenever you scroll to an element. - civiccc/react-waypoint

github.com

코드

import * as React from 'react';
import {Waypoint} from 'react-waypoint';
import styled from 'styled-components';

interface Props {
  loadMore: () => void;
  threshold?: string;
  hasMore: boolean;
  loader: React.ReactNode | React.ComponentType;
  children: React.ReactNode;
  className?: string;
}

const InfiniteScrollDiv = styled.div`
  padding-top: 35px;
`;

const InfiniteScroll: React.ExoticComponent<Props> = React.memo(({
  loadMore,
  threshold,
  hasMore,
  loader,
  children,
  className
}) => (
  <InfiniteScrollDiv className={className}>
    {children}
    {hasMore && (
      <Waypoint
        onEnter={loadMore}
        bottomOffset={threshold}
      >
        {loader}
      </Waypoint>
    )}
  </InfiniteScrollDiv>
));

export default InfiniteScroll;

InfiniteScroll 컴포넌트의 구조는 다음과 같습니다.

Props부터 설명을 드리자면,

1. loadMore

데이터를 fetch하는 함수입니다.

초기 렌더링 시 데이터를 불러오거나, 스크롤을 내리면서 추가 데이터를 불러와야 할 때 필수로 사용됩니다.

2. threshold (optional)

페이지의 최하단으로부터의 거리입니다.

스크롤이 페이지의 최하단에 닿기 전에 데이터를 미리 불러오고 싶을 때 활용합니다.

만약 threshold를 "200px"라고 설정하면, 스크롤이 페이지 하단에서 200px의 거리에 있을 때 Waypoint 컴포넌트가 onEnter 됐다고 인식합니다.

3. hasMore

불러와야 할 데이터가 더 있는지 판단하는 필드입니다.

값이 false라면, 더 이상 추가적인 데이터가 불러와지지 않습니다.

4. loader

데이터가 불러와지기 전에 사용자에게 보여지는 ReactNode 혹은 ReactComponent 입니다.

로딩중이라는 것을 사용자에게 보여주기 위해 넘겨주는 필드입니다.

5. children

실제로 렌더링될 (사용자의 눈에 보여지는) 요소입니다.

6. className (optional)

스타일 수정을 위해 className이라는 필드 역시 받도록 하였습니다.

다만, 필수적으로 필요하진 않기 때문에 threshold와 동일하게 optional로 설정하였습니다.

이제 실제로 return 되는 JSX 구문을 그림으로 나타내보겠습니다.

동작 1

아직 데이터 fetch가 이루어지지 않았기 때문에, children은 렌더링 되기 전입니다.

따라서, 사용자에게는 loader가 보여지는데 이는 아래 그림과 같습니다.

동작 2

Waypoint가 onEnter 됐으므로, props로 받은 loadMore 함수가 실행됩니다.

실행이 완료되고 children이 렌더링되기 전 까지는 loader가 계속 사용자에게 보여지게 되며, 완료될 시에는 아래 그림의 형태를 띄게 됩니다.

동작 3

이제, 실제 데이터에 따라 렌더링된 요소가 이제 사용자에게 보여집니다.

스크롤을 내리면서 다시 로딩 컴포넌트를 마주쳤을 때, (= Waypoint가 onEnter 됐을 때) 추가 데이터가 fetch되며 결국 Infinite-scrolling이 가능하게 됩니다.

실제 예시

눈으로 확인하시면 이해가 빠르실 듯 하여, InfiniteScroll 컴포넌트를 활용한 피드 컴포넌트를 임의로 제작하였습니다.

예시는 아래에서 보여드리는 사진의 모습과 동일하며, 전체적인 코드는

https://github.com/Pewww/waypoint-infinite-scroll

Pewww/waypoint-infinite-scroll

Implementation of Infinite-Scrolling by using React-Waypoint. - Pewww/waypoint-infinite-scroll

github.com

에서 확인하실 수 있습니다!

첫 렌더링 시

로딩중

추가적인 렌더링 완료 후

마치며

설명이 빈약할 수도 있기 때문에 궁금하신 점이나 수정되어야 할 부분들은 모두 코멘트로 달아주시면 감사하겠습니다!

이상, react-waypoint를 활용한 Infinite-scrolling 구현 포스팅이었습니다.

봐주셔서 정말 감사합니다!

Codility - FrogRiverOne 풀이

Pewww — Tue, 22 Oct 2019 23:20:03 +0900

Lesson4. FrogRiverOne

안녕하세요!

오늘은 Lesson4의 두 번째 문제인 FrogRiverOne에 대해 풀이해보려 합니다.

Question

https://app.codility.com/programmers/lessons/4-counting_elements/frog_river_one/

FrogRiverOne coding task - Learn to Code - Codility

Find the earliest time when a frog can jump to the other side of a river.

app.codility.com

개구리가 강 반대편으로 점프할 수 있는 가장 빠른 시간을 찾아야 합니다.

목적지를 나타내는 X와 각 요소의 범위가 1 ~ X로 이루어진 배열 A가 주어지는데, 배열 A를 탐색하며 1부터 X 까지의 수가 모두 나타났을 때의 index를 반환하면 됩니다.

만약 X가 5, A가 [1, 3, 1, 4, 2, 3, 5, 4] 라고 했을 때, 1부터 5까지의 수가 모두 나타난 배열 A의 index는 6이므로 6을 반환하면 되고, 혹시나 나타나지 않았을 경우에는 -1을 반환하면 됩니다.

Answer

이번에는 자료구조 중 하나인 Set을 활용하여 풀이해보았습니다!

* Set은 중복된 value를 저장하지 않습니다.

1. 새로운 Set 변수 s를 생성합니다.

2. A 배열의 루프를 돌며, s에 값( A[idx] )을 추가합니다.

3. 만약 s의 길이가 X와 같다면, 1 부터 X 까지의 수가 모두 채워졌다는 의미이므로 해당 index를 반환합니다.

-> 배열 A 내의 요소의 범위가 1 ~ X라는 전제가 깔려있기 때문에 가능한 로직입니다!

4. 루프를 돌고 난 뒤에도 index가 반환되지 않았을 경우에는 -1을 최종적으로 반환합니다.

풀이 코드는 아래와 같습니다. ( 시간 복잡도는 O(N) )

function solution(X, A) {
  const s = new Set();
   
  for (let idx = 0, leng = A.length; idx < leng; idx++) {
    const value = A[idx];
    s.add(value);
        
    if (s.size === X) {
      return idx;
    }
  }
    
  return -1;
}

풀이 결과

The End

문제를 이해하고 난 후엔 그리 어렵지 않게 풀 수 있었던 것 같습니다.

다음 시간에는 Lesson4의 세 번째 문제인 MaxCounters에 대해 풀이해보려 합니다.

봐주셔서 감사합니다!

Javascript - 나를 위한 클로저 예제 분석

Pewww — Sun, 28 Jul 2019 03:59:34 +0900

들어가며

var text = 'Hello, ';

function greeting() {
  var name = 'Pewww';
  
  return function() {
    console.log(text + name);
  }
}

var g = greeting();
g(); // 'Hello, Pewww' 출력

예전에도 클로저 예제 분석에 대한 글을 썼었지만, (~~지금은 삭제한 상태~~)

제대로 이해하지 못한 상태였고, 저 스스로도 확실히 과정이나 결과에 대해 납득하기 어려웠습니다.

계속 그렇게 찝찝한 상태로 있다가 얼마 전, 내용을 다시 정리해보고 싶다는 생각이 들었고,

저번 보다는 좀 더 이해도가 높아졌다고 생각하여 글을 다시 써보려고 합니다.

솔직히 완벽히 이해했다고는 말할 수 없지만, 제가 고민하며 정리한 내용을 보고 다른 분들께서도 이해가 되지 않던, 혹은 풀리지 않던 문제의 실마리가 되었으면 합니다.

다음에 다시 클로저 예제 분석에 대한 글을 쓸 때에는 완벽히 이해한 제 모습을 기대하며, 포스팅 시작해보도록 하겠습니다.

분석

var i;

for (i = 0; i < 5; i++) {
  setTimeout(function() {
    console.log(i);
  }, 0);
}

아마 클로저에 대해 찾아보신 분들은 한 번쯤은 봤을 법한 예제입니다.

모두가 결과물이 0, 1, 2, 3, 4가 출력되는 것이 아닌 5가 5번 출력이 된다고 알고 있지만, 막상 그 결과에 대해 쉽게 납득하기 어려운 분들도 많을 것 입니다.

이해하기 쉽게 그림을 그리며 한 번 설명해보겠습니다.

1. for 루프 시 setTimeout 구문이 실행되며, setTimeout은 콜스택에 쌓인다.

※ setTimeout 내부 익명함수는 Anonymous Function의 약자인 A.F로 축약하여 사용하겠습니다.

1번 과정

2. 웹 API 중 하나인 타이머가 생성되며, 익명함수(A.F)는 Web APIs로 이동합니다.

2번 과정

3. setTimeout이 완료되고 콜스택에서 제거됩니다.

3번 과정

4. 설정한 타이머가 지난 후 익명함수(A.F)는 콜백 큐로 이동됩니다.

타이머를 0으로 설정했지만, 실제로는 최소 4ms가 지난후에야 콜백 큐로 이동된다고 합니다!

4번 과정

5. 이 작업이 5번 반복되고, for 루프는 종료됩니다. (- 콜백 큐에는 5개의 익명함수가 차례로 쌓인 상태입니다.)

5번 과정

6. 루프가 모두 종료되어 현재 콜스택이 비어있는 상태이므로, 이벤트 루프는 콜백큐의 익명함수를 하나씩 콜스택으로 올립니다.

6번 과정

7. 익명함수가 실행됩니다.

이해를 돕기 위해 선행적으로 알아야 하는 개념을 말씀드리자면,

1. 함수는 선언될 때 스코프가 생성되며, 우리는 이것을 렉시컬 스코핑이라고 한다.

var name = 'Hello';

function showName() {
  // 함수는 선언될 때 스코프가 생성됩니다.
  // 따라서 console 구문에서의 name은 전역에 선언된 name(= 'Hello')를 가리킵니다.
  console.log(name);
}

function callShowName() {
  var name = 'Bye';
  // 만약 name = 'Bye'의 구문이었다면, 전역 변수 name의 값이 'Bye'로 바뀌기 때문에
  // showName 함수를 호출 했을 때, 콘솔은 'Hello'가 아닌 'Bye'를 출력하게 됩니다.
  showName();
}

callShowName(); // 'Hello' 출력

위의 예제에서 'Bye'가 아닌 'Hello'가 출력되는 이유 역시 렉시컬 스코핑 때문이며, 이에 따라 함수의 스코프 체인 역시 선언 시에 결정됩니다.

2. 함수는 호출될 때, 컨텍스트가 생성된다.

함수는 호출될 때, 함수 실행 컨텍스트가 생성됩니다.

이에 따라 활성 객체가 만들어지는데, 쉽게 말해 해당 컨텍스트에서 실행에 필요한 여러 정보들이 담긴 자바스크립트 객체라고 생각하시면 됩니다.

크게, 변수 객체(Variable Object), 스코프 체인(Scope Chain), this의 프로퍼티들로 나뉘어 지는데 앞으로 V.O, S.C, this로 축약하여 설명 이어가도록 하겠습니다.

함수가 호출되기 전 생성되는 전역 실행 컨텍스트를 먼저 살펴보자면 다음과 같이 나타낼 수 있습니다.

전역 실행 컨텍스트

arguments는 없는 상황이고, i라는 변수가 등록되어 있습니다.

스코프 체인은 전역 변수 객체가 연결되어 있으며, this는 window를 가리킵니다.

그럼 이제 실제 익명함수가 호출되었을 때의 함수 실행 컨텍스트를 살펴볼까요?

함수 실행 컨텍스트

arguments와 variable 모두 없는 상황이고 this는 여전히 window를 가리키고 있습니다.

스코프 체인은 자기 자신 (= 익명 함수의 변수 객체)과 전역 변수 객체가 연결 되어 있습니다.

익명 함수가 실행될 때, 콘솔에 i를 출력하려 합니다.

하지만, 자신의 변수 객체에 i라는 프로퍼티를 찾을 수 없는 상황입니다.

그럼 그냥 undefined를 출력할까요?

아닙니다.

스코프 체인으로 전역 변수 객체가 연결되어 있기 때문에, 우리는 보다 상위 스코프인 전역 스코프를 탐색할 수 있습니다.

(우리는 이것을 스코프 체이닝이라고 부릅니다.)

탐색 시, i를 성공적으로 찾았는데 문제는 for 루프가 모두 돌면서 i는 이미 5로 변화된 상태라는 것 입니다.

따라서, 현재 콜 스택에 있는 익명함수와 콜백 큐에 대기 중인 익명함수는 유감스럽게도 모두 5로 변화된 i를 참조하고 있는 것이죠.

그렇기 때문에, 우리는 0, 1, 2, 3, 4가 콘솔에 출력되길 바랐지만 정작 5가 5번 출력되는 현상을 볼 수 밖에 없던 것 입니다.

그림으로 간단히 나타내보자면, 아마 위와 같은 상황일 것 입니다.

상황

그렇다면, 해결책 중 하나인 IIFE를 적용하면 어떻게 될까요?

IIFE로 해결하기

var i;

for (i = 0; i < 5; i++) {
  (function(j) {
    setTimeout(function() {
      console.log(j);
    }, 0);
  })(i);
}

함수가 선언될 때 스코프가 생성되고 스코프 체인 역시 정해진다고 말씀 드렸었습니다.

따라서, IIFE는 자기 자신 (IIFE의 변수 객체)과 더불어 스코프 체인으로 전역 변수 객체 역시 연결되어 있습니다.

setTimeout 내부 익명함수는 자기 자신(익명 함수의 변수 객체)과 함께, 상위 스코프들인 IIFE와 전역 변수 객체가 연결될 것 입니다.

이제 실제 루프를 돌며, IIFE가 호출되고 IIFE의 컨텍스트 역시 생성이 됩니다.

아까와 다른 점은 i를 j라는 이름의 인자로 받고 있다는 점 인데, 이를 그림으로 나타내보겠습니다.

IIFE 실행 컨텍스트

또한, IIFE 함수가 실행되면 setTimeout 구문 역시 실행되고, 내부의 익명함수가 호출됩니다.

함수가 호출되면, 자연스럽게 컨텍스트가 생성되며 익명함수의 컨텍스트는

익명 함수 실행 컨텍스트

위와 같을 것 입니다.

따라서, 루프가 모두 돌고 나서는 서로 다른 5개의 컨텍스트들이 생성될 것이고,

컨텍스트 내에서, 스코프 체인을 통해 상위 스코프의 변수 객체에 접근 가능한 전체적인 모습을 나타내보면 아마 아래와 같지 않을까 생각합니다.

유기적으로 연결되어 있는 모습

어쨌든, 익명함수가 실행되고 콘솔에 j를 출력하고자 할 때, 아까와 마찬가지로 자신의 변수 객체에 j를 찾을 수 없는 상황입니다.

따라서, 스코프 체이닝으로 바로 윗 단계인 IIFE 스코프를 탐색하게 되고, 해당 변수 객체에서 j를 성공적으로 찾게 되어 체이닝은 종료됩니다.

각 IIFE 컨텍스트 내부 변수 객체에서 j는 0, 1, 2, 3, 4의 값을 가지므로 콘솔에는 우리가 원하던 결과인 0, 1, 2, 3, 4가 출력됩니다.

주의

// 1번
var i;

for (i = 0; i < 5; i++) {
  (function() {
    setTimeout(function() {
      console.log(i);
    }, 0);
  })();
}

// 2번
var i;

for (i = 0; i < 5; i++) {
  setTimeout((
    function(j) {
      console.log(j);
    }
  )(i), 1000);
}

주의할 1번 예제를 보면, IIFE를 실행하는데 i를 넘겨주지 않고 있습니다.

즉, IIFE 컨텍스트 내부 변수 객체는 arguments와 variable 모두 null이 되는 것이죠.

따라서, 실제 setTimeout 내부 익명함수가 실행되어 콘솔에 i를 출력하고자 할 때,

자신의 변수 객체에서는 i를 찾을 수 없으니 상위 스코프인 IIFE 스코프를 탐색하게 되고, 이 곳에서도 찾을 수 없으니 결국은 전역 스코프를 탐색하여 이미 5로 변해버린 i를 참조하게 됩니다.

그리고 2번 예제에서는, setTimeout 내부에서 IIFE를 실행하고 있습니다.

이 경우 함수가 즉시 실행되기 때문에, 콘솔에 원하는 결과가 출력 될 수는 있어도 설정한 timer(1000ms)는 무시됩니다.

정리

함수는 호출할 때 환경(컨텍스트)이 만들어집니다.

함수가 만들어질 때, 그 시점의 환경에 대한 참조를 물고 가는 것을 우리는 클로저라고 합니다.

참조를 물고 가기 때문에, 이미 외부 함수의 생명 주기가 끝났더라도, 내부 함수는 그 외부 함수의 변수를 참조할 수 있게 됩니다.

하나 더 간단한 예시를 들어보겠습니다.

var text = 'Hello, ';

function greeting() { // 외부 함수
  var name = 'Pewww';
  
  return function() { // 내부 함수
    console.log(text + name);
  }
}

var g = greeting();
g(); // 'Hello, Pewww' 출력

위의 코드에서, greeting() 함수는 익명 함수를 반환하고 있습니다.

var g = greeting(); 구문에서 greeting() 함수는 실행된 이후, 실행 컨텍스트 스택에서 제거됩니다.

이에 따라, 변수인 name도 같이 소멸되어 내부 함수의 console 구문에서 name에 대해 접근할 수 없어 보이는데, 실제로 g()를 실행했을 때

콘솔에는 정상적으로 'Hello, Pewww'가 출력됩니다.

위에서 설명했던 내용들을 곱씹어보면, 그다지 이해하기 어렵지 않은 내용일 것 입니다.

greeting() 함수 실행 컨텍스트의 활성 객체는 사라지지 않고 유효하기 때문에 (활성 상태 유지), 외부함수인 greeting이 종료되더라도 내부 익명 함수에서는 name에 대한 접근이 가능하게 됩니다.

(아래는 이해를 돕기 위해 [[Scopes]] 프로퍼티를 찍은 모습입니다.)

[[Scopes]] 프로퍼티

자바스크립트에서 가비지 콜렉터(일명 G.C) 는 참조(Reference)를 바탕으로 동작하는데, 이처럼 클로저에 의해 참조 되고 있으면 가비지 콜렉터는 정상적으로 메모리를 회수하지 못 하게 됩니다.

이 점 때문에, 클로저를 사용할 경우 메모리 누수에 대해 조심해야 한다고 얘기하는 것 이며,

사용 후 참조를 없애주는 것이 중요합니다.

실제 브라우저 상에서 가비지 콜렉터가 동작하는 모습을 간접적으로(?) 확인할 수 있는데, 이 부분에 대해서는 추후 포스팅 해 볼 예정입니다.

마치며

내용을 완벽히 이해하려면, 더욱 폭넓은 지식이 필요하다는 것을 깨달았습니다.

최대한 자세히 내용을 담아보려 했는데, 그러지 못 한 것 같아 아쉬움이 많이 남습니다.

Ps. 저 역시 공부하는 입장이기 때문에, 오해의 소지나 잘못된 내용이 있을 수도 있습니다...

그런 부분들이 존재 할 경우 댓글로 정정해주시면 정말 감사하겠습니다!