feat: update new trigger modal according to design

[liweitian]

Description

Update according to new trigger design. Will replace the inline editor after it is done.

Task Item

Closes #1641

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

Checklist

• I have added tests that prove my fix is effective or that my feature works
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have functionally tested my change

Screenshots

Syntax Highlight & Completion

[github-actions]

Coverage increased (+0.02%) to 40.27% when pulling cc79ecb6e6aaab2e52136f7b76884b9bcb0f5d72 on liweitian/newTriggerModal into 4ea1b2a on master.

[a-b-r-o-w-n]

Some small changes.

[a-b-r-o-w-n]

The only other thing here is this odd spacing issue:

[cwhitten]

@liweitian I'd like to hold on this until we have the inline monaco editor to provide syntax highlighting and validation.

[yeze322]

Need some changes on code style

[boydc2014]

Inline lu lsp is in, please merge master and resolve all the comments

[yeze322]

code style & mock module.

[yeze322]

All my comments resolved! great 👍

stale

[cwhitten]

Something I'm seeing on this diff is that I can no longer toggle into "Edit" mode in the all-up LU page. We need to preserve the capability for users to see the "raw" lu data.

[cwhitten]

Let's convert this to a function component and use hooks instead of class methods.

I believe the getDerivedStateFromProps implementation is causing some unexpected behavior in editing the form. For example, data is getting overwritten at times, and I'm unable to add newlines to the bottom of an intent definition like I can in the inline LG editor. The behavior should be almost identical to the inline LG editor. See LgEditorWidget.tsx for its implementation. It should be used as a strong reference.

[alanlong9278]

As @yeze322 said,

This component has several problems. The usage of useEffect hook is anti-pattern meanwhile the data flow is not well designed (as an example, the onChange handler submits data to both local states and external API).

The props and local states are mixed together, makes your component hard to maintain.

You really need to rethink what's your scenario is and carefully define the shape of your input props to make sure you can fully leverage change detection mechanism.
Though state management of Shell has historical problems, you can try the Class Component with lifecycle methods before Leilei's fix on Shell states.
(I was also trapped in this problem before)

There is a bug about luEditor value in luEditorWidget: state localVale and props luIntent.body are mixed. So I try to use class component to fix it.
I fixed the bug: unable to add newlines to the bottom.

[cwhitten]

Understood. I cut this: #2138 to follow-up.

[yeze322]

Under current data flow, getDerivedStateFromProps can match weitian's scenario though it's still not a good pattern. Then we can optimize this pattern by following best practice.

A suggested pattern of this scenario is to use a fully uncontrolled component with a key (according to official doc). A key here might be the data version of current local state, requires more shell or indexer work.

@cwhitten I will follow up in the issue