ejs-html - npm Package Compare versions

Comparing version 3.0.1 to 3.1.0

custom-els.md

@@ -6,3 +6,3 @@ # Custom Elements
 
-The basic example bellow defines a custom text input element, that has is put inside an label element and has a text title in front of it:
+The basic example bellow defines a custom text input element, that has its input inside an label element and has a text title in front of it:
 ```html
@@ -27,3 +27,3 @@ <label>
 ## Concepts
-As of this writting, the W3C is currently working in custom elements for the Web, under the [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) umbrella. But we are *not* talking about it here, this is a completly different beast (inspired by the rising standard, but yet not the same thing). EJS-HTML custom elements are resolved at render time, before the browser get to the HTML.
+As of this writting, the W3C is currently working in custom elements for the Web, under the [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) umbrella. But we are *not* talking about that here, this is a completely different beast (inspired by the rising standard, but yet not the same thing). EJS-HTML custom elements are resolved at render time, before the browser get to the HTML.
 
@@ -80,3 +80,3 @@ Any element that have a dash (`-`) on its name will be treated as custom (this follows the W3C standard). At compile time, they will be identified and compiled to a `customRender` call. At rendering time, the `customRender` will be called in order to render the custom element and return the HTML result. So it works conceptually like a super-powered include, because it accepts dynamic attributes and complex HTML content.
 
-Note that a empty-named content markup (`<eh-content name="">`) is implied for any content not inside a `eh-content` tag. In the example above, `<b>B</b>ody` is treated as if it was written as `<eh-content name=""><b>B</b>ody</eh-content>`
+Note that an empty-named content markup (`<eh-content name="">`) is implied for any content not inside a `eh-content` tag. In the example above, `<b>B</b>ody` is treated as if it was written as `<eh-content name=""><b>B</b>ody</eh-content>`
 
@@ -115,6 +115,6 @@ ## Default Placeholder Content
 ## Divergence From W3C's Web Components
-In the current spec, the W3C declares a `<content>` tag to act as ejs-html's `<eh-placeholder>`. This lib does not follow the spec because (a) its mechanism based on CSS selectors to solve multiple content areas is too complex (b) its usage is hard to optimize on compile time (c) there is no support for default content.
+In the current spec, the W3C declares a `<content>` tag to act as ejs-html's `<eh-placeholder>`. The spec is not followed by this lib because (a) its mechanism based on CSS selectors to solve multiple content areas is too complex (b) its usage is hard to optimize on compile time (c) there is no support for default content.
 
 ## The CustomRender Callback
-Currently, this lib does not attempt to detect witch EJS template to use to render a given custom element. You must implement that yourself and provide when rendering each template. For example, if your custom element definitions are in a folder, you are responsible to handle the routing.
+Currently, this lib does not attempt to detect which EJS template to use to render a given custom element. You must implement that yourself and provide when rendering each template. For example, if your custom element definitions are in a folder, you are responsible to handle the routing.
 
@@ -165,2 +165,2 @@ A full example bellow, for the given folder structure:
 })
-```
+```

HISTORY.md

@@ -0,1 +1,4 @@
+# 3.1.0
+* Added: `compile.both(source[, option])`
+
 # 3.0.1
@@ -2,0 +5,0 @@ * Fixed: npm.js does not render tabs on README correctly

lib/compile.js

@@ -39,3 +39,3 @@ 'use strict'
  */
-module.exports = function (source, options) {
+module.exports = function (source, options, _jsCode) {
 	options = options || {}
@@ -46,2 +46,7 @@
 
+	// Used internally, to avoid parsing the file twice in compile.both()
+	if (_jsCode) {
+		_jsCode.code = jsCode
+	}
+
 	let internalRender
@@ -84,2 +89,15 @@ try {
 /**
+ * Execute both {@link compile} and {@link compile.standAlone}
+ * This twice as faster then calling both in sequence, since the source will be parsed once
+ * @returns {{render: Render, code: string}}
+ */
+module.exports.both = function (source, options) {
+	let jsCode = {}
+	return {
+		render: module.exports(source, options, jsCode),
+		code: `var __escape = ${escape.html.standAloneCode}, __line = {}; ${jsCode.code}`
+	}
+}
+
+/**
  * Common logic for `compile` and `compile.standAlone`
@@ -86,0 +104,0 @@ * @private

package.json

 {
 	"name": "ejs-html",
-	"version": "3.0.1",
+	"version": "3.1.0",
 	"author": "Sitegui <[e-mail]>",
@@ -5,0 +5,0 @@ "description": "Embedded JavaScript HTML templates. An implementation of EJS focused on run-time performance, HTML syntax checking, minified HTML output and custom HTML elements.",

README.md

@@ -143,2 +143,8 @@ # EJS HTML
 
+### compile.both(source[, options])
+Runs both `compile(source, options)` and `compile.both(source, options)` at the same time to avoid parsing the source twice. Returns an object with two keys:
+
+* `render`: a function to run in the same VM, like `compile()`
+* `code`: a string, like `compile.standAlone()`
+
 ### render(source[, locals[, options]])
@@ -145,0 +151,0 @@ Just a convinience for `compile(source, options)(locals)`.

No alert changes

Improved metrics

Total package byte prevSize

46023

increased by2.05%

Lines of code

933

increased by1.74%

Number of lines in readme file

165

increased by3.77%

No dependency changes