자바스크립트를 이해하려면 서버 측 렌더링을 사용해야 합니까?
- coldplay.xixi앞으로
- 2020-11-23 17:54:093889검색
Javascript 학습 튜토리얼이 칼럼에서는 서버사이드 렌더링 사용 여부를 소개합니다.
머리말
A 얼마 전에 React 서버사이드 렌더링 프로젝트를 시작했는데, 이것을 사용해야 할지 여부는 주로 시나리오에 따라 다릅니다.
누구나 자주 언급하는 SEO와 첫 화면 렌더링에 더 적합합니다. 일반적으로 TOC 비즈니스에 필요합니다.
동형화
최신 프레임워크의 서버 측 렌더링과 jsp 및 php 사이에는 여전히 많은 차이점이 있습니다. nextjs와 nuxtjs는 단순한 서버 측 렌더링이 아니기 때문에 동형 프레임워크이기도 합니다.
동형성이란 무엇인가요? 즉, 코드 조각이 브라우저와 서버 모두에서 실행될 수 있습니다. 이는 서버 측에서 NodeJS의 인기 때문입니다.
jsp, php, django와 같은 기존 서버 측 렌더링 프레임워크는 모두 기존 MPA 다중 페이지 모드와 유사하게 html 문자열을 반환합니다. 따라서 페이지를 전환하면 페이지가 새로 고쳐지고 CSS 및 js 파일이 다시 요청되어 사용자 경험이 저하됩니다.
현재 인기 있는 프런트 엔드 개발 모델은 SPA 단일 페이지입니다. 이는 H5 기록을 기반으로 새로 고침 없이 페이지를 전환하여 더 나은 사용자 경험을 제공할 수 있습니다.
그래서 nextjs와 nuxtjs는 서버 측 렌더링뿐만 아니라 SPA도 지원합니다. 일반적으로 홈페이지에서 서버 측 렌더링을 수행하는 데 사용되며 다른 페이지는 여전히 SPA의 비새로 고침 액세스 모드를 유지합니다.
Django를 사용하여 작성된 페이지가 있는데 이는 유지 관리가 매우 어렵습니다. 어느 것이 프론트엔드를 담당하고 어느 것이 백엔드를 담당하는지 명확하게 알 수 없기 때문입니다. 그래서 이를 유지하기 위해서는 프론트엔드와 백엔드 모두 Python과 Django를 배워야 하는데, 이는 유지관리 비용을 크게 증가시킵니다.
실제 애플리케이션 시나리오 측면에서 서버 측 렌더링에 더 적합한 몇 가지 시나리오가 있습니다.
지원 게시물 요청
One은 재구성된 h5 페이지입니다. 이 프로젝트는 이전에 Python + Django를 사용하여 싱가포르 팀이 작성했기 때문에 일부 페이지는 타사 웹사이트 게시물 제출 양식으로 열립니다.
재구성된 H5 페이지는 모두 Tencent Cloud CDN에 걸려 있으며 Post로 열 수 없습니다. Get으로 바꾸면 어떨까요? 왜냐하면 이것은 그들이 이전에 맺은 합의였고, 은행은 모두 아버지이기 때문에 우리를 위해 그 합의를 바꾸지 않을 것이기 때문입니다.
페이지 기능이 비교적 간단해서 재구성 타임라인을 따라잡기 위해 당시 옆 친구가 ES5 구문만 지원하는 Express + EJS를 사용하는 버전을 구현했습니다. Express + EJS 实现了一版，只支持 ES5 的语法。
后续需求经历几次变更，想在原来的页面上加功能都比较麻烦。比如我想实现 JS Bridge，我只能用 microbundle 把现有的 npm 包打成一个 umd 文件，然后用 script 标签引入。
动态渲染标题
前阵子遇到了另一个需求，我需要为多家银行实现同样的 H5 页面，功能基本上都是一样的，但 App 头部需要展示不同银行的名字。
在我们 AirPay App 里面，客户端在打开 webview 的时候会去读取我们 HTML 里面的 title，将其设置为原生头部的标题。
如果我在代码里面使用 document.title 的方式动态设置就不会生效，只能通过 JS Bridge 来动态设置头部。
但这个页面不仅会提供给 AirPay 使用，还会提供給 Shopee 使用，需要兼容两套 JS Bridge，有点儿得不偿失。
但如果使用服务端直出的形式，就可以在服务端直接判断好需要渲染的标题，设置到 HTML 的 title 里面。这就是另一种适合的业务场景了。
所以在之前项目基础上添加了 React 服务端渲染的功能，支持用 React 开发同构应用。这里也没有用 Next，只是自己实现的一套同构。
大致实现思路是用 isomorphic-style-loader 和 universal-router 来处理样式和路由的同构，服务端获取到数据后输出到 window._INITIAL_STATE__
얼마 전에 여러 은행에 대해 동일한 H5 페이지를 구현해야 하는 경우가 있었습니다. 기능은 기본적으로 동일하지만 다른 은행의 이름을 표시해야 합니다. 앱 헤더. AirPay 앱에서 클라이언트가 webview를 열면 HTML의 제목을 읽고 이를 기본 헤더의 제목으로 설정합니다.
코드에서document.title을 사용하면 동적 설정이 적용되지 않고 JS Bridge를 통해서만 헤더를 동적으로 설정할 수 있습니다. 하지만 이 페이지는 AirPay뿐만 아니라 Shopee에서도 제공됩니다. JS Bridge 두 세트와 호환되어야 하는데, 이는 이득보다 약간 더 중요합니다. 하지만 서버사이드 직접 출력 방식을 사용하면 서버사이드에서 렌더링해야 할 제목을 직접 판단하여 HTML 제목에 설정할 수 있습니다. 이는 또 다른 적합한 비즈니스 시나리오입니다. 그래서 이전 프로젝트를 기반으로 React를 이용한 동형 애플리케이션 개발을 지원하기 위해 React 서버 측 렌더링 기능을 추가했습니다. Next는 여기서 사용되지 않고 단지 내가 구현한 동형 집합입니다. 🎜🎜일반적인 구현 아이디어는 isomorphic-style-loader와 universal-router를 사용하여 스타일과 경로의 동형을 처리하는 것입니다. 서버는 데이터를 가져와 window._INITIAL_STATE__에 출력합니다. 브라우저 초기화 데이터는 데이터 동형성을 달성합니다. 🎜🎜동시에 Express 라우팅을 기반으로 배포되는 원본 EJS 템플릿은 그대로 유지되며 EJS를 사용하여 렌더링하거나 React 서버에서 직접 내보낼 수 있습니다. 🎜🎜첫 번째 단계의 이 페이지는 Tencent Cloud CDN에 걸려 있습니다. 두 번째 단계에서는 서버 측 렌더링이 사용됩니다. 결국 로딩 속도가 훨씬 빨라진 것을 느낄 수 있습니다. . 🎜🎜프로세스 후견 측면에서 부서 전체의 Node 서비스는 대기업이 작성한 Node Agent를 사용하여 수행되며 다양한 주요 프로모션의 테스트를 통과했습니다. 🎜🎜🎜🎜단점 🎜🎜🎜🎜물론, 서버 측 렌더링을 남용해서는 안 됩니다. 🎜🎜예를 들어, 내부 백엔드 관리 시스템은 Nuxt로 구동됩니다. 이제 각 로컬 빌드에는 10분이 걸리며 이는 개발 효율성에 큰 영향을 미칩니다. 🎜🎜Nuxt에는 라우팅을 기반으로 빌드 파일을 동적으로 분할하고, Nuxt-link 라우팅 구성 요소에 마우스를 놓을 때 JS 파일을 미리 로드하는 등의 매우 강력한 기능이 있습니다. 🎜하지만 SEO가 필요 없고, 첫 화면 로딩 속도를 개선할 필요도 없기 때문에 실제 이점은 거의 0에 가깝습니다.
팀의 거의 모든 사람들이 빌드를 최적화하기 위해 다양한 방법을 시도했지만 효과는 그리 뚜렷하지 않습니다. 최근에야 우리는 마이크로 프론트엔드를 분할하기 시작하여 이 문제를 해결했습니다.
또한 서버 측 렌더링도 클라이언트 측 렌더링과 다르게 작성되므로 버그가 발생하기 쉽습니다.
예를 들어 Vuex 상태 파일의 다음 코드는
const date = moment().format('YYYY-MM-DD')
export default () => ({
date
})페이지가 열리면 오늘 시간이 표시되어야 합니다. 페이지가 하늘을 가로질러 배치되더라도 페이지를 열고 새로 고치는 것은 같은 날이어야 합니다.
그러나 Nuxt에서 표시되는 날짜는 서비스가 시작된 날짜입니다. 아무리 새로고침을 해도 변경되지 않습니다.
Nuxt는 초기화될 때 이러한 데이터를 스토어에 저장하기 때문에 나중에 어떻게 새로 고쳐도 이 파일은 Node에 의해 모듈이 캐시되므로 날짜가 업데이트되지 않습니다.
그러나 클라이언트 측 렌더링에서는 페이지 새로 고침으로 인해 브라우저가 JS 파일을 다시 로드하므로 이 날짜도 다시 계산됩니다.
추천(무료): Javascript 학습 튜토리얼
위 내용은 자바스크립트를 이해하려면 서버 측 렌더링을 사용해야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!