Released DotVVM 3.0

A month after releasing a public preview, we are now releasing the final release of DotVVM 3.0. It brings several new features as well as many small improvements and bug fixes.

The main topic of DotVVM 3.0 is to do more things on the client-side, either by using the @js directive, or by getting more from static commands, using LINQ methods in bindings, and so on.

If you are interested in full list of changes, see the Release notes on GitHub.

New Features

JS directive

This feature allows to write code in JavaScript (or TypeScript) that can interact with DotVVM components and the viewmodel. The JavaScript file must have a default export – a function that create an instance of the “module”. You can call then exported JavaScript functions from static commands by using _js.Invoke("methodName", args...), as well as call DotVVM commands or static commands from the JavaScript module by using the new NamedCommand control. Thanks to the new support of lambda functions in bindings, it is simple to pass parameters from JavaScript.

See the JS directive sample application to see how easy it is to use this feature.

LINQ methods in data-bindings

One of the benefits of being able to use lambdas in binding expressions is that we can translate LINQ methods to their JavaScript equivalents. Starting from DotVVM 3.0, you can now use Where and Select methods in data-bindings which allows to make client-side filtering. We plan to extend this list in DotVVM 3.1.

There are some limitations we also plan to fix in DotVVM 3.1 – right now, you need to specify types with your lambda methods, DotVVM cannot infer them yet.

<dot:GridView DataSource="{value: Customers.Where((CustomerData c) => string.IsNullOrEmpty(Filter) || c.Name.Contains(Filter)}">
    ...
</dot:GridView>

Variable support in binding expressions

You can now declare variables in binding expression, which enhances the abilities especially in static command bindings. For example, you can get multiple values on one request, and then assign them to different parts of the viewmodel.

{staticCommand: var result = _myService.GetItems(); Items = result.Items; TotalCount = result.TotalCount}

Better development experience

We have bundled both minified and non-minified versions of DotVVM scripts, and improved logging on the client-side.

If you run DotVVM in the debug mode, you’ll get non-minified DotVVM and Knockout JS files which simplify debugging. If you are interested in more detailed log messages, you can set dotvvm-loglevel entry to verbose in your site’s local storage.

Improvements

We have refactored the entire TypeScript part of DotVVM into ECMAScript modules, and we are using rollup to produce bundles for modern browsers as well as IE 11 (with SystemJS polyfill).

We have also introduced a new state manager which keeps the viewmodel state in an immutable JS object, and emulates the hierarchy of Knockout observables to be used in data-bindings. The state manager brings new API (you can just call dotvvm.state to obtain the current snapshot of the viewmodel, and you can update the viewmodel by calling dotvvm.patchViewModel). Also, there are new methods on observables – read-only state property and patchState / setState.

Also, the viewmodel is now aware of types of its properties, and validates all changes made to the state. If you try to set an object into a property where int is expected, you’ll get an error. In several specific situations (e. g. assigning number to a string property), we can coerce the value to the correct type. This should help you when you try to interact with the viewmodel from JS code – it should prevent you from breaking the state.

Breaking changes

Upgrading from DotVVM 2.x to 3.0 should be much easier than upgrading from DotVVM 1.1 to 2.0. There are only few places where things have changed:

• If you handle client-side events like beforePostback, afterPostback, error and so on, please note that we’ve renamed or removed some attributes of the event arguments.
• We have changed all script resources to have the defer option enabled by default (because DotVVM is also loaded with defer option). In most cases, it should just work, but it’s good idea to check if all your scripts load correctly.
• We have changed the methods in IUploadedFileStorage and IReturnedFileStorage to their async versions

See the Breaking changes section in the Release notes for more details.

Released DotVVM Business Pack 3.0 Preview 3

We are close to the release of the final version of Business Pack 3.0.

The biggest change for us has been the refactoring of the CSS styles of Business Pack. We are now using CSS variables which offer an easy way to change the styles of controls – you just change the value of the CSS variable without the need to have your own build of Business Pack. Internally, we have rewritten the stylesheets from Node-Sass to Dart Sass – it will help us to make our scss files easier to maintain, and give us more features.

Also, we have finished the ImageCrop control (which has been marked as experimental until now). There is also a new version of the RichTextBox control.

New version of DotVVM for Visual Studio is on its way

In recent updates to Visual Studio 2019, some internal APIs changed which made our extension throwing errors (DotvvmPackage couldn’t be loaded and similar). We try to stay compatible with the latest VS updates, and we’ve been able to fix the problem in a day or two after VS 16.9.2 was released.

Unfortunately, there is no clever way to offer different versions of the extension for different minor versions of Visual Studio, so we don’t know how to prevent these situations in the future. Let’s hope that Microsoft won’t change the HTML editor API so frequently in the future.

In a few days, we’ll ship a new version of the DotVVM for Visual Studio extension with new project templates targeting DotVVM 3.0 and offering an option to create a new DotVVM JS module file.

New docs will arrive soon

We are still working on the docs for DotVVM 3.0. We’ve decided to change the structure of the docs because the division of the content between basic and advanced topics didn’t make much sense. We’ll launch the new docs site in mid-April.

What’s next: DotVVM 3.1

Right now, we have couple of pull requests that are almost finished and are now in the review phase. We plan to finalize them and release DotVVM 3.1 quite soon – hopefully in May / June timeframe. You can look forward to:

• Enhancements in the validation - you will be able to return validation errors outside the validation target, or use validation in static commands
• Type inference for lambda functions in bindings
• More LINQ methods supported in bindings (e. g. OrderBy)
• FileUpload that is not using iframe

We have also started planning for DotVVM 4.0 – there are several interesting ideas on the table, like making it easier to write custom controls, enhancing the data sets so they can be loaded using static commands or REST APIs, together with a support for infinite scrolling.

We are very thrilled of DotVVM 3.0, and we hope that the new features will make your life easier. We’ll be happy for any feedback – join us on the Gitter chat.