next 보일러 플레이 pankod 분석하기

Next + Redux + Enzyme + Typescript 보일러플레이트를 찾다가, 발견한 프로젝트인데 구조를 살펴보면서 또 한없이 모자람을 느껴 한번 쓱 훑어보기로 했다.

 

다음과 같은 것이 구성되어 있다.

 

 

.
├── app
│   ├── proxy.js
│   ├── routes.js
│   └── server.js
├── documentation
├── pages
│   ├── _app.tsx
│   ├── _document.tsx
│   ├── home
│   │   ├── index.scss
│   │   ├── index.spec.tsx
│   │   └── index.tsx
│   └── index.ts
├── project-cli
├── src
│   ├── Actions
│   │   ├── HomeActions.spec.tsx
│   │   ├── HomeActions.ts
│   │   └── index.ts
│   ├── Components
│   │   ├── Heading
│   │   │   ├── index.spec.tsx
│   │   │   ├── index.tsx
│   │   │   └── style.scss
│   │   └── index.ts
│   ├── Definitions
│   │   ├── ActionConsts.ts
│   │   └── index.ts
│   ├── Interfaces
│   │   ├── Components
│   │   │   └── Heading.d.ts
│   │   ├── Pages
│   │   │   ├── App.d.ts
│   │   │   └── Home.d.ts
│   │   ├── Redux
│   │   │   ├── Action.d.ts
│   │   │   └── Store.d.ts
│   │   ├── Services
│   │   │   └── API
│   │   │       ├── Http.d.ts
│   │   │       └── Planetary
│   │   │           ├── ApodPayload.d.ts
│   │   │           ├── ApodResponse.d.ts
│   │   │           └── Planetary.d.ts
│   │   └── index.ts
│   ├── Redux
│   │   ├── Reducers
│   │   │   ├── home.spec.ts
│   │   │   ├── home.ts
│   │   │   └── index.ts
│   │   └── store.ts
│   └── Services
│       ├── API
│       │   ├── Http.spec.ts
│       │   ├── Http.ts
│       │   ├── Planetary.spec.ts
│       │   └── Planetary.ts
│       └── index.ts
├── tsconfig.json
├── tslint.json
├── jest.config.js
├── jest.setup.ts
├── jest.tsconfig.json
├── next.config.js
├── package-lock.json
└── package.json
 

< 다음과 같은 디렉토리로 구성되어 있다. >

App

앱의 서버를 담당하고 있다.

proxy

문자열로 된 객체를 반환하는데, 그 안에는 나사api와 관련된 url와 같은 것이 존재한다.

routes

page에 대응되는 route를 담당하고 있다.

server.js

특별한 점이 있다면 proxy.js 에서 만든 모듈을 이용해서 리버스 프록시를 하는 점이다.

    if (process.env.PROXY_MODE === 'local') {
        const proxyMiddleware = require('http-proxy-middleware');
        Object.keys(devProxy).forEach(function(context) {
            server.use(proxyMiddleware(context, devProxy[context]));
        });
    }

Document

앱의 문서 담당인데 md 이나 site의 confing등이 있다. 앱에 직접적인 영향을 미치지는 않는 것 같다.

(실제로 삭제했지만 큰 문제는 없다)

Pages

next의 페이지를 담당하는 디렉토리이다.

 

이 때 컴포넌트 생성 관련해서 인터페이스를 사용한 점이 낯설다.

import App, { Container, NextAppContext } from 'next/app';
import * as React from 'react';
import { Provider } from 'react-redux';
import withRedux from 'next-redux-wrapper';
import store from '@Redux/store';
import { IApp } from '@Interfaces';
 
class MyApp extends App<IApp.IProps> {
    static async getInitialProps(props: NextAppContext) {
        let pageProps = {};
 
        if (props.Component.getInitialProps) {
            pageProps = await props.Component.getInitialProps(props.ctx);
        }
 
        return { pageProps };
    } // getInitialProps를 모두 하나로 모음
 
    render(): JSX.Element {
        const { Component, pageProps, store } = this.props;
 
        return (
            <Container>
                <Provider store={store}>
                    <Component {...pageProps} />
                </Provider>
            </Container>
        );
    }
}
 
export default withRedux(store)(MyApp);
 

MyApp은 next에 있는 App을 상속받는다.

App을 살펴보면 App 역시 React.Component를 상속받는다.

그렇기 때문에 next 컴포넌트가 React.Component를 상속받고 있는 것과 같은데, 추가적으로 Next 컴포넌트에서 넘어오는 props가 추가된다(Component, pageProps)

 

App은 props와 state를 각각 가지는데 이를 제네릭으로 표현했다.

//#region Global Imports
import { Props } from 'prop-types';
//#endregion Global Imports
 
//#region Interface Imports
import { IStore } from '@Interfaces/Redux/Store';
//#region Interface Imports
 
declare namespace IApp {
    export interface IProps extends Props<{}> {
        store: IStore;
    }
 
    export interface IState {}
}
 

커스텀 페이지

