lockandload - npm Package Compare versions

Comparing version 1.1.6 to 1.1.7

package.json

 {
   "name": "lockandload",
-  "version": "1.1.6",
+  "version": "1.1.7",
   "description": "Minimalist AMD-compliant Javascript and CSS loader",
@@ -5,0 +5,0 @@ "main": "index.html",

README.md

@@ -26,4 +26,5 @@ <h1>lockandload</h1>
 - No extra diagnostic code to minimise code weight and optimise loading speed.
-- Fully event driven, no polling timers.
-- Standard event: domready.
+- Mostly event driven, no polling timers except for the scss() helper
+  function.
+- Standard supported dependencies: `require` and `domready`.
 - Both high and low priority asynchronous loading of Javascript and CSS files.
@@ -37,2 +38,5 @@ - Leverages native browser speed for high priority loading (by getting out
 - No config file, means: no syntax to learn, no config file parser code.
+- No module system: all needed functionality is included already because
+  it was/is so small, that writing a module system would take more code
+  than the source of all the added functionality.
 
@@ -63,3 +67,5 @@ ## Requirements
     - Inline `lockandload` 'headready' script.
+      - CSS scripts fullfilling a custom applied-style dependency.
       - Low priority CSS scripts.
+      - Medium priority async Javascript scripts.
       - Low priority async Javascript scripts.
@@ -72,7 +78,9 @@ - Low priority synchronous Javascript scripts.
 Look at `annotated.html` to understand the code and read additional
-inline documentation.
+inline documentation.  This `index.html` file is not present in the git
+source repository, it can only be found in the npm repository (or after running
+ `npm run prepublish`).
 
 ## API
 
-Globally:
+### Globally
 - `define(id?, dependencies?, factory)`<br />
@@ -85,7 +93,13 @@ The standard [AMD global
 
-Locally in the secondary `lockandload` 'headready' script; all path arguments
+   Running `define(1, dependencies, factory)` is a custom extension and is
+   the same as the traditional global `require(dependencies, factory)`.
+   It is used in the existing scripts to avoid defining the global
+   `require()`.
+
+### Locally
+In the secondary `lockandload` 'headready' script; all path arguments
 are used verbatim in `<link href="path">` or `<script src="path">` tags:
 - `scss(id, path)`<br />
    Loads additional ordered css files asynchronously; after the stylesheet
-   has been applied, it fires the `id` event.
+   has been applied, it fulfills the `id` dependency.
 - `css(path)`<br />
@@ -99,2 +113,36 @@ Loads additional low priority ordered css files asynchronously.
 
+### Dealing with jQuery
+In order to support legacy code that uses inline `$(function(){...})` scattered
+throughout pages, this loader allows you to use that construct even before
+the jQuery library has been loaded,
+and thus enables you to load jQuery in an asynchronous and non-blocking fashion.
+
+The standard `headready` script contains a dependency on `domready` and
+`jquery`  which then at the end runs `domready()` which will run all the
+registered delayed functions.
+
+### SPA (Single Page App) support
+To ease SPA development, the loader defines a
+`$$(function(jquery_document){...})`  function which registers functions
+for execution on every SPA-controlled page refresh.  The registered functions
+receive a convenience argument `$(document)` when executed.
+
+To run the registered functions, one needs to make a call to the entrypoint
+of the AMD-dependency on `domready`.
+
+E.g. in your application, you could use code like this:
+
+```javascript
+!function(){
+  // Preamble
+  define("main", ["domready"], function (domready) {
+    // Your main application
+    function refreshpage() {
+      // The function that gets called on virtual page refreshes
+      domready();	// This will call all registered $$(...) functions
+    }
+  });
+}();
+```
+
 ## References
@@ -101,0 +149,0 @@

No alert changes

Improved metrics

Total package byte prevSize

19678

increased by12.61%

Number of lines in readme file

158

increased by43.64%

No dependency changes