Basic Example of Client Side Templating with Dust.js

倾然丶 夕夏残阳落幕 提交于 2019-11-28 23:13:04
  1. If you put it in a div, the markup will render as soon as the page loads, and with contain the dust {placeholder} syntax. Then, once the client-side rendering happens, it'll suddenly be replaced with the fully rendered content. In a simple example, this can happen so fast you don't notice it. However, depending on how long it takes to download the templates, the dust JS libraries, fetch the JSON (if it's not already embedded in the page), the JS performance of the browser, and other things happening on the page, this switch may be very noticeable to a user, which is not a good experience.

  2. When you compile a dust template, the output is String that contains a JavaScript function. It will look something like:

    (function() { dust.register("intro", body0); function body0(chk, ctx) { /* [...] */ } })();

    When you pass this string to dust.loadSource, all it does is eval it, executing this self-calling function. The result is that the dust.register call executes, which associates the body0 function with the name intro in dust.cache. After that, every time you call dust.render("intro"...), dust looks up the intro template in dust.cache and executes the function associated with it.

  3. Store the output of dust.compile in a .js file, such as intro.js for the example above. You can then include dust-core.js and intro.js on the page just like any other JavaScript files (e.g. in script tags or via loaders).

  4. Usually, you store each dust template in a separate file, such as intro.tl and use some sort of build system (e.g. http://gruntjs.com/) to automatically compile it into a .js file every time it changes. You then concatenate all the generated .js files into a single file (grunt can do this too) and load that on the page in a script tag.

  1. You shouldn't have to contain the template in script tags, your second way is better.

  2. loadSource will run the compiled output of your template, which includes registering it so that other templates and dust.render can reference the compiled output chain through its name ("intro" in this case).

  3. This involves pre compiling your templates before you even open up the browser. So you might have a folder that has all your templates as .tl files. In some build step, you would compile all these templates (using dust.compile) and save the output as .js files. Then the browser would actually load those .js files. This also gets rid of the need for dust.loadSource. The advantage here is not having to include the compiler and the parser, which add up to ~3000 lines of code. The dust library size goes from 4000 lines of code to just 800 lines of code. EDIT: Also, as you mentioned, you're not compiling templates on the fly in the browser, so that will also be a big performance gain.

  4. I'd say other than missing the build step I mentioned above, you're on the right path.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!