[Query Builder] drag and drop refactor without DOM manipulations

[ivanvpetrov]

Closes #

Additional information (check all that apply):

• Bug fix
• New functionality
• Documentation
• Demos
• CI/CD

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code (test guidelines)
• This PR includes API docs for newly added methods/properties (api docs guidelines)
• This PR includes feature/README.MD updates for the feature docs
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes ng update migrations for the breaking changes (migrations guidelines)
• This PR includes behavioral changes and the feature specification has been updated with them

[desig9stein]

@ig-georgeA @andiesm813 @SisIvanova I have a question regarding the keyboard drag ghost element. In the previous implementation, we used the actual chip ghost element. However, in the current approach, we are using a standard chip with a class that attempts to mimic the appearance of the real ghost.

The issue is that the color variables and shadow styles are scoped to the real ghost element, which no longer exists. As a result, I am unable to access these variables, and I would prefer not to hardcode the chip’s colors within the query builder's context to achieve a realistic ghost effect.

Would it be acceptable to display only the drag handle outline while dragging with the keyboard? If not, can I make it look like the drop ghost placeholder when dragging with the mouse, but instead of placeholder text to have the actual chip content?

like on this screenshot

[andiesm813]

@ig-georgeA @andiesm813 @SisIvanova I have a question regarding the keyboard drag ghost element. In the previous implementation, we used the actual chip ghost element. However, in the current approach, we are using a standard chip with a class that attempts to mimic the appearance of the real ghost.

The issue is that the color variables and shadow styles are scoped to the real ghost element, which no longer exists. As a result, I am unable to access these variables, and I would prefer not to hardcode the chip’s colors within the query builder's context to achieve a realistic ghost effect.

Would it be acceptable to display only the drag handle outline while dragging with the keyboard? If not, can I make it look like the drop ghost placeholder when dragging with the mouse, but instead of placeholder text to have the actual chip content?

like on this screenshot

@desig9stein i dont understand why you are not using the chip ghost element that you were using previously. In the designs i worked on, there was no specified ghost chip.... i only see a "drop area" design.... but the ghost chip can look the way it used to look... that shouldnt change. Unless @ig-georgeA specified that elsewhere....

I'm not really sure what this state represents....

[ig-georgeA]

So the moment I start moving with the arrow keys it becomes the dotted style? I remember we kept the ghost style because it matches what it might look like when dragging with the mouse.

Furthermore, we needed an ENTER key press or some other event to commit the drag since just moving it was not committing it.

If I understood you @desig9stein , there is no "ghost" element when dragging wiht keyboard. Can we style the "insert here" chip to make it look like a chip being moved with drop shadow and all. But this style will only be shown for the keyboard drag and drop. When using the mouse, it will still be the dotted style coz at that point we have the ghost element at play.

[desig9stein]

@ig-georgeA My task here is to make it look the same as it does in the master branch. I’ve already hardcoded the same elevations as in the real ghost element. However, to fully match its appearance, I also need to adjust its colors. The shadows and colors vary across themes—for example, Bootstrap does not apply a shadow to the real ghost element.

If I don’t modify the color, only the drag outline will be visible during keyboard dragging in the Bootstrap theme. That said, I’d prefer not to hardcode the colors because if the user updates the real ghost colors/shadows, the fake one will not reflect those changes, leading to inconsistencies. Additionally, I’d like to avoid exposing new variables for the fake ghost chip within the query builder’s context since this will lead to problems when we scoupe the styles to the component in the near feature.

My questions are:

@ivanvpetrov – Can we bring back the real ghost element as it was before this refactoring?
@ig-georgeA @simeonoff – If Ivan’s answer is no, would it be acceptable to hardcode the colors/shadows to mimic the real ghost, knowing that users won’t be able to modify them by adjusting the real chip ghost colors/shadows?

[ivanvpetrov]

@ig-georgeA My task here is to make it look the same as it does in the master branch. I’ve already hardcoded the same elevations as in the real ghost element. However, to fully match its appearance, I also need to adjust its colors. The shadows and colors vary across themes—for example, Bootstrap does not apply a shadow to the real ghost element.

If I don’t modify the color, only the drag outline will be visible during keyboard dragging in the Bootstrap theme. That said, I’d prefer not to hardcode the colors because if the user updates the real ghost colors/shadows, the fake one will not reflect those changes, leading to inconsistencies. Additionally, I’d like to avoid exposing new variables for the fake ghost chip within the query builder’s context since this will lead to problems when we scoupe the styles to the component in the near feature.

My questions are:

@ivanvpetrov – Can we bring back the real ghost element as it was before this refactoring? @ig-georgeA @simeonoff – If Ivan’s answer is no, would it be acceptable to hardcode the colors/shadows to mimic the real ghost, knowing that users won’t be able to modify them by adjusting the real chip ghost colors/shadows?

@desig9stein This seems to solve the problem. What do you think?

	%filter-tree__expression-item-keyboard-ghost {
		.igx-chip__item {
			box-shadow: elevation(#{$keyboard-ghost-elevation});
                        ====> background: var(--ghost-background);
		}
	}

[ivanvpetrov]

Branch and PR remade in #15530. Closing this one