Skip to content

Releases: dotnet-websharper/core

WebSharper 9.1.3

10 Jun 13:22
Compare
Choose a tag to compare

This is a minor release of WebSharper 9.1. NuGet version 9.1.3.570.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::9.1.3.570

Enhancements

  • #1474 support embedding WebSharper content into Razor pages. To enable this

    • Use services.AddWebSharperContent() in your startup, as well as app.UseWebSharper() (or one of its variants).
    • In your layout page, use @inject WebSharper.AspNetCore.IWebSharperContentService WebSharperContentService and add @WebSharperContentService.Head() to the head section of the page for a placeholder for WebSharper to place initialization scripts.
    • In your Razor PageModel file (code backend), use the IWebSharperContentService service with dependency injection, and then you can create a property that defines a WebSharper content embedded into the page. Here with also creating a named optimized bundle for the page:
          public IHtmlContent MyWebSharperControl =>
              _webSharperContentService.Render(                
                  WebSharper.Sitelets.Content.Bundle("index", new MyWebSharperControl()));
    • Use this property within your page, like @Model.MyWebSharperControl. Do not create WebSharper.Web.Controls directly in your Razor expressions as the WebSharper compiler cannot discover them there for preprocessing.
    • See https://github.com/dotnet-websharper/aspnetmvc for a demo
  • Also, app.AddWebSharper() will now not fail if no sitelet is configured, but will just run remoting and support MVC content. It will also not attempt to load sitelet via reflection by default, unless wsBuilder.DiscoverSitelet() is used.

Fixes

  • #1473 Fix a dead code elimination issue that could cause page startup problems.
  • Tied the version of WebSharper.UI and WebSharper core packages together to the exact version. This can resolve a hidden bug arising from fixes around macros not being applied right when the UI type provider was build with lower version core dlls.

WebSharper 9.1.2

29 May 11:35
Compare
Choose a tag to compare

This is a bugfix release of WebSharper 9.1. NuGet version 9.1.2.559.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::9.1.2.560

Fixes

  • #1472 Fixes for passing captured values to the client, for example with WS.UI's ClientServer.client. Solve dead code elimination issues around json deserializers.

WebSharper 9.1.1

26 May 15:21
Compare
Choose a tag to compare

This is a minor release of WebSharper 9.1. NuGet version 9.1.1.557.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::9.1.1.557

Improvements

  • #1467 Restore the ability to create source maps. As before with WebSharper 6, use "sourceMap": true in wsconfig.json to turn source mapping on.
  • #1468 Added a compiler setting buildService that can also turn F# compiler service on and off, deprecating standalone but keeping it. Also added a buildServiceLogging setting, that can turn off creating a websharper.log file while still using the build service. For all current settings, see https://github.com/dotnet-websharper/core/blob/master/docs/CompilerSettings.md
  • #1457 Fixes for .d.ts output for methods with single generic argument, and System.Collections.Generic.IEnumerator.

WebSharper 9.1

15 May 14:53
Compare
Choose a tag to compare

This is a major release of WebSharper. NuGet version 9.1.0.554.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::9.1.0.554

Create npm packages with TypeScript definitions included

This is how you can use new features quickly:

  • After installing templates with above command, create a new WebSharper library project with dotnet new websharper-lib -o MyLib -lang F# (or -lang C#)
  • To wsconfig.json, add:
    "javascriptExport": true,
    "dce": true,
    "outputDir": "build"
  • Note: .d.ts file generation is now on by default, no need to specify it.
  • Create an assets folder and run npm init there to set up a package.json file. Leave entry point on the default setting (index.js). We do this so that the build folder can be wiped on a clean safely.
  • Add to your project file:
    <Target Name="CleanBuildDir" BeforeTargets="CoreCompile">
      <RemoveDir Directories="build" />
    </Target>
    
    <Target Name="CopyPackageJsonAndPack" AfterTargets="WebSharperCompile">
      <Copy SourceFiles="assets/package.json" DestinationFolder="build" />
      <Exec Command="npm pack" WorkingDirectory="build" />
    </Target>
  • Build your project which now writes dead code eliminated output to build folder, then packages it into a tgz package with npm. You can test locally with npm install PathToTgz, and run npm publish PathToTgz when ready to push to the public registry.

