WebSharper 4 beta-9

Zafir.4.0.177.78-beta9

Fixes

• #719 beta8 had a serious bug where it generated unsafe accesses to global object at the top of the scripts, this is now fixed, but not reverting the change to shorten outside addresses, see the note about breaking change below.

Improvements

• #722 Auto-hash WebSharper-generated output and files included as WebResource, use this hash on generating links to avoid browsers caching an outdated version. This is an automatic feature, no configuration currently.
• #725 Client-side JSON can de/serialize custom classes. (Serializable attribute and default constructor are not required as on the server.)
• #726 Not creating .js file for an assembly containing only inlined code
• #715 Client-side JSON module is visible as WebSharper.TypedJson from C# to avoid name conflict.
• #723 JavaScript(false) on an interface opts-out of default interface handling on client-side, allows for more divergence of client/server behavior when needed.
• #724 optional analyzer for closures, helping to avoid some classes of memory leaks in JavaScript.

There is an inconvenient source of memory leaks in most JavaScript engines: captured variables are tied to a Context object and even functions that do not use some (or any) variables from a Context still retain the whole object. This is described well here: http://point.davidglasser.net/2013/06/27/surprising-javascript-memory-leak.html

Adding a WebSharperAnalyzeClosures project property gives warnings on these kinds of captures, helping to eliminate memory leaks.

Usage: <WebSharperAnalyzeClosures>True</WebSharperAnalyzeClosures> or <WebSharperAnalyzeClosures>MoveToTop</WebSharperAnalyzeClosures>. The latter additionally moves all non-capturing lambdas to top level automatically (experimental).

Breaking change

• Previously, having [<Inline "myLibrary.doSomething()">] and [<Inline "$global.myLibrary.doSomething()">] was working equivalently. Now access to global scope without the $global object is assumed to be initialized before the current script starts running (WebSharper itself takes care of this, if you use the Require attribute) and will not change, so it is safe to shorten. Whenever you want the exact call on the current global scope (window object), be sure to use $global.