Expression

Expressions are one of the core concepts in WeDa applications, widely used in various scenarios such as output parameters, input parameters, property bindings, etc. The expressions used in WeDa applications are JavaScript expressions, and valid JavaScript expressions are valid WeDa expressions. It should be noted that the restrictions on JavaScript in WeChat Mini Programs still exist in WeDa. Therefore, if you wish to smoothly support Mini Programs, it is necessary to avoid using code such as eval and new Function in your programming.

Expressions in Applications

In WeDa applications, all locations supporting expression binding feature either an fx marker or {{ }} placeholder. Common expression usage scenarios include:

• Property binding, most commonly seen in the binding of component properties (props)
• Binding of action input parameters in events (including event flows)
• Input parameter binding in Weida data tables and APIs query
• Use expressions within the expression placeholders {{ }} in MySQL queries

For specific productized usage, please refer to: https://cloud.tencent.com/document/product/1301/86577

WeDa APIs

WeDa has built-in rich client APIs for use in expressions or other custom code. All built-in APIs in WeDa reside under the $w namespace, and in addition to the namespace, certain scopes are also referenced via $w.

When binding expressions, the following rules must be observed:

1. Use synchronous expressions instead of asynchronous
2. Use side-effect free expressions
3. Use expressions instead of statements

Outside of binding expressions, code in lifecycle, page handlers, and global common are JavaScript modules, allowing for more complex code logic without being constrained by expression rules.

Synchronous Expressions

In scenarios where expressions are used without explicit declaration, synchronous expressions are required, meaning expressions that return results immediately. Asynchronous expressions that require waiting for a Promise to resolve may not function properly during binding.

For example, WeDa provides two APIs to get user information: $w.auth.currentUser and $w.auth.getUserInfo(). If you want to display the user's nickname in a text component:

• Text content property can be directly bound to the synchronous expression $w.auth.currentUser.nickName ✅
• But it cannot be bound to the asynchronous expression $w.auth.getUserInfo().then(user => user.nickName) ❌

Similar asynchronous APIs in WeDa include $w.cloud.callDataSource, $w.cloud.callWorkflow, and $w.cloud.getTempFileURL. If you wish to bind these asynchronous results, currently you need to use a variable as a synchronous expression for intermediate processing.

Side-effect Free Expressions

Every valid expression evaluates to some value, but conceptually, there are two types of expressions: those with side effects (e.g., assignment) and those that merely compute a value.

Although WeDa does not strictly enforce binding expressions with or without side effects, it is recommended to always use side-effect free expressions. This is because in common scenarios like binding expressions to component properties, the execution timing of expressions is complex and relatively unpredictable. Untimely invocation of expressions or APIs with side effects may lead to unexpected abnormal behavior.

Some APIs in WeDa have side effects:

• Update variables: $w.app.setState, $w.page.setState
• Data source or workflow invocation: $w.cloud.callDataSource, `$w.cloud.callWorkflow
• Trigger query or eventflow: $w.query1.trigger, `$w.eventflow1.trigger
• Most component methods: $w.input1.setValue, $w.listView1.refresh, etc.

Expressions and Statements

Expressions and Statements

expression is a set of code that returns a value.

A JavaScript application is composed of many syntactically correct statements. A single statement can span multiple lines. If each statement is separated by a semicolon, multiple statements can appear on a single line.

A common mistake beginners make is treating ordinary JavaScript statements as expressions, which can lead to abnormal situations. Below are some common examples of treating statements as expressions:

Example 1: Construct an array

Constructing an Array

// Bad ×
// Multi-line statements are not expressions and do not return a value
let list = [];

$w.query1.data.records.forEach((item) => {
  list.push(item);
});

Use map or reduce for array operations

// Good √
$w.query1.data.records.map((item) => {
  return item;
});

Example 2: Construct an option for the Universal Chart (echart)

raw echat option

// Bad ×
// echat's option assignment statement
// Assignment is an expression but has side effects, and terminated with a semicolon indicates it is a statement.
option = {
  xAxis: {
    type: "category",
    data: ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
  },
  yAxis: {
    type: "value",
  },
  series: [
    {
      data: [150, 230, 224, 218, 135, 147, 260],
      type: "line",
    },
  ],
};

Directly use object literal expressions

// Good √
{
  xAxis: {
    type: 'category',
    data: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun']
  },
  yAxis: {
    type: 'value'
  },
  series: [
    {
      data: [150, 230, 224, 218, 135, 147, 260],
      type: 'line'
    }
  ]
}