Skip to content

Script Development / Code Planning and Organization

Script Sets, Scripts, and Functions should be organized logically rather than being randomly piled together. Proper organization of Script Sets and Scripts facilitates code maintenance and system efficiency.

1. Reasonably Divide Script Sets and Scripts by Purpose and Type

Generally, the following code organization methods are recommended:

  • Create separate Script Sets for business processing scripts by industry, project, or organization, such as: eShop, IoT, monitor, sales, marketing, etc.
  • When the code volume is large, divide scripts into low-frequency and high-frequency usage, such as prediction, advanced_prediction.

2. Calling Functions from Another Script

Scripts can be divided into different Scripts or Script Sets based on functionality and usage, and code in different Scripts can call each other. To call a function from another Script, simply import the corresponding Script.

When importing another Script, the following fixed syntax must be used:

Python
1
2
3
4
5
6
# import <Script Set ID>__<Script ID>
import demo__script

# Or use an alias to shorten the length
# import <Script Set ID>__<Script ID> as alias
import demo__script as script

In the Script editor, you can hover over the question mark icon in the left sidebar to directly copy the relevant statement.

If you need to export a Script Set, the other Scripts that this Script Set depends on must also be exported. Otherwise, the exported Script Set will not be able to run due to missing functions!

Scripts or Script Sets are not Python modules and cannot be imported using import.

However, DataFlux Func internally implements a dynamic loading mechanism and allows the use of import statements to load dynamic code. Therefore, the following syntax is incorrect.

Python
1
2
3
4
5
6
# Incorrect Syntax 1: Importing a Script Set as a module
import demo

# Incorrect Syntax 2: Importing a Script as a module
import demo.script
from demo import script

Additionally, when importing Scripts, be careful not to create circular references, such as:

Python
1
2
3
4
5
6
7
8
# Script script2 in Script Set demo
import demo__script2

# Script script3 in Script Set demo
import demo__script3

# Script script1 in Script Set demo
import demo__script1

Note that when editing multiple Scripts simultaneously, if the current Script imports another Script, the referenced Script will execute based on the published version. The system will never import a draft version!

3. Code Volume and Dependency Chain of a Single Script

Since DataFlux Func dynamically loads the required Scripts when running a Script, if one Script imports another Script, the imported Script will also be dynamically loaded.

Therefore, if certain functions in a Script are called very frequently, consider extracting them into a separate Script to reduce loading overhead. It is recommended to keep a single Script size under 1000 lines.

Additionally, avoid excessively long dependency chains, which can lead to unnecessary performance overhead, such as:

  • Script 1 depends on Script 2
  • Script 2 depends on Script 3
  • Script 3 depends on Script 4
  • Script 4 depends on Script 5
  • ...

Python built-in modules and third-party modules are not affected by this limitation.

4. Cases Where Scripts Are Not Divided

Although the above sections discuss the rational planning of Scripts and the methods for calling between Scripts, in certain specific cases (such as when the public functions used are very few and simple), you may consider not dividing Scripts and placing all the code in a single Script.

This approach, while introducing some redundancy, also brings additional benefits:

  • A single Script can run independently, reducing loading overhead
  • Not affected by changes in public functions
  • No need to consider dependency relationships when exporting Scripts

Choose the most reasonable method for planning Scripts based on actual circumstances.

5. Abbreviated References Between Scripts in the Same Script Set

Added in version 1.1.0rc51

Within the same Script Set, references between Scripts can omit the Script Set ID part (i.e., only write the part starting with __).

This facilitates correct internal function references even after cloning a Script Set and changing the Script Set ID.

For example:

Python
1
2
3
4
# Script: demo__utils

def echo(msg):
    return msg
Python
1
2
3
4
5
6
7
# Script: demo__test

# Equivalent to import demo__utils as utils
import __utils as utils

def my_func(msg):
    return utils.echo(msg)

6. Avoid Over-Encapsulation

Python is a multi-paradigm programming language, allowing both simple procedural programming and object-oriented programming.

However, in DataFlux Func, it is recommended to use a more procedural programming style for ease of debugging, avoiding over-encapsulation.

For example, the same functionality can be implemented in two different ways:

Python
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
import requests

# Procedural
def query_some_api(url, params):
    r = requests.get(url, params)
    return r.json()

# Object-Oriented
class APIQuery(object):
    def __init__(self, url):
        self.url = url

    def do(self, params):
        r = requests.get(self.url, params)
        return r.json()

def test_api_query(url, params):
    api_query = APIQuery(url)
    api_query.do(params)

In the above example, although both methods can achieve the same functionality, since query_some_api(...) is a directly callable function, it can be selected in the editor and run directly with parameters.

On the other hand, to debug and run the do(...) method of the APIQuery class, you must first instantiate an object, requiring the additional test function test_api_query(...) to call it.

Choose the appropriate method based on actual circumstances.