Releases: dotnet-websharper/core
WebSharper 9.1.3
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 asapp.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
- Use
-
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, unlesswsBuilder.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
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
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
inwsconfig.json
to turn source mapping on. - #1468 Added a compiler setting
buildService
that can also turn F# compiler service on and off, deprecatingstandalone
but keeping it. Also added abuildServiceLogging
setting, that can turn off creating awebsharper.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, andSystem.Collections.Generic.IEnumerator
.
WebSharper 9.1
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 runnpm init
there to set up apackage.json
file. Leave entry point on the default setting (index.js
). We do this so that thebuild
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 atgz
package withnpm
. You can test locally withnpm install PathToTgz
, and runnpm 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 excepthtml
, andweb
ifprebundle
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 in
wsconfig.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 aweb
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
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 ofList
,Array
, andSeq
modules.
WebSharper 6.1.11
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 ofList
,Array
, andSeq
modules.
WebSharper 9.0
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 fordotnet 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
, andTimeSpan.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
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
WebSharper 6.1.10
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
WebSharper 8.0
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
inwsconfig.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 calledwsbundle
. Configure a bundler likeesbuild
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 avite
server on the url setting"DebugScriptRedirectUrl"
inappconfig.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 ascript
block, instead of grabbing data from ameta
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. AlsoJS.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 ofName("")
, 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
orGenerator
attribute on them, and your attribute will work as an alias. - #1386 You can use
"StubInterfaces": true
inwsconfig.json
to automatically treat all interfaces in your project as aStub
(interface for JavaScript interop). - #1395
Stub
attribute now accomodates for overloads, keeping the JavaScript name always as is in .NET. - #1397 F#
option
arguments inStub
types translate to plain arguments. - #1404
wsconfig.json
files can defineDebug
andRelease
sections. - #1405 Added missing
Style
property forHTMLElement
.
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
andGetAssemblyRendering
, 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.