import * as React from 'react';
import { connect } from 'react-redux';
import { bindActionCreators, Dispatch } from 'redux';
import { IHomePage, IStore } from '@Interfaces';
import { Heading } from '@Components';
import { HomeActions } from '@Actions';
 
export class HomePage extends React.Component<IHomePage.IProps, IHomePage.IState> {
    constructor(props: IHomePage.IProps) {
        super(props);
    }
 
    public render(): JSX.Element {
        return (
            <div className="title">
                Hello!
                <Heading text="World!" />
            </div>
        );
    }
}
 
const mapStateToProps = (state: IStore) => state.home;
 
const mapDispatchToProps = (dispatch: Dispatch) => ({
    Map: bindActionCreators(HomeActions.Map, dispatch),
});
 
export default connect(
    mapStateToProps,
    mapDispatchToProps,
)(HomePage);
 

다른 페이지 역시 비슷한 양상을 보인다.

이 때 재밌는 점은 store 인터페이스와 Dispatch 인터페이스이다.

Dispatch 인터페이스와 같은 경우에는 redux에서 주어져 있고

store 인터페이스는 Interface/Redux/Store에 직접 구현되어 있다.

import { IHomePage } from '@Interfaces';
 
export interface IStore {
    home: IHomePage.IStateProps;
}
 

src

Redux와 Component Util들을 포함한 디렉토리이다.

 

Component는 특별한 것이 없다.

 

Interface

// PAGE INTERFACES
export { IApp } from '@Interfaces/Pages/App.d.ts';
export { IHomePage } from '@Interfaces/Pages/Home.d.ts';
 
// COMPONENT INTERFACES
export { IHeading } from '@Interfaces/Components/Heading.d.ts';
 
// REDUX INTERFACES
export { IStore } from '@Interfaces/Redux/Store.d.ts';
export { IAction } from '@Interfaces/Redux/Action.d.ts';
 
//SERVICES INTERFACES
export { HttpModel } from '@Interfaces/Services/API/Http.d.ts';
export { PlanetaryModel } from '@Interfaces/Services/API/Planetary/Planetary';
export { ApodPayload } from '@Interfaces/Services/API/Planetary/ApodPayload';
export { ApodResponse } from '@Interfaces/Services/API/Planetary/ApodResponse';
 

디렉토리를 가진 모든 파일이 그렇지만 Index에 나머지 디렉토리를 모아두는 것이 인상적이다.

인터페이스를 가지는건

Component Pages Redux(Action,Store) Service

 

Actions

import { Dispatch } from 'redux';
 
import { ActionConsts } from 'src/RDefinitions';
import { PlanetaryService } from '@Services';
 
import { IHomePage } from '@Interfaces';
 
export const HomeActions = {
    Map: (payload: {}) => ({
        payload,
        type: ActionConsts.Home.SetReducer,
    }),
 
    Reset: () => ({
        type: ActionConsts.Home.ResetReducer,
    }),
 
    GetApod: (payload: IHomePage.Actions.IGetApodPayload) => async (dispatch: Dispatch) => {
        const result = await PlanetaryService.GetPlanetImage({
            params: payload.params,
        });
 
        dispatch({
            payload: {
                image: result,
            },
            type: ActionConsts.Home.SetReducer,
        });
    },
};
 

Home과 관련된 액션이다. 필요에 따라 받는 payload의 타입을 정확히 지정해줬다.

이제 보니 thunkMiddleware를 사용중인거 같다.

Service

이번 포스팅의 가장 재밌는 부분이다.

import 'isomorphic-unfetch';
import getConfig from 'next/config';
import { stringify } from 'query-string';
import { HttpModel } from '@Interfaces';
/**
 * @module Http
 */
 
const {
    publicRuntimeConfig: { API_KEY, API_URL },
} = getConfig();
 
const BaseUrl = `${API_URL}/api`;
 
export const Http = {
    Request: async <A>(
        methodType: string,
        url: string,
        params?: HttpModel.IRequestQueryPayload,
        payload?: HttpModel.IRequestPayload,
    ): Promise<A> => {
        return new Promise((resolve, reject) => {
            const query = params ? `?${stringify({ ...params, api_key: API_KEY })}` : '';
 
            fetch(`${BaseUrl}${url}${query}`, {
                body: JSON.stringify(payload),
                cache: 'no-cache',
                headers: {
                    'content-type': 'application/json',
                },
                method: `${methodType}`,
            })
                .then(async response => {
                    if (response.status === 200) {
                        return response.json().then(resolve);
                    } else {
                        return reject(response);
                    }
                })
                .catch(e => {
                    reject(e);
                });
        });
    },
};
 

Http라는 모듈이 직접 만들어져 있다.

리턴값으로 <A> 라는 뭔가가 담긴 Promise를 리턴하게 되는데

Promise는 제네릭이 필수적이라 만약 기대하는 제네릭이 없다면 async 앞에 저런식으로 붙혀줘야 한다.

 

다음에는 마저 각종 설정 파일들을 조사해보자