Release Notes / Version 11.2301
Table Of ContentsIn the 2207 Blueprint workspace, certain TypeScript source patterns have been simplified. The changes described below can be applied automatically by a tool CoreMedia provides. To do so, make sure your CoreMedia Blueprint workspace is in a clean VCS state. Then start by enabling all extensions:
cd workspace-configuration/extensions mvn extensions:list -DextensionsFile=extensions.txt mvn extensions:sync "-Denable=*"
Now invoke the new source code update tool:
cd ../.. cd apps/studio-client pnpm install pnpm dlx @coremedia/studio-client.tools.update-ts-source-code@~1.0.0
Restore the state of any previously disabled extensions:
cd ../.. cd workspace-configuration/extensions mvn extensions:sync -DextensionsFile=extensions.txt rm extensions.txt
Add and commit all resulting changes with an appropriate commit message. Now, the number of possible conflicts in Studio Client TypeScript code when merging with CoreMedia Blueprint AEP 2207 is reduced drastically.
The following sections describe the improved TypeScript syntax that the tool applies and that should be used when you write Studio TypeScript code from now on.
Since version 4.7, TypeScript fully supports ECMAScript class static blocks, so the workaround syntax using a private static field with an "immediately evaluated function" (IEF) can now be simplified.
Before:
class Foo { static #static = (() => { console.log("Foo is being initialized!"); })(); }
After:
class Foo { static { console.log("Foo is being initialized!"); } }
In Ext JS, it is often required to use
this
in the constructor before calling
super()
. According to ECMAScript and thus TypeScript class semantics, this is not allowed and results in an error.
To still be able to use TypeScript classes for Ext JS development, we found a workaround described in the following. Assume there is a class
Bar
with a constructor that takes a string and a boolean, an Ext JS subclass could look like so:
class Foo extends Bar { #field: string; constructor(a: string) { super(...(() => { /* all code accessing 'this' before 'super()': */ this.#field = a; // super args must be returned and spread ('...'): return [a + "!", this.#compute()]; )()); /* code after super call: */ console.log(this.#field); } #compute(): boolean { ... } }
The pattern is slightly simpler when there is just one super call parameter, but is still hardly comprehensible and cumbersome to write.
The new workaround that reads and writes simpler is to define an alias for
this
and use
@ts-expect-error
to ignore the resulting error exactly in that line. The new syntax for the code above looks like so:
class Foo extends Bar { #field: string; constructor(a: string) { // @ts-expect-error Ext JS semantics const this$ = this; // same code as inside the IEF with every 'this' is replaced by 'this$': this$.#field = a; // normal super call: super(a + "!", this$.#compute()); /* code after super call: */ console.log(this.#field); } #compute(): boolean { ... } }
(CMS-21747)