풀스택 플러그인 소개

6398 단어 webdev javascript tooling

전체 스택 플러그인은 빌드 파이프라인, 요청의 서버측 렌더링(SSR), 데이터의 서버-클라이언트 핸드오프 및 클라이언트측 렌더링(CSR)에 연결할 단일 통합 지점입니다. 이러한 종류의 플러그인은 사용자에게 두려운 크로스 스택 도구 통합을 위한 드롭인 솔루션을 제공합니다.

배경

현대 웹 개발에 참여하고 있다면(원하든 원하지 않든) 의심할 여지 없이 빌드 플러그인에 익숙할 것입니다. 이를 사용하여 TypeScript를 JavaScript로 변환하거나 CSS 파일을 원활하게 가져올 수 있습니다. 이것은 언어나 브라우저 표준이 허용하는 것보다 더 빠르게 움직일 수 있는 최신 개발자 경험(DX) 도구의 놀라운 일입니다.

Sometimes the ambition of these plugins exceeds the capabilities of the tooling.

하지만 가끔 DX는... '부족'하다고 합시다. 때때로 이러한 플러그인의 야망은 도구의 기능을 초과합니다. 때때로 통합은 문서의 "고급"섹션에서 미로 같은 지침을 성공적으로 탐색하고 이해하는 것을 의미합니다.

이것은 일이 무너지는 곳입니다

styled-components 의 만족스러운 사용자라고 가정해 보겠습니다. SSR(서버측 렌더링) 통합을 채택하기 전까지는 모든 것이 훌륭합니다. 이와 같이 설정하면 다음과 같은 큰 이점이 있습니다.

스타일과 함께 배치된 구성 요소를 작성하기 위한 강력하고 표현력이 풍부한 DX

SSR 중 중요한 CSS 추출

선호하는 모든 도구를 사용하여 CSS 사전 처리

더 나은 검색 엔진 순위 및 짧은 콘텐츠가 있는 첫 번째 페인트 타이밍

이것은 매우 강력한 이점이지만 사전 설정은 약한 마음을 위한 것이 아닙니다. 이것을 설정하려면 여러 가지를 조정해야 합니다.

Configure the babel plugin 귀하의 번들러 뒤 주르에서.

Wire up server-side rendering

요청당ServerStyleSheet 인스턴스를 구성합니다.

앱을 <StyleSheetManager /> 구성 요소로 래핑하고 ServerStyleSheet 인스턴스를 전달합니다.

ServerStyleSheet 인스턴스에서 생성된 스타일 태그를 포함하도록 제공된 HTML을 수정합니다.

꽤 많습니다.

하지만 그건 styled-components '잘못이 아니다. 그것이 바로 지금 우리의 툴링이 작동하는 방식입니다. 빌드 도구가 있고 런타임 도구가 있으며 두 가지가 만나지 않습니다.

동서양을 잇다

그렇다면 이 격차를 어떻게 해소할 수 있을까요? 우리는 번들러와 런타임 간의 관계를 재고하고 두 가지가 서로 대화하도록 해야 합니다.

vite 을 사용한다고 가정해 보겠습니다. 전체 스택 플러그인은 다음과 같습니다.

interface FullStackPlugin extends VitePlugin {
  /**
   * Provide a set of references to server-side plugins.
   * 
   * A server-side plugin can participate in the server-side rendering
   * pipeline and do things like:
   * 
   * - Set up any necessary per-request context (instances).
   * - Wrap the main component in Providers wired up to the context.
   * - Modify the HTML markup for the response.
   * - Modify the HTTP headers for the response
   * - Contribute to the server-to-client hand-off of data.
   */
  getServerRendererPlugins?: () =>
    | MaybeArray<RendererPluginReference>
    | undefined;

    /**
     * Provide a set of references to client-side plugins.
     * 
     * A client-side plugin can participate in the client-side rendering
     * pipeline and do things like:
     * 
     * - Set up any necessary per-request context, having access to that
     *   request's server-to-client handoff data.
     * - Wrap the main component in Providers wired up to the context.
     * - Perform any blocking, asynchronous operations before actually
     *   doing the initial hydration.
     */
  getClientRendererPlugins?: () =>
    | MaybeArray<RendererPluginReference>
    | undefined;
}

/**
 * Describe where to find the code for the runtime plugin, including
 * which export to use (defaults to the default export) and any
 * configuration that needs to be serialized into that plugin at runtime.
 */
interface RendererPluginReference {
  readonly spec: string;
  readonly exportName?: string;
  readonly config: unknown;
}

type MaybeArray<T> = Array<T> | T;

이것이 도서관 저자로서 당신에게 주는 힘을 상상해 보십시오.

다음은 전체 스택 플러그인으로 깔끔하게 해결되는 몇 가지 사용 사례입니다.

styled-components , linaria , twind 등과 같은 도구에 대한 중요한 CSS의 SSR 추출...

react-query를 사용하여 서버측 데이터를 로드하고 해당 데이터의 서버에서 클라이언트로의 전달을 자동으로 설정합니다.

비용이 들지 않는 코드 분할 및 구성 요소, 페이지 및 데이터의 지연 로드.

간단한 SSR/CSR 통합 또는 react-router와 같은 자동 파일 시스템 기반 라우팅을 위한 remix의 심층 통합.

그리고 그것은 빙산의 일각에 불과합니다. 또 무엇을 상상할 수 있습니까?

풀스택 플러그인 소개

배경

이것은 일이 무너지는 곳입니다

동서양을 잇다

관련되어있다

Reference

좋은 웹페이지 즐겨찾기