Improvements

  • #1457 WebSharper now can generate .d.ts output to enrich .js output files with TypeScript type information. This is supported for all project types except html, and web if prebundle is true.
  • #1462 Added a mode for generating minimal output code to make an npm package with WebSharper. To use this mode, create a library project then set use "dce": true" and set the "outputDir"setting too inwsconfig.json`. For more details, see the new documentation at https://github.com/dotnet-websharper/core/blob/master/docs/CompilerSettings.md#dce
  • #1463 When "prebundle": true (production-ready mode) for a web project, do not unpack unnecessary debug mode JavaScript files to output folder from references.
  • #1464 Some internal optimizations for faster Sitelet project initialization.

WebSharper 9.0.1

24 Apr 12:36
Compare
Choose a tag to compare

This is a hotfix release of WebSharper 9.0. NuGet version 9.0.1.549.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::9.0.1.549

Fixes

  • #1459 resolve off-by-one bugs and improve performance of collection functions introduced with F# 6.0, these are: insertAt, insertManyAt, removeAt, removeManyAt, updateAt, for each of List, Array, and Seq modules.

WebSharper 6.1.11

24 Apr 12:38
Compare
Choose a tag to compare

This is a hotfix release of WebSharper 6.1, backporting some fixes from WebSharper 9.0. NuGet version 6.1.11.550.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::6.1.11.550

Fixes

  • #1459 resolve off-by-one bugs and improve performance of collection functions introduced with F# 6.0, these are: insertAt, insertManyAt, removeAt, removeManyAt, updateAt, for each of List, Array, and Seq modules.

WebSharper 9.0

17 Apr 07:45
Compare
Choose a tag to compare

This is a major release of WebSharper. NuGet version 9.0.0.547.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::9.0.0.547

WebSharper 9.0 is running on .NET 8, the current Long Term Support .NET framework. WebSharper 9.0 is fully compatible with WebSharper 8.0, only adding support for new language and framework features.

Improvements

  • Templates now have a framework selector. Use the -f or --framework options for dotnet new or the framework dropdown in Visual Studio new project dialog. The default framework is .NET 8.0.
  • #1419 F# 9.0 features:
    • nullable reference types,
    • .Is* properties on union types,
    • partial active patterns can return bool instead of unit option,
    • empty-bodied computation expressions,
    • random functions for collections,
    • C# collection expression support for F# lists and sets
  • #1420 C# 13.0 features:
    • params collections
    • more support for partial members
    • new overloads on String.Format, String.Concat, and TimeSpan.From* methods

Fixes

  • #1455 Fix using trait calls in inlines and using it in a way that it resolve to a method defined by a base class of current type

WebSharper 8.0.1

14 Apr 14:27
Compare
Choose a tag to compare

This is a minor release of WebSharper 8.0. NuGet version 8.0.1.543.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::8.0.1.543

Fixes

  • #1454 Fixes a bug in the optimizer when immediately invoking a property of an object expression.
  • #1448 TimeSpan.Days/Hours/etc methods now match .NET results for negative durations.

Improvements

  • #1442 let inline can be used as part of code, not just on module level.
  • #1452 using overloads instead of optional arguments for the extension methods on IApplicationBuilder, including resolving ambiguous overload error for .UseWebSharperRemoting().

WebSharper 6.1.10

14 Apr 15:09
Compare
Choose a tag to compare

This is a hotfix release of WebSharper 6.1, backporting some fixes from WebSharper 8.0. NuGet version 6.1.10.544.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::6.1.10.544

Fixes

  • #1448 TimeSpan.Days/Hours/etc methods now match .NET results for negative durations.
  • #1429 Removed a console print from DateTime.ToString custom formatter parsing.

WebSharper 8.0

