Options
All
  • Public
  • Public/Protected
  • All
Menu

支持的三种输入方式及区别

在之前的示例中,传入 SanProject 的内容为组件类:

const { SanProject } = require('san-ssr')
const san = require('san')
const MyComponent = san.defineComponent({
    template: `<div>Hello {{ name }}</div>`
})

// SanProject 类提供了你会用到的所有接口
const project = new SanProject()

// 输入是组件对象
// 输出是一个 render 函数。该函数接受数据对象作为参数,返回 HTML 字符串。
const render = project.compileToRenderer(MyComponent)

const html = render({name: 'San'})

事实上,San-SSR 支持三种输入,分别为组件类、JavaScript 文件路径与 TypeScript 文件路径:

// app.js
const san = require('san')
let MyComponent = san.defineComponent({
    template: "<div>Hello {{ name }}</div>"
})
exports = module.exports = MyComponent
// index.js
const { SanProject } = require('san-ssr')
const fs = require('fs')
const path = require('path')

const project = new SanProject()

// 此时传入的是一个文件路径
// 得到的是 render 函数文件内容
const renderStr = project.compileToSource(require.resolve('./app.js'))
// const renderStr = project.compileToSource(require.resolve('./app.ts'))

fs.writeFileSync(path.resolve(__dirname, 'output.js'), renderStr)


// 在服务器端执行以下代码进行渲染
const render = require('./output.js')
const html = render({name: 'San'})

compileToRender 与 compileToSource

  • compileToRender 只支持输入组件类。
  • compileToSource 支持输入组件类、JavaScript 文件路径以及 TypeScript 文件路径。

区别

根据不同的输入,San-SSR 的行为是不同的。

输入为组件类时

此时 San-SSR 接收到的是已经在内存中的类,组件的 template、components 等信息可以直接在类上通过属性读取。

优点:

  • 可以通过递归的方式遍历整个组件树。
  • 获取到的是代码执行后的结果,San-SSR 对于组件的写法是无感的。

缺点:

  • San-SSR 并不知道当前类及其子组件所对应的文件信息,也就是“不知道这些组件类是从哪里来的”。
  • 当使用 compileToSource 时,San-SSR 需要尝试将内存中的类转换为字符串定义,有一定局限性。
  • 由于需要将组件加载到内存中,因此可能在线下编译阶段执行组件代码,其依赖必须完备(仅仅是为了 require 不报错)。

输入为文件路径时

此时 San-SSR 会尝试读取文件内容,其输入是组件文件的字符串,组件的 template、components 等信息需要通过静态分析的方式获取哦。

优点:

  • San-SSR 知道组件的明确路径。
  • San-SSR 知道组件定义文件内容。
  • 可以单文件编译,不需要加载完整的组件树。

缺点:

  • 组件写法需要相对固定,过于复杂时,无法通过静态分析获取到 template、components 等信息。

Generated using TypeDoc