Ist es notwendig, serverseitiges Rendering zu verwenden, um Javascript zu verstehen?

Tutorial zum Javascript-LernenIn der Spalte wird erläutert, ob serverseitiges Rendering verwendet werden soll.

Vorwort

Vor einiger Zeit habe ich ein serverseitiges React-Rendering-Projekt gestartet, das hauptsächlich vom Szenario abhängt.

Es eignet sich besser für SEO und First-Screen-Rendering, die von allen oft erwähnt werden. Im Allgemeinen wird es für das TOC-Geschäft benötigt.

Isomorphismus

Es gibt immer noch viele Unterschiede zwischen dem serverseitigen Rendering moderner Frameworks und JSP und PHP. Da es sich bei nextjs und nuxtjs nicht nur um serverseitiges Rendering handelt, handelt es sich auch um isomorphe Frameworks.

Was ist Isomorphismus? Das heißt, ein Code kann sowohl im Browser als auch auf dem Server ausgeführt werden. Dies liegt an der Beliebtheit von NodeJS auf der Serverseite.

Traditionelle serverseitige Rendering-Frameworks wie JSP, PHP und Django geben alle HTML-Strings zurück, ähnlich dem traditionellen MPA-Mehrseitenmodus. Daher wird beim Seitenwechsel eine Aktualisierung durchgeführt und die CSS- und JS-Dateien werden erneut angefordert, was zu einer schlechten Benutzererfahrung führt.

Das derzeit beliebte Front-End-Entwicklungsmodell ist SPA Single Page, das auf dem H5-Verlauf basiert und Seiten ohne Aktualisierung wechseln kann, was zu einer besseren Benutzererfahrung führen kann.

Nextjs und nuxtjs unterstützen also nicht nur das serverseitige Rendern, sondern auch SPA. Es wird häufig zum Rendern der Homepage auf der Serverseite verwendet, und andere Seiten behalten weiterhin den Nicht-Aktualisierungs-Zugriffsmodus von SPA bei.

Wir haben Seiten, die mit Django geschrieben wurden, was sehr mühsam zu pflegen ist. Denn es lässt sich nicht eindeutig sagen, wer für das Frontend und wer für das Backend zuständig ist. Um dies aufrechtzuerhalten, müssen sowohl das Front-End als auch das Back-End Python und Django erlernen, was die Wartungskosten erheblich erhöht.

In Bezug auf tatsächliche Anwendungsszenarien gibt es mehrere Szenarien, in denen serverseitiges Rendering besser geeignet ist.

Support-Post-Anfrage

Eine davon ist eine rekonstruierte h5-Seite. Das Projekt wurde zuvor von einem singapurischen Team mit Python + Django geschrieben, daher werden einige Seiten von Drittanbieter-Websites mit Post-Einreichungsformularen geöffnet.

Unsere rekonstruierten H5-Seiten hängen alle im Tencent Cloud CDN und können nicht mit Post geöffnet werden. Warum ändern Sie es nicht in „Get“? Denn dies war eine Vereinbarung, die sie zuvor getroffen hatten, und die Banken sind allesamt Väter, daher werden sie die Vereinbarung nicht für uns ändern.

Die Seitenfunktionen sind relativ einfach. Um mit dem Zeitrahmen für die Rekonstruktion Schritt zu halten, implementierte mein damaliger Freund neben mir eine Version mit Express + EJS, die nur die ES5-Syntax unterstützte. 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__

Die nachfolgenden Anforderungen wurden mehrfach geändert und es ist mühsam, der Originalseite Funktionen hinzuzufügen. Wenn ich beispielsweise JS Bridge implementieren möchte, kann ich nur Microbundle verwenden, um das vorhandene NPM-Paket in eine UMD-Datei zu packen und es dann mithilfe des Skript-Tags zu importieren.

Dynamisches Rendern von Titeln

Ich bin vor einiger Zeit auf eine andere Anforderung gestoßen, als ich dieselbe H5-Seite für mehrere Banken implementieren musste. Die Funktionen sind grundsätzlich gleich, aber die Namen verschiedener Banken müssen angezeigt werden der App-Header. Wenn der Kunde in unserer AirPay-App die Webansicht öffnet, liest er den Titel in unserem HTML und legt ihn als Titel des nativen Headers fest.

Wenn ich document.title im Code verwende, wird die dynamische Einstellung nicht wirksam. Ich kann den Header nur dynamisch über JS Bridge festlegen.

