Execute Script V2 - UX #15461
Execute Script V2 - UX #15461
Conversation
…script-v2-frontend
…script-v2-frontend
|
QA Wolf here! As you write new code it's important that your test coverage is keeping up. |
…script-v2-frontend
…script-v2-frontend
…ready. Passing uninitialised stores to the derived store was causing issues
…script-v2-frontend
…script-v2-frontend
…script-v2-frontend
…ly. Rows were being misrepresented as 'Multi Select'
…script-v2-frontend
…script-v2-frontend
…script-v2-frontend
…script-v2-frontend
…script-v2-frontend
…script-v2-frontend
…script-v2-frontend
There was a problem hiding this comment.
Awesome work Dean - this is a massive improvement. It worked flawlessly and passed all my checks:
- All bindings work
- Helpers work
- Snippets work
- Full evaluation context
I've noted a few minor code things but nothing major.
One question I do have - it looks like you made changes to the existing binding panels, but then ended up making your own one (CodeEditorField)? Was it not possible to reuse the existing components for this use case? It's totally fine if not, I just noticed there's a fair bit of duplication between BindingPanel and CodeEditorField which might make maintenance harder in future.
| @@ -140,6 +144,7 @@ | |||
| ? [hbAutocomplete([...bindingsToCompletions(bindings, codeMode)])] | |||
| : [] | |||
|
|
|||
| // TODO: check if it inputData != newInputData (memo) | |||
There was a problem hiding this comment.
Not sure if these are done and left in by accident, or still need done, so just flagging them!
| @@ -156,6 +161,7 @@ | |||
| } | |||
|
|
|||
| const setDefaultEnumValues = () => { | |||
| // TODO: Update this for memoisation | |||
| @@ -71,6 +69,10 @@ | |||
| let expressionError: string | undefined | |||
| let evaluating = false | |||
|
|
|||
| // Ensure these values are not stale | |||
| $: jsValue = initialValueJS ? value : null | |||
| $: hbsValue = initialValueJS ? null : value | |||
There was a problem hiding this comment.
I'm a little apprehensive about this change just because it's so core, but I can't see any immediate issues with it. Right now this component is intended to be in charge of it's own value after mounting, which is why none of the initial value variables here are dynamic.
I'm not actually sure how this makes a difference, because initialValueJS itself is not reactive and is only set once on mount, so I can't see how making the assignment of jsValue and hbsValue reactive would change functionality. They would re-evaluate when value changes (but they are also updated by the component itself further down on chance), probably causing a wasted double update, but they reference initialValueJS which means they could potentially incorrectly set a JS value into HBS and vice versa if the current mode is different to the initial mode.
There was a problem hiding this comment.
@aptkingston and I discussed this and decided that the more appropriate approach to this was to better manage the state on blur for the editor field, rather than make a global change to the reactivity of the base editor values.
Updated behaviour: #15545
Thanks again for taking a look! Yep, regarding the |
…omponent to ensure they are kept in sync
Pull out new code editor field and drawer bindable slot into single component
…script-v2-frontend
…script-v2-frontend
Description
UX updates to accomodate the new version of the
JavaScriptautomation type.JavaScriptstep type (EXECUTE_SCRIPT2)CodeEditorField- extracted theCodeEditorUX from deep with theBindingPanelso that it can be used as a standalone UX. Supports JS only for the momentCodeEditorin theBindingPanelentirely. That is beyond the scope of this ticket.Update Rowbinding UX switched back from modal to drawer mode to keep it in line with the other steps.Trigger,User,StepandSettingsdata. When selecting a suggestion in the dropdown, it will display any available data in the UI!JavaScript(EXECUTE_SCRIPT) step has been deprecated. Any automations still using the legacy step will function as before and no action is required.Fixes
Fix- Binding icons inAttachment|Signaturedrawers were all defaulted toShareAndroid. They reflect the correct category now.Fix- Timing issue with the Bindable drawer across the builder.CodeEditorwould get stuck with the initiating value. This caused a timing issue for all bindable inputs if they had an "update on blur" UX.Fix- Added support for using spaces when configuring fields forApp Actiontriggers. This has been an annoyance for a while.My fieldencodes astrigger.fields.[My field]and is displayed astrigger.fields.My field.Fix- Blurring a field name input in anApp Actionstep, without altering it, would trigger an empty update and throw an errorFix- Webhooks that have no test data would throw errors when modifying.Fix- Minor adjustment to theApp Actiontrigger field UX adding a little flexibility when configuringFix- Addedtableparameter to theRow actionin the test endpoint as it was missing from the test results.Fix- Automation icons panel was displaying the incorrect icons. The list would display the icon associated with the first automation in the group. Now they reflect their corresponding automation definition typesFix- Row types mislabelled as 'Multi select' in the bindings drawer.Addresses
Screenshots
JavaScript V2 UX. The code is directly visible and editable in the step, with suggestions and snippets . Suggestions will also render/evaluate any data in your test results or some default data
Live binding evaluation in all fields!
Launchcontrol
Automation Execute Script V2 and general Automation fixes
Feature branch env
Feature Branch Link