doc: fix doc
diff --git a/contents/en/basics/release-note/5-5-0.md b/contents/en/basics/release-note/5-5-0.md
index 09f0c10..4652207 100644
--- a/contents/en/basics/release-note/5-5-0.md
+++ b/contents/en/basics/release-note/5-5-0.md
@@ -14,17 +14,21 @@
These changes mean that files like `echarts/core.js` can now be resolved as ESM in environments like pure Node.js, vitest, jest, and create-react-app.
-Please note that if using `"exports"`, the files that are not declared in "exports" will be invisible from outside any more. Also, the path must start with `'.'`.
-
We’ve also ensured that this new feature is compatible with a variety of environments, including runtime (node/vitest/jest(create-react-app)/ssr/…) and bundlers (webpack/rollup/vite/esbuild/…).
We’re excited about this new feature and believe it will significantly improve the developer experience.
## Server-Side Rendering + Lightweight Client Runtime
-Starting from Apache ECharts 5.3, we support a server-side SVG string rendering solution with zero dependencies, which also supports the initial animation of the chart. However, if you need to implement some interactions on the client side, you need to load the complete ECharts, which may increase the page loading time. For some scenarios that require high page loading speed, this may not be an ideal choice.
+Apache ECharts is powerful, but correspondingly, it has a large package size. We have made various efforts to improve this in previous versions. Developers can use TreeShaking to load parts of the code as needed, reducing the amount of code loaded. Starting from Apache ECharts version 5.3, we support a server-side SVG string rendering solution with zero dependencies, and support the initial animation of charts. In this way, using the result of server-side rendering as the first screen rendering can greatly reduce the first screen loading time.
-In version 5.5.0, we added a lightweight client runtime, so the client can implement some interactions without loading the complete ECharts. In this way, we can render the chart on the server side and then load the lightweight runtime on the client side to implement some common interactions. This means that you no longer need to load about 1MB of the complete ECharts package, but only need to load about 4KB of the lightweight runtime. This improvement will greatly improve the page loading speed, especially for the mobile experience.
+Although server-side rendering is an effective solution to reduce the package size, if some interactions need to be implemented on the client side, it is still necessary to load echarts.js, which may increase the loading time. For some scenarios that require faster page loading, this may not be an ideal choice.
+
+In version 5.5.0, we added a lightweight runtime for the client side, so the client does not need to load the full ECharts to implement some interactions. In this way, we can render charts on the server side, and then load the lightweight runtime on the client side to implement some common interactions. This means that only 4KB of lightweight runtime (1KB after gzip) is needed to implement charts with initial animations and some commonly used interaction forms. This improvement will greatly increase the page loading speed, especially for the mobile experience.
+
+
+
+Take this pie chart with a title as an example, if the client only packages the pie chart and title components, it needs 135KB after gzip; if it follows the server-side rendering solution, the rendering result SVG is 1 KB after gzip, and the client runtime is 1KB after gzip, only 1.5% of the former volume. In terms of interaction, the latter can also achieve initial animation, highlighting after the mouse moves to the chart element, and get click events, which can meet most of the common interaction needs.
If you need to use this solution, the server-side code remains the same, but you need to make sure that the ECharts version is above 5.5.0.
@@ -48,7 +52,7 @@
// Output a string
const svgStr = chart.renderToSVGString();
-// If chart is no longer useful, consider dispose it to release memory.
+// Dispose it to release memory
chart.dispose();
chart = null;
@@ -85,9 +89,11 @@
if (params.ssrType === 'legend') {
// Click the legend element, request the server for secondary rendering
isSeriesShown[params.seriesName] = !isSeriesShown[params.seriesName];
- $.get('...?series=' + JSON.stringify(isSeriesShown)).then(svgStr => {
- updateChart(svgStr);
- });
+ fetch('...?series=' + JSON.stringify(isSeriesShown))
+ .then(res => res.text())
+ .then(svgStr => {
+ updateChart(svgStr);
+ });
}
}
}
@@ -95,9 +101,11 @@
}
// Get the SVG string rendered by the server through AJAX request
-$.get('...').then(svgStr => {
- updateChart(svgStr);
-});
+fetch('...')
+ .then(res => res.text())
+ .then(svgStr => {
+ updateChart(svgStr);
+ });
</script>
```
diff --git a/contents/en/how-to/cross-platform/server.md b/contents/en/how-to/cross-platform/server.md
index d14a198..565fd3d 100644
--- a/contents/en/how-to/cross-platform/server.md
+++ b/contents/en/how-to/cross-platform/server.md
@@ -299,12 +299,12 @@
| Rendering Solution | Loading Volume | Loss of Function and Interaction | Relative Development Workload | Recommended Scenario |
| --- | --- | --- | --- | --- |
-| Client-side rendering | ~1000KB | None | Minimum | The first screen load time is not sensitive, and there is a high demand for complete functionality and interaction |
-| Client-side rendering ([partial package importing](basics/import#shrinking-bundle-size) on demand) | ＞400KB | Large: the packages not included cannot use the corresponding functions | Small | The first screen load time is not sensitive, there is no strict requirement for code volume but hope to be as small as possible, only use a small part of ECharts functions, no server resources |
-| One-time server-side SVG rendering | ~20KB | Large: unable to dynamically change data, does not support legend toggle series display, does not support tooltips and other interactions with high real-time requirements | Medium | The first screen load time is sensitive, low demand for complete functionality and interaction |
-| One-time server-side Canvas rendering | ~200KB | Largest: the same as above and does not support initial animation, larger image volume, blurry when enlarged | Medium | The first screen load time is sensitive, low demand for complete functionality and interaction, platform restrictions cannot use SVG |
-| Server-side SVG rendering plus client-side ECharts lazy loading | ~20KB + 1000KB | Medium: cannot interact before lazy loading is completed | Medium | The first screen load time is sensitive, high demand for complete functionality and interaction, the chart is best not needed for interaction immediately after loading |
-| Server-side SVG rendering plus client-side lightweight runtime | ~20KB + 4KB, an additional ~20KB per update request | Medium: Cannot implement interactions with high real-time requirements | Large (need to maintain chart status, define client-server interface protocol) | The first screen load time is sensitive, low demand for complete functionality and interaction, very strict requirements for code volume, not strict requirements for interaction real-time |
-| Server-side SVG rendering plus client-side ECharts lazy loading, using lightweight runtime before lazy loading is completed | ~20KB + 4KB + 1000KB | Small: Cannot perform complex interactions before lazy loading is completed | Largest | The first screen load time is sensitive, high demand for complete functionality and interaction, sufficient development time |
+| Client-side rendering | Largest | None | Minimum | The first screen load time is not sensitive, and there is a high demand for complete functionality and interaction |
+| Client-side rendering ([partial package importing](basics/import#shrinking-bundle-size) on demand) | Large | Large: the packages not included cannot use the corresponding functions | Small | The first screen load time is not sensitive, there is no strict requirement for code volume but hope to be as small as possible, only use a small part of ECharts functions, no server resources |
+| One-time server-side SVG rendering | Small | Large: unable to dynamically change data, does not support legend toggle series display, does not support tooltips and other interactions with high real-time requirements | Medium | The first screen load time is sensitive, low demand for complete functionality and interaction |
+| One-time server-side Canvas rendering | Large | Largest: the same as above and does not support initial animation, larger image volume, blurry when enlarged | Medium | The first screen load time is sensitive, low demand for complete functionality and interaction, platform restrictions cannot use SVG |
+| Server-side SVG rendering plus client-side ECharts lazy loading | Small, then large | Medium: cannot interact before lazy loading is completed | Medium | The first screen load time is sensitive, high demand for complete functionality and interaction, the chart is best not needed for interaction immediately after loading |
+| Server-side SVG rendering plus client-side lightweight runtime | Small | Medium: Cannot implement interactions with high real-time requirements | Large (need to maintain chart status, define client-server interface protocol) | The first screen load time is sensitive, low demand for complete functionality and interaction, very strict requirements for code volume, not strict requirements for interaction real-time |
+| Server-side SVG rendering plus client-side ECharts lazy loading, using lightweight runtime before lazy loading is completed | Small, then large | Small: Cannot perform complex interactions before lazy loading is completed | Largest | The first screen load time is sensitive, high demand for complete functionality and interaction, sufficient development time |
Of course, there are some other combination possibilities, but the most common ones are the above. I believe that if you understand the characteristics of these rendering solutions, you can choose the appropriate solution based on your own scenario.
diff --git a/contents/zh/basics/release-note/5-5-0.md b/contents/zh/basics/release-note/5-5-0.md
index fc3b658..6d4eb44 100644
--- a/contents/zh/basics/release-note/5-5-0.md
+++ b/contents/zh/basics/release-note/5-5-0.md
@@ -13,7 +13,6 @@
- 在子目录中添加了一些只包含 `"type": "commonjs"` 的 `package.json` 文件
这些改变意味着，像 `echarts/core.js` 这样的文件现在可以在像纯 Node.js、vitest、jest 和 create-react-app 这样的环境中解析为 ESM。
-请注意，如果使用 `exports`，那么在 `exports` 中未声明的文件将无法从外部访问。此外，路径必须以 `'.'` 开头。
我们还确保了这个新功能与各种环境兼容，包括运行时（Node.js/vitest/jest（create-react-app）/ssr/…）和打包器（webpack/rollup/vite/esbuild/…）。
@@ -21,9 +20,15 @@
## 服务端渲染 + 客户端轻量运行时
-从 Apache ECharts 5.3 版本起，我们支持了零依赖的服务端 SVG 字符串渲染方案，并支持图表的初始动画。但是，如果需要在客户端实现一些交互，那么需要加载完整的 ECharts，这可能会增加页面的加载时间。对于一些对页面加载速度要求较高的场景，这可能不是一个理想的选择。
+Apache ECharts 功能强大，相应地，包体积也比较大。我们在之前的版本中也做了各种努力来改进这一点。开发者可以使用 TreeShaking 按需加载部分代码，以减少加载的代码量。从 Apache ECharts 5.3 版本起，我们支持了零依赖的服务端 SVG 字符串渲染方案，并支持图表的初始动画。这样，使用服务端渲染的结果作为首屏渲染的画面，可以大大减少首屏加载时间。
-在 5.5.0 版本中，我们新增了客户端轻量运行时，客户端无需加载完整 ECharts 即可实现部分交互。这样，我们可以在服务端渲染图表，然后在客户端加载轻量运行时，实现一些常见的交互。这意味着，不再需要加载大约 1MB 的 ECharts 完整包，而是只需要加载约 4KB 的轻量运行时。这一改进将极大地提升页面加载速度，特别是对于移动端的体验。
+服务端渲染虽然是一种很有效减少包体积的解决方案，但如果需要在客户端实现一些交互，那么不得不仍旧加载 echarts.js，这可能会增加更多的加载时间。对于一些对页面加载速度要求较高的场景，这可能不是一个理想的选择。
+
+在 5.5.0 版本中，我们新增了客户端轻量运行时，客户端无需加载完整 ECharts 即可实现部分交互。这样，我们可以在服务端渲染图表，然后在客户端加载轻量运行时，实现一些常见的交互。这意味着，只需要加载 4KB 的轻量运行时（gzip 后 1KB），即可实现带初始动画和部分常用交互形式的图表。这一改进将极大地提升页面加载速度，特别是对于移动端的体验。
+
+
+
+以这个带标题的饼图为例，如果按客户端仅打包饼图和标题组件的方案，gzip 后需要 135KB；如果按服务端渲染的方案，渲染结果 SVG gzip 后 1 KB、客户端运行时 gzip 后 1KB，仅为前者体积的 1.5%。交互方面，后者也可以做到初始动画、鼠标移动到图表元素后的高亮，并且获取到点击事件，能够满足大部分的常见交互需求。
如需使用这一方案，服务端代码和之前一样，但需要保证 ECharts 版本号在 5.5.0 以上。
@@ -47,7 +52,7 @@
// 输出字符串
const svgStr = chart.renderToSVGString();
-// 如果不再需要图表，调用 dispose 以释放内存
+// 调用 dispose 以释放内存
chart.dispose();
chart = null;
@@ -84,9 +89,11 @@
if (params.ssrType === 'legend') {
// 点击图例元素，请求服务器进行二次渲染
isSeriesShown[params.seriesName] = !isSeriesShown[params.seriesName];
- $.get('...?series=' + JSON.stringify(isSeriesShown)).then(svgStr => {
- updateChart(svgStr);
- });
+ fetch('...?series=' + JSON.stringify(isSeriesShown))
+ .then(res => res.text())
+ .then(svgStr => {
+ updateChart(svgStr);
+ });
}
}
}
@@ -94,9 +101,11 @@
}
// 通过 AJAX 请求获取服务端渲染的 SVG 字符串
-$.get('...').then(svgStr => {
- updateChart(svgStr);
-});
+fetch('...')
+ .then(res => res.text())
+ .then(svgStr => {
+ updateChart(svgStr);
+ });
</script>
```
diff --git a/contents/zh/how-to/cross-platform/server.md b/contents/zh/how-to/cross-platform/server.md
index c354741..669b73e 100644
--- a/contents/zh/how-to/cross-platform/server.md
+++ b/contents/zh/how-to/cross-platform/server.md
@@ -299,12 +299,12 @@
| 渲染方案 | 加载体积 | 功能及交互损失 | 相对开发工作量 | 推荐场景 |
| --- | --- | --- | --- | --- |
-| 客户端渲染 | ~1000KB | 无 | 最小 | 首屏加载时间不敏感，对功能交互完整性要求高 |
-| 客户端渲染（[按需引用](basics/import#按需引入-echarts-图表和组件)部分包） | ＞400KB | 大：没有引入的包就无法使用对应功能 | 小 | 首屏加载时间不敏感，对代码体积没有严格要求但是希望尽可能小，仅使用 ECharts 的一小部分功能，没有服务器资源 |
-| 一次性服务端 SVG 渲染 | ~20KB | 大：无法动态改变数据、不支持图例切换系列是否显示、不支持提示框等实时性要求高的交互 | 中 | 首屏加载时间敏感，对功能交互完整性要求低 |
-| 一次性服务端 Canvas 渲染 | ~200KB | 最大：同上且不支持初始动画、图片体积更大、放大会模糊 | 中 | 首屏加载时间敏感，对功能交互完整性要求低，平台限制无法使用 SVG |
-| 服务端 SVG 渲染加客户端懒加载 ECharts | ~20KB + 1000KB | 中：懒加载完成前无法交互 | 中 | 首屏加载时间敏感，对功能交互完整性要求高，最好图表不会在加载后立刻需要交互 |
-| 服务端 SVG 渲染加客户端轻量运行时 | ~20KB + 4KB，每次更新请求额外 ~20KB | 中：无法实现实时性要求高的交互 | 大（需要维护图表状态、定义客户端服务端接口协议） | 首屏加载时间敏感，对功能交互完整性要求低，对代码体积有非常严格要求，交互实时性要求不严格 |
-| 服务端 SVG 渲染加客户端懒加载 ECharts，懒加载完成前使用轻量运行时 | ~20KB + 4KB + 1000KB | 小：在懒加载完成前无法进行复杂交互 | 最大 | 首屏加载时间敏感，对功能交互完整性要求高，有充分的开发时间 |
+| 客户端渲染 | 最大 | 无 | 最小 | 首屏加载时间不敏感，对功能交互完整性要求高 |
+| 客户端渲染（[按需引用](basics/import#按需引入-echarts-图表和组件)部分包） | 大 | 大：没有引入的包就无法使用对应功能 | 小 | 首屏加载时间不敏感，对代码体积没有严格要求但是希望尽可能小，仅使用 ECharts 的一小部分功能，没有服务器资源 |
+| 一次性服务端 SVG 渲染 | 小 | 大：无法动态改变数据、不支持图例切换系列是否显示、不支持提示框等实时性要求高的交互 | 中 | 首屏加载时间敏感，对功能交互完整性要求低 |
+| 一次性服务端 Canvas 渲染 | 大 | 最大：同上且不支持初始动画、图片体积更大、放大会模糊 | 中 | 首屏加载时间敏感，对功能交互完整性要求低，平台限制无法使用 SVG |
+| 服务端 SVG 渲染加客户端懒加载 ECharts | 小，然后大 | 中：懒加载完成前无法交互 | 中 | 首屏加载时间敏感，对功能交互完整性要求高，最好图表不会在加载后立刻需要交互 |
+| 服务端 SVG 渲染加客户端轻量运行时 | 小 | 中：无法实现实时性要求高的交互 | 大（需要维护图表状态、定义客户端服务端接口协议） | 首屏加载时间敏感，对功能交互完整性要求低，对代码体积有非常严格要求，交互实时性要求不严格 |
+| 服务端 SVG 渲染加客户端懒加载 ECharts，懒加载完成前使用轻量运行时 | 小，然后大 | 小：在懒加载完成前无法进行复杂交互 | 最大 | 首屏加载时间敏感，对功能交互完整性要求高，有充分的开发时间 |
当然，还存在一些其他的组合可能性，但最常用的就是以上几种，相信如果你了解了这些渲染方案的特点，就可以根据自己的场景选择合适的方案了。
diff --git a/static/images/5-5-0/ssr-example.png b/static/images/5-5-0/ssr-example.png
new file mode 100644
index 0000000..ab34038
--- /dev/null
+++ b/static/images/5-5-0/ssr-example.png
Binary files differ