Aber diese Seite wird nicht nur von AirPay verwendet, sondern auch von Shopee bereitgestellt. Sie muss mit zwei Sätzen von JS Bridge kompatibel sein, was den Gewinn etwas überwiegt.

Aber wenn Sie die serverseitige Direktausgabemethode verwenden, können Sie den Titel, der auf der Serverseite gerendert werden muss, direkt bestimmen und im HTML-Titel festlegen. Dies ist ein weiteres geeignetes Geschäftsszenario.

Basierend auf dem vorherigen Projekt wurde die serverseitige Rendering-Funktion React hinzugefügt, um die Entwicklung isomorpher Anwendungen mit React zu unterstützen. Next wird hier nicht verwendet, sondern nur eine Reihe von Isomorphismen, die ich selbst implementiert habe. 🎜🎜Die allgemeine Implementierungsidee besteht darin, Isomorphic-Style-Loader und Universal-Router zu verwenden, um den Isomorphismus von Stilen und Routen zu verarbeiten. Der Server erhält die Daten und gibt sie an window._INITIAL_STATE__ aus Die Initialisierungsdaten des Browsers erreichen Datenisomorphismus. 🎜🎜Gleichzeitig bleiben die ursprünglichen EJS-Vorlagen erhalten, die auf Basis von Express-Routing verteilt werden. Sie können mit EJS gerendert oder direkt vom React-Server exportiert werden. 🎜🎜Diese Seite hängt in der ersten Phase im Tencent Cloud CDN. In der zweiten Phase ist die Ladegeschwindigkeit deutlich höher. Immerhin wird vorher noch ein Ladebild angezeigt . 🎜🎜In Bezug auf die Prozessüberwachung werden die Node-Dienste der gesamten Abteilung mithilfe von Node-Agenten ausgeführt, die von großen Chefs geschrieben wurden, und sie haben den Test verschiedener großer Werbeaktionen überstanden. 🎜🎜🎜🎜Nachteile 🎜🎜🎜🎜Natürlich sollte serverseitiges Rendering nicht missbraucht werden. 🎜🎜Zum Beispiel wird unser internes Backend-Managementsystem von Nuxt unterstützt. Jetzt dauert jeder lokale Build 10 Minuten, was sich stark auf die Entwicklungseffizienz auswirkt. 🎜🎜Nuxt verfügt über sehr leistungsstarke Funktionen, wie z. B. das dynamische Aufteilen von Build-Dateien basierend auf dem Routing, das Vorladen von JS-Dateien, wenn die Maus auf der Nuxt-Link-Routing-Komponente platziert wird, usw. 🎜

Aber der tatsächliche Nutzen ist nahezu gleich Null, da wir kein SEO benötigen und die Ladegeschwindigkeit des ersten Bildschirms nicht verbessern müssen.

Fast jeder im Team hat verschiedene Mittel ausprobiert, um den Build zu optimieren, aber der Effekt ist nicht sehr offensichtlich. Erst als wir vor kurzem damit begannen, Micro-Frontends aufzuteilen, konnten wir dieses Problem lösen.

Darüber hinaus ist serverseitiges Rendering auch anders geschrieben als clientseitiges Rendering, was leicht zu Fehlern führen kann.

Zum Beispiel der folgende Code in der Vuex-Statusdatei:

const date = moment().format('YYYY-MM-DD')
export default () => ({  
date
})

Beim Öffnen der Seite sollte die heutige Uhrzeit angezeigt werden. Auch wenn die Seite am anderen Ende des Himmels platziert ist, sollte sie immer noch am selben Tag sein, wenn Sie sie öffnen und aktualisieren.

Aber in Nuxt ist das angezeigte Datum das Datum, an dem Ihr Dienst gestartet wird, egal wie Sie es aktualisieren, es wird sich nie ändern.

Da Nuxt diese Daten bei der Initialisierung im Store speichert, wird diese Datei nicht erneut auf den Server geladen, da das Modul von Node zwischengespeichert wird, sodass das Datum nicht aktualisiert wird.

Aber beim clientseitigen Rendern wird dieses Datum ebenfalls neu berechnet, da die Seitenaktualisierung dazu führt, dass der Browser die JS-Datei neu lädt.

Empfohlen (kostenlos): Javascript-Lern-Tutorial

Das obige ist der detaillierte Inhalt vonIst es notwendig, serverseitiges Rendering zu verwenden, um Javascript zu verstehen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!