Copilot Custom Component support, phase 2

[emarc]

Description

Phase 2 of better support for custom components and composites in Copilot.

Includes

• (Drag &) Drop improvements
• Editing of (simple) properties such as text
• Better handling of components that extend a base-class
• Better handling of the "top-level" component (extended or Composite)

Tier

Plus

License

Proprietary

Motivation

Background

With "custom components" (and composites) we mean essentially all components in the project that are not part of the basic OOTB Vaadin component set.

In 24.7 we released improvements for how custom components / composites are handled.
This is a continuation of features that were not finished, or that we've gained a better understanding of.
This will still not completely exhaust the problem space, but is a big step forward.

Problem

Custom components and composites have custom API and custom “slots”/areas for components. In addition, many employ base classes. Copilot needs to clearly show what is being edited so shared files are not accidentally changed. When there are limitations, those need to be indicated.

Solution

• Drop improvements

  • Better handling of types. Check which setters are compatible, and display accordingly.
    • When dropping an Image, setImage(Image) and setContent(Component...) should be shown. When dropping a Button, setSaveButton(Button) and setContent(Component...) should be shown. When dropping a Div, only setContent(Content...) should be shown.
  • The drop-popup (and properties panel) should be able to take multiple components one at a time (add vs replace) when the method accepts multiple components.

• Text edit improvements

  • Simple text properties should be easy to edit, e.g. double-click on title to edit (setTitle(String))
  • (Properties panel is a separate PRD)

• Base classes

  • When a custom component extends a (custom) base-class.
    • Basic features should work as expected, i.e. not throw :-)
    • Don't allow accidental edits of base class.
    • Only allow selecting parts that can be edited from the subclass (i.e. that can be directly accessed) = "configure" components from the baseclass.
    • Do not show parts that cannot be edited in the outline.
    • Only parts that are attached in the subclass can be moved (drag & drop) in the subclass.
    • -> This means the base class cannot be edited with Copilot (for now)
  • TODO We have some user-provided cases; link here and make sure to address.

Notes

At this stage, we're still aiming to provide a "universal" solution that supports as much as possible w/o requiring anything from the creator of the custom component. Thus we're choosing to first create the easier, more complete solution (e.g properties panel) in favor of the more fancy solution (e.g direct manipulation, custom drop-zones, custom property editors).

Requirements

• Dropping a component on a custom component should show compatible methods
• Dropping component on custom component should allow add/replace for methods that accept multiple
• Double-clicking on simple text properties in custom component should allow edit of that property
• If the custom component extends a base class, allow configuring components that the subclass has access to

Nice-to-haves

Risks, limitations and breaking changes

Risks

Handling of base classes is potentially both a UX and a technical problem.

Re-ordering of components when dropping needs UX design, and it might turn out it's not worth the effort when considering usefulness.

Limitations

Double-click to edit text can be difficult: there are many cases, we should handle easy/reasonable ones and aim to clearly indicate what can be edited vs not. This is hard to define up front, we'll have to choose what is reasonable on a case-by-case basis.

Base classes CANNOT be edited.

Breaking changes

(should not have breaking changes)

Out of scope

Custom dropzones are not part of this PRD.
Base classes for custom components handled with drill-down pattern.

Materials

No response

Metrics

• Usage statistics

Pre-implementation checklist

• Estimated (estimate entered into Estimate custom field)
• Product Manager sign-off
• Engineering Manager sign-off

Pre-release checklist

• Documented (link to documentation provided in sub-issue or comment)
• UX/DX tests conducted and blockers addressed
• Approved for release by Product Manager

Security review

None

[MarcinVaadin]

Double-clicking on simple text properties in custom component should allow edit of that property

It is impossible to match String value with proper API call. Let's imagine having code as:

String aStringVariable = "Header Title";
AcmeHeader header1 = new AcmeHeader();
header1.setTitle("Header Title");
header1.setButtonTitle("Another title");
header1.setTitle2(aStringVariable);
header1.setTitle5("Header Title");
add(header1);

There is no way to know which setter to use. In case of Vaadin components with slot names, we are already mapping them to proper setter methods. There is no such option with custom components.

[Artur-]

What is it impossible? You have the DOM node with the text and need to figure out which setter affects that DOM node. The case is pretty much the same as with TextField when double clicking on a label or a helper text.

[MarcinVaadin]

What is it impossible? You have the DOM node with the text and need to figure out which setter affects that DOM node. The case is pretty much the same as with TextField when double clicking on a label or a helper text.

Agreed to base that feature on available properties that are matched by value.