ReactJS 서버측 렌더링과 클라이언트측 렌더링

ReactJS 서버측 렌더링과 클라이언트측 렌더링

이제 막 ReactJs에 대해 공부하기 시작했는데, 페이지를 렌더링하는 방법이 서버 측과 클라이언트 측 두 가지라는 것을 알게 되었습니다.그런데 같이 쓰는 방법을 모르겠어요.어플리케이션을 구축하는 방법은 2가지입니까, 아니면 2가지를 병용할 수 있습니까?

함께 사용할 수 있다면 어떻게 해야 할까요?서버측과 클라이언트측에서 같은 요소를 복제할 필요가 있습니까?아니면 이미 렌더링된 서버 측과 접속하지 않고 애플리케이션 정적 부분을 서버에, 동적 부분을 클라이언트 측에 각각 구축할 수 있을까요?

특정 웹 사이트/웹 응용 프로그램에 대해 클라이언트 측, 서버 측 또는 둘 다 react를 사용할 수 있습니다.

클라이언트 측

여기서는 완전히 React를 실행하고 있습니다.브라우저의 JS.이것은 가장 간단한 설정이며 대부분의 예(http://reactjs.org의 예도 포함)를 포함합니다.서버에 의해 렌더링된 초기 HTML은 플레이스 홀더이며 모든 스크립트가 로드되면 전체 UI가 브라우저에 렌더링됩니다.

서버측

리액트를 생각하다여기서 JS는 서버측 템플릿 엔진(옥, 핸들바 등)으로 사용됩니다).서버에 의해 렌더링된 HTML에는 UI가 그대로 포함되어 있으며 스크립트가 로드될 때까지 기다리지 않습니다.검색 엔진으로 페이지를 인덱싱할 수 있습니다(javascript를 실행하지 않는 경우).

UI가 서버에 렌더링되기 때문에 이벤트 핸들러가 작동하지 않고 대화식(정적 페이지)이 없습니다.

둘다요.

여기서 초기 렌더는 서버에 있습니다.따라서 브라우저가 수신한HTML은 UI를 그대로 가지고 있습니다.스크립트가 로드되면 가상 DOM이 다시 렌더링되어 구성 요소의 이벤트 핸들러를 설정합니다.

DOM( React)을. 컴포넌트가 같은 JS를 props이치노않으면 " " " " 는 서버 측 DOM이하지 않는다고 합니다.서버측과 클라이언트측의 가상 DOM이 일치하지 않는다고 JS가 불평합니다.

리액트 이후JS는 리렌더 간에 가상 DOM을 구분합니다.실제 DOM은 변환되지 않습니다.이벤트 핸들러만이 실제 DOM 요소에 바인드 됩니다.

이미지 소스:Walmart Labs 엔지니어링 블로그

NB: SSR(Server Side Rendering), CSR(Client Side Rendering).

SSR의 주요 차이점은 클라이언트 브라우저에 대한 서버 응답에 렌더링할 페이지의 HTML이 포함된다는 것입니다.SSR를 사용하면 페이지가 더 빨리 렌더링됩니다.JS 파일이 다운로드되고 브라우저가 React를 실행할 때까지 이 페이지는 사용자 상호 작용 준비가 되지 않습니다.

한 가지 단점은 SSR TTFB(Time to First Byte)가 약간 길어질 수 있다는 것입니다.서버가 HTML 문서를 작성하는 데 시간이 걸리고, 결과적으로 서버 응답 크기가 증가하므로 이해할 수 있습니다.

실제로 같은 조사를 하고 싶다고 생각하고 있었습니다만, 코멘트에 회답이 기재되어 있습니다만, 좀 더 명확해져야 할 것 같아서 이 투고를 하고 있습니다(적어도 아키텍처적으로 문제가 있다고 판단되면, 보다 좋은 방법을 생각해 낼 수 있으면 갱신하겠습니다).

두 가지 방법을 모두 고려하여 컴포넌트를 작성해야 합니다.기본적으로,if는 클라이언트 또는 서버 중 어느 쪽에 있는지 판단하고 DB 쿼리(또는 서버에서 적절한 것) 또는 REST 콜(클라이언트) 중 하나를 수행합니다.그런 다음 데이터를 생성하고 클라이언트에 노출하는 엔드포인트를 작성해야 합니다.

더 깨끗한 솔루션에 대해 알게 되어 기쁩니다.

어플리케이션을 구축하는 방법은 2가지입니까, 아니면 2가지를 병용할 수 있습니까?

함께 사용할 수 있습니다.

함께 사용할 수 있다면 어떻게 해야 할까요?서버측과 클라이언트측에서 같은 요소를 복제할 필요가 있습니까?아니면 이미 렌더링된 서버 측과 접속하지 않고 애플리케이션 정적 부분을 서버에, 동적 부분을 클라이언트 측에 각각 구축할 수 있을까요?

리플로우 및 재도장 작업을 피하기 위해 동일한 레이아웃을 렌더링하는 것이 좋습니다. 깜박임이나 깜박임이 줄어들면 페이지가 더 부드러워집니다.하지만, 그것은 제한이 아닙니다.SSR html(응답 시간을 줄이기 위해 전극이 수행하는 작업)을 캐시하거나 CSR(클라이언트 측 렌더)에 의해 덮어쓰기되는 정적 html을 전송할 수 있습니다.

SSR로 시작하는 경우 단순하게 시작하는 것이 좋습니다. SSR은 매우 빠르게 복잡해집니다.서버에 html을 구축하려면 window, 문서(클라이언트에 있는 것) 등의 오브젝트에 대한 접근권이 상실되고 비동기 조작을 통합할 수 없게 되며(즉석에서 사용 가능한), 일반적으로 코드 SSR 호환성을 얻기 위해 많은 코드를 편집해야 합니다(webpack을 사용하여 번들.js를 패키징해야 합니다).CSS Import, require vs import와 같은 것이 갑자기 당신을 깨물기 시작합니다(이것은 웹 팩이 없는 기본 React 앱에서는 해당되지 않습니다).

SSR의 일반적인 패턴은 다음과 같습니다.요청을 처리하는 Express 서버:

const app = Express();
const port = 8092;

// This is fired every time the server side receives a request
app.use(handleRender);
function handleRender(req, res) {
    const fullUrl = req.protocol + '://' + req.get('host') + req.originalUrl;
    console.log('fullUrl: ', fullUrl);
    console.log('req.url: ', req.url);

    // Create a new Redux store instance
    const store = createStore(reducerFn);

    const urlToRender = req.url;
    // Render the component to a string
    const html = renderToString(
        <Provider store={store}>
            <StaticRouter location={urlToRender} context={{}}>
                {routes}
            </StaticRouter>
        </Provider>
    );
    const helmet = Helmet.renderStatic();

    // Grab the initial state from our Redux store
    const preloadedState = store.getState();

    // Send the rendered page back to the client
    res.send(renderFullPage(helmet, html, preloadedState));
}

SSR로 시작하는 사람들에게 제안할 수 있는 것은 static html을 제공하는 것입니다.CSR SPA 앱을 실행하면 static html을 얻을 수 있습니다.

document.getElementById('root').innerHTML

SSR를 사용하는 유일한 이유는 다음과 같습니다.

1. SEO
2. 고속 로드(할인 가능)

Hack : https://medium.com/ @gagan_goku / vpa-and-server-side-vpa-444d8c48abfc

언급URL : https://stackoverflow.com/questions/27290354/reactjs-server-side-rendering-vs-client-side-rendering