We'll publish these release notes for versions that deserve more explanation than short descriptions available in our change log.
The Serenity.Pro.Coder package, which includes four source generators, is now enabled by default in projects created from StartSharp template v6.1.9 and onwards.
These source generators provided by Serenity.Pro.Coder perform tasks similar to those of sergen's mvc, clienttypes, and servertypings commands, eliminating the need for manual execution or project rebuilding. Additionally, a RowFields source generator is included, reducing the amount of code required when defining or modifying row classes.
All of these source generators seamlessly function within Visual Studio (and Visual Studio Code) as you make changes to your C# and TypeScript classes. There is no need for a repetitive cycle of modification, building, transformation, use of generated code, and rebuilding.
For more information on our source generators, please visit our blog post https://serenity.is/blog/2022/10/09/source-generators.
In very old Serenity versions (before 2.9.10, approximately 6 years ago), we used the JSRender library for dialog and other templates, utilizing double-brace placeholders like {{text:Some.Text}} (https://www.jsviews.com/).
We believe that this approach has not been in use for quite some time, but we retained it in our corelib code for compatibility reasons. However, we are now removing the Q.jsRender method and support for legacy syntax like {{text:Some.Text}} in our dialog templates.
If you are still using this format in your older applications, we kindly request you to update your templates to a modern style within your DialogClass's getTemplate method, as demonstrated below:
class SomeDialog {
getTemplate() {
return `<div>${Q.text('Some.Text')}</div>`;
}
}We have a TemplatedWidget class, which also serves as the base class for TemplatedDialog, PropertyDialog, EntityDialog, and more.
This class includes an idPrefix property generated from uniqueName + '_'. We are now moving it up to the Widget class, enabling its usage in other widget classes that do not inherit from TemplatedWidget.
This change should not cause any disruptions but allows us to utilize idPrefix in widgets that do not require a templating system.
We have introduced a method named renderContents in the Widget class. This method initially has an empty body but can be overridden by derived classes. For instance, TemplatedWidget now overrides this method to apply its template to the widget's element, a task that was previously handled in the constructor of TemplatedWidget.
This addition is not expected to break existing code. The purpose of this new method is twofold:
- Derived classes can render their contents by overriding this method, potentially using innerHTML, React, and more, without needing to modify the constructor.
- Subclasses of
TemplatedWidgetcan entirely disable the templating system by overriding this method and leaving it empty or not callingsuper.renderContents().
Please note that we are gradually working towards removing legacy template mechanisms, especially those that involve template files (e.g., .ts.html), but we must retain the TemplatedWidget class for compatibility reasons.
Around 6 years ago, in Serenity 2.1.3, we introduced a configuration option for responsive dialogs in Q.Config. Newer applications could enable responsive dialogs, providing better layouts for mobile devices, by setting this option to true. However, the default value was false to maintain compatibility with legacy applications using alternative methods.
Newer Serene and StartSharp applications included a line in their ScriptInitialization.ts to set this option to true:
Q.Config.responsiveDialogs = trueGiven that legacy non-responsive dialogs are no longer widely used, and their CSS might not function correctly, we have changed the default value to true. This change might impact very old applications, although likely none, as they can easily set Q.Config.responsiveDialogs = false in their ScriptInitialization.ts to revert to the legacy default.
Other applications can remove the aforementioned line in ScriptInitialization.ts, as it represents the default setting in Serenity.Scripts 6.0.9 and onwards.
We intend to eliminate this flag entirely in the future. If you still rely on non-responsive dialogs, please inform us through Serenity discussions.
Previously, scattered throughout StartSharp, particularly in membership-related code, we had code similar to the following:
return Q.format(Q.text('Validation.MinRequiredPasswordLength'), 7);The Q.text function allowed us to obtain localized text by its key, but it lacked IntelliSense support. Fortunately, sergen (and now source generators) generated a Texts class to provide strongly typed access to local texts. Consequently, we have started employing this approach in our code wherever possible:
return Q.format(Texts.Validation.MinRequiredPasswordLength, 7);If you've upgraded your project to version 6.1 or higher using stargen or a manual method, you're likely aware that we've adopted modular TypeScript and have configured esbuild via package.json and a tsbuild.js. In the future, we'll move tsbuild.js itself into an npm package once it stabilizes. However, for now, we have to apply fixes to tsbuild manually or via stargen.
We'll also be adding an auto-watch feature (for now, you have to manually run
node tsbuild --watchin the console to compile on save).
If you don't have any modular TypeScript files in your projects (which can happen during the initial migration), you might encounter an error from esbuild during the build process because the output directory doesn't exist (there's nothing to output).
To address this issue, we've made the following change:
if (!outputs)We've replaced it with:
if (!outputs || !existsSync(build.initialOptions.outDir))
return;During the transition to modular TypeScript, the registration of the Serenity.SummaryType enum was inadvertently lost in recent releases. If you've used this enum and encountered an error, you can resolve it by updating to version 6.1.8 or later.
When an error occurs during an AJAX call and the server returns some HTML, we use Q.iFrameDialog to display the HTML. However, in recent versions, it experienced a script error when Bootstrap dialogs were enabled, preventing the proper display of the error. This issue has been resolved.
Due to the way we inject the TypeScript library (tslib.js) into our Corelib, the source mapping indexes were shifted before. When debugging in Chrome, etc., with source mapping enabled, you would receive invalid stack traces. Setting breakpoints would often lead to unrelated code being marked in TypeScript. This issue has been resolved in version 6.1.8.