JavaScript

From Organic Design wiki
Revision as of 09:47, 26 March 2015 by Nad (talk | contribs) (SPA)
Cone.png This article or section is a stub. Stubs are articles that have not yet received substantial attention from the authors. They are short or insufficient pieces of information and require additions to further increase the article's usefulness. The project values stubs as useful first steps toward complete articles.

Scope

Prototypes

Closures

A closure is like a bubble in JavaScript in that it acts like a separate self-contained global scope, and can contain variables, functions, and even entire JavaScript frameworks like jQuery. The Module Pattern is a closely related concept which is the most common form that closures take, it's become the generally accepted method of creating JavaScript code designed to be imported without any assumptions as to the target environment.

Closures can have both a private and public aspect, they're in the form of a function rather than an object, and are brought into existence by calling them, what's returned is the public interface. The content of the scope within the closures definition is private and exists for as long as the returned public interface exists.

The following example illustrates a simple closure. The variable foo is private and can only be accessed by functions in the same private scope, or by the functions returned in the public interface. An instance of the closure is created in the variable closure by being assigned the value returned by anonymously executing the declared function.

{{{1}}}


In the example above, the public function baz can access the private foo variable from it's local scope. The public interface also includes a variable bar which can be accessed publicly or via this from within the executing public interface functions. All of the items in both the private and the public scopes of the closure exist for the lifetime of the closure object.

In this next example, a single private variable is defined, and there are two public functions which are called one after the other. The first stores a secret message in the private variable which the second displays. This shows that the private local scope of the functions remains intact after the function exits and is available to all the functions. It is not available outside the scope of the functions thought, any data which needs to be available outside the private scope of the closure needs to be prefixed with this. Note that if the private variable were not defined in the private scope, then the function that writes to it would create the variable in the global public scope because it's not using the var keyword.

{{{1}}}


To pass globals into your closure such as jQuery as $, use the following syntax - this is actually more efficient too because the interpreter doesn't need to walk the tree to find the value of $.

{{{1}}}


For more in-depth information about closures, see Understanding closures, The Module pattern in-depth and Snook.ca Why I don't love the JavaScript module pattern.

Single-page applications

A single-page application (SPA), also known as single-page interface (SPI), is a web application that fits on a single web page. In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or partial changes are performed loading new code on demand from web servers, usually driven by user actions.

The page does not automatically reload during user interaction with the application, nor does control transfer to another page. Necessary updates to the page display may or may not involve interaction with a server. The term single-page application was coined by Steve Yen in 2005, though the concept was discussed at least as early as 2003.

Hash fragments

A central concept making single-page applications possible is the idea of "hash fragments" which is the part of the URL appearing after the first hash character. Everything after the hash represents addressing within the document, whereas everything before the hash is outside the page and requires a server to fetch the document. This allows applications to have their current state fully reflected within the URL so it can be bookmarked - this is one of the foundation principles of the web, that any state the application is in, for example a report or query result, can be bookmarked or sent to others as a URL. So the Single Page Application model is the best of both worlds - it has the dynamic feel of a desktop application having instant responsiveness without page reloads, but also has the important URL reflection quality of the web.

The most natural way of mapping application interface elements to functionality in the system model is to make the URL portion after the hash continue on in the form of path elements separated by slashes - hence the name "hash fragments".

In the OrganicDesign software architecture we plan to make the entire path after the hash map directly to a path in the unified ontology so that the whole p2p network would be accessible via the following kind of URL format.

http://localhost/#/path/into/unified/ontology/

This could also start with a normal domain name if the peer instance is running on a server connected to the web, in that case an optional exclamation mark could also be included which indicates that the paths should be crawlable by search engines, for example:

http://foobar.com/#!/path/into/unified/ontology/

pushState

pushState is an HTML5 API that offers a different way to change the current URL, and thereby insert new back/forward history entries, without triggering a page load. This differs from hash-based navigation in that you're not limited to updating the hash fragment — you can update the entire URL. Most modern framemworks that offer Single Page Application support can determine if the browser supports pushState and use it, but fall back to hash fragment URL format otherwise.

Existing SPAs

JavaScript frameworks

Graphics libraries

Tools

See also