Skip to content

DotVVM 3.2
Compare
Choose a tag to compare
@quigamdev quigamdev released this 30 Aug 09:53
· 19 commits to release/3.2 since this release
v3.2
abce228

New features

Added more JavaScript translations

#1059, #1062, #1100
We continued with our effort to add JavaScript translations for common .NET methods and some custom extensions. You can use these methods inside data-binding to express more complex operations and have them evaluated on the client's side.

  • DateTime property getters (e.g. Year, Month, Day etc.)
  • WebUtility methods (UrlEncode(str), UrlDecode(str))
  • Numerous new string methods
    • IsNullOrWhiteSpace(str)
    • Many overloads for comparing strings with the StringComparison parameter
    • Many trimming and padding method overloads

Improvements and fixes

Changed type of viewmodel to any

#1069
The type of dotvvm.state is now any. This allows for an easier access to the underlying state of viewmodels without the need of repeated casting.

Prefer to use state in static commands

#1078, #1113
We fixed a synchronization issue that occurred with state, which could have been observed using a staticCommand. Changes made to state in user code were not always correctly reflected. As a result it was possible to read old data using staticCommand.

Fixed OnPreInit invocation on DotvvmMarkupControl

#1082
Usage of the parameterless constructor on DotvvmMarkupControl may have previously caused weird issues in connection with the @js directive. This was caused due to the fact that the necessary resource was not loaded.

Fixed NRE when using NamedCommand without the @js directive

#1083
DotVVM no longer throws a NullReferenceException in case user specifies a NamedCommand without the @js directive. This use case is still not supported, however, DotVVM now throws a better and more descriptive exception that tells user what is wrong.

Improved error reporting when a function from viewmodule module fails

#1085
DotVVM now provides a better error whenever a function from a viewmodule (also known as a JavaScript module) fails.

Fixed issue with not loading assemblies with custom controls

#1087
Some users and components register controls using the config.Markup.Controls.Add(...) method call. However, this does not update the assemblies list in config.Markup.Assemblies and as a result DotVVM may have previously missed to load some necessary assemblies.

Fixed issue with type inferer

#1093
Type inferer for lambda parameter types no longer fails on some of the supported and more complex .NET methods.

Fixed REST API bindings generation

#1098
We fixed many issues in connection with REST API bindings generation. Generated code should now be correct and not dependent on the global Newtonsoft.Json settings. See also notes about breaking changes regarding this feature.

Fixed registration of viewmodules in markup controls

#1103
Viewmodules are now registered only for pages that have the @js directive. Previously the property that indicates whether a module is referenced could have been inherited by a markup control.

Fixed issue with indexing expression evaluating to null

#1120
DotVVM now generates expressions that are less strict whenever a null gets passed as an indexing expression, for example as a key to a dictionary. Instead of a compilation exception, it now propagates the null value as a result of the whole expression.

Fixed indexer's get method translation for dictionaries

#1121
We fixed an issue in the JavaScript translation for the indexer's get method for dictionaries.

Breaking changes

Behavior change after regenerating REST API bindings

Newly generated and regenerated bindings will have some changes. This is due to the fact that we had to update underlying Nswag version that changed the way API clients are generated. Most notably, there are the following differences:

  • HttpClient is now cached and passed as an argument for the API client's constructor
  • Generated code uses an ApiException instead of the previously used SwaggerException.

Users that do not regenerate their bindings are not affected by this change.

Tooling

Azure pipelines

#1067
Continuous integration system is now capable to run DotVVM tests both on Windows and Linux using newly defined azure pipelines.

Assets 2