[XML] Update script behaviour, refactors #69

2023-05-13T14:34:25+08:00

thesabinelim commented

2023-05-13 14:34:25 +08:00

(Migrated from github.com)

Mostly refactors, but also 2 potentially controversial changes:

There can now only be one main script in a layout. I'm not sure why we ever needed to support more considering they all run during the same phase of a layout's render cycle
The script executes before the layout. This will break some existing functionality where it's possible to set properties of a component using imperative handles in the initial script. For example:

<script>
  testLabel:setText("New text")
</script>
<label id="testLabel" text="Old text" />

Will no longer work because testLabel hasn't been initialised yet when the script runs.

To solve this, use Reactive Properties instead, like so:

<script>
  shared.labelText = "This should work"
</script>
<label text={shared.labelText} />

IMO we should be moving away from imperative code in XML and leaning more heavily into a declarative approach. I guess this is the crossroads where we'll need to decide

The next PRs will take advantage of this new behaviour and demonstrate why this new approach is valuable

Mostly refactors, but also 2 potentially controversial changes: 1. There can now only be one main script in a layout. I'm not sure why we ever needed to support more considering they all run during the same phase of a layout's render cycle 2. The script executes before the layout. This will break some existing functionality where it's possible to set properties of a component using imperative handles in the initial script. For example: ```xml <script> testLabel:setText("New text") </script> <label id="testLabel" text="Old text" /> ``` Will no longer work because testLabel hasn't been initialised yet when the script runs. To solve this, use Reactive Properties instead, like so: ```xml <script> shared.labelText = "This should work" </script> <label text={shared.labelText} /> ``` IMO we should be moving away from imperative code in XML and leaning more heavily into a declarative approach. I guess this is the crossroads where we'll need to decide **The next PRs will take advantage of this new behaviour and demonstrate why this new approach is valuable**

🚀 1

thesabinelim commented

2023-05-13 15:34:07 +08:00

(Migrated from github.com)

Don't merge yet - fixing a bug

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GitHub/Basalt#69