26 Mar 13:42
Compare
Choose a tag to compare

This is a major release of WebSharper. NuGet version 8.0.0.540.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates::8.0.0.541

WebSharper version 8 is running on .NET 8, the current LTS .NET framework. A WebSharper 9 upgrade is soon in the pipeline. The WebSharper 7 version haven't reached maturity, so it is skipped as a production-ready release. The below change summaries reflect changes since WebSharper 6.

Changes to JavaScript translation

WebSharper 8 writes modern module-based JavaScript code. This is a break from previous versions which still had EcmaScript 5 compatible output that could be directly interpreted by browsers. With WebSharper 8, usually some bundling tool is required if you use code that would import any npm packages or if you want to optimize your site for production. Many WebSharper bindings have been updated to use npm imports.

For an overview of WebSharper's JavaScript translation with F# examples (but everything is also valid for C#), see the WebSharper 8 translation document.

Changes to Sitelets (web projects)

Along with the JavaScript change, using dynamic code lookup has been eliminated, initializing web pages always use explicit import statements. A production-ready mode has been added to serve optimized bundled code.

Please read the WebSharper 8 update guide on how to update your older projects or create a new WebSharper 8 project from a template using dotnet new install WebSharper.Templates.

  • #1359 Web.Controls now use a ws-id attribute on elements to mark where to insert dynamic content.
  • #1361 By default, output follows one class per file rule, and there is an additional root.js for web projects that re-exports everything needed by the site. This file can be used as an entrypoint for a bundler like esbuild.
  • #1372 If you specify "prebundle": true in wsconfig.json, then the WebSharper compiler will create readable npm-based prebundles, and Sitelets runtime will expect fully bundled code export their contents through a global variable called wsbundle. Configure a bundler like esbuild to create a final bundle.
    See new templates for an example.
  • #1438 Prebundling is also supported for offline sitelets. Use a bundler to generate fully offline-compatible JavaScript.
  • #1408 Added a UseWebSharperScriptRedirect helper for Asp.NET Core, which starts up a vite server on the url setting "DebugScriptRedirectUrl" in appconfig.json's "websharper" section.
  • #1403 Added Content.PageFromFile, which serves a html file from application root, while inserting an initializer scripts where exact placeholder <script ws-replace="scripts"></script> is found.

Changes to Remoting and JSON serialization

  • #1343 Remoting now uses a symmetric JSON serialization, requests and responses have use the same serializers. In JavaScript code, a function is created for every RPC function, that wraps this deserialization and handles the asynchronicity.
  • #1346 Web.Control initialization now takes place in a script block, instead of grabbing data from a meta element.
  • #1336 RPC endpoints are exposed by default at yourURL/TypeName/MethodName, and do not expect any custom headers any more, but behave like a standard API.
  • #1424 The above default path can be overridden with the Remote attribute, example: Remote("alternatePath").
  • #1339 Record types can now be used for instance-based remoting. Example:
    type RecordRemote =
        {
            [<Remote>]
            R1 : string -> Async<string>
        }
    let recordRemoteImpl =
        {
            R1 = fun x -> 
                async {
                    return (x + "_fromRecordRemote")
                }
        }
    do AddRpcHandler typeof<RecordRemote> recordRemoteImpl
  • #1047 Interfaces can now be used for instance-based remoting, similar to classes and records.

New features

  • #1299 Added the Import attribute, sample usage:
    [<Import("sayHi.js")>] // imports the default export, applies to all Inlines/Stubs within class
    type SayHi [<Inline "new $imported()">] () =
        
        // FooInst is an instance member, we don't have to refer to an import directly, so its effect is ignored
        [<Inline "$this.FooInst()">]
        member this.FooInst() = X<string>
    
        // Foo is a static member of SayHi class, this inherits the Import attr from the type
        [<Inline "$imported.Foo()">]
        static member Foo() = X<string>
     
        // Bar is a separate named export, we redefine the Import attr which hides the one inherited from the type
        [<Import("Bar", "sayHi.js"); Inline "$imported()">]
        static member Bar() = X<string>
  • #1391 Added WebSharper.JavaScript.ImportFile function which adds a side-effecting import, that can be used for css and other non-code resources.
  • #1347 Added ImportFile helper to WebSharper.InterfaceGenerator, example usage: "default" => T<unit> ^-> T<unit> |> ImportFile (sprintf "highlight.js/styles/default.css" name).
  • #1333 Added JS.Verbatim which takes a string and exact JS code will be printed in the code output. Supports string interpolation to include values. Also JS.jsx for supporting jsx HTML fragments.
  • #1325 You can use "JsOutput": "path" to make the compiler output all generated code from library projects too.
  • #1350 Added support of SPAEntryPoint attribute for library projects. Combined with the "JsOutput" setting, this allows library projects to be used for producing .js files for external use. An $EntryPoint.js file will contain the call for the annotated function.
  • #1337 You can add static members EncodeJson/DecodeJson on a type to enable WebSharper's client-side JSON serialization on them.
  • #1340 Query parameters can be included in Endpoint attribute values: | [<EndPoint "/FindBook?isbn={isbn}&ty={ty}">] FindBook of isbn:string * ty:string option
  • #1388 Added proxy for System.StringBuilder
  • #1389 Added proxy for System.Convert
  • #775 Added proxy for stderr/System.Console.Error
  • #1355 Added the !... operator for F# use, which translates directly to the JavaScript spread operator ...
  • #1383 Metaprogramming: macros defined on the type level is now invoked before the macro on a member. The type level one can return a MacroFallback value to let use the default translation for a member.
  • #1368 Stub attribute is valid for interfaces, with the equivalent effect of Name(""), translating member names without prepended type name.
  • #1373 Metaprogramming: generators now get the expression of the member they are used on, so they can act as decorators, dynamically adjusting the code of the member.
  • #1377 Metaprogramming: you can define your own attribute, put Macro or Generator attribute on them, and your attribute will work as an alias.
  • #1386 You can use "StubInterfaces": true in wsconfig.json to automatically treat all interfaces in your project as a Stub (interface for JavaScript interop).
  • #1395 Stub attribute now accomodates for overloads, keeping the JavaScript name always as is in .NET.
  • #1397 F# option arguments in Stub types translate to plain arguments.
  • #1404 wsconfig.json files can define Debug and Release sections.
  • #1405 Added missing Style property for HTMLElement.

Fixes

  • #1387 Implicit quotations in client-side code are not pre-compiled as a separate member.
  • #1412 Fix dead code elimination around interface methods.
  • #1351 Fix WIG created dlls to have file information when looked at by Windows file properties dialog.

Language features

  • The compilers now run on .NET 8.
  • #1366 F# 8.0 new features: syntax sugar (property shorthand, nested record field copy, etc.), static interface members, try/with within collection expressions
  • #1294 C# 11.0 new feature: list patterns
  • #1367 C# 12.0 new features: primary constructors for non-record classes, collection expressions and the .. operator

Cleanup and optimizations

  • #1445 All standard proxies are now merged into a single WebSharper.StdLib.dll
  • #1362 removed the requestAnimationFrame polyfill.
  • #1364 removed the JSON polyfill.
  • #1431 printf functions now generate cleaner code when a string is used in a %s hole.
  • #1443 Removed UseStdlibCdn and other WebSharper CDN-related settings.
  • #1444 Removed UseMinifiedScripts setting. WebSharper now outputs readable code, to be processed by external JavaScript tooling for production purposes.

Breaking changes

  • The serialization/url changes around remoting can break code if you depended on unspecified internal mechanisms of RPC calls. The goal of the remoting changes is to provide reliable API shapes now.
  • Removed two fields from Resources.Context type: DebuggingEnabled and GetAssemblyRendering, these had a very low chance to be needed from any user code directly.
  • #1351 was achieved by WIG building atop the definitions library. In WIG, make sure you don't have namespace conflicts between your definitions and the defining code, and ideally hide the definitions by making them internal.