[Widget Params] Split title and mapping editing (2 of 3)

[ranbena]

This is the second of a batch of 3 commits that change UX of widget params.

Why?

Currently, there is one edit button per parameter, opening a popover that allows editing both source type and title. A better user experience is to have edit buttons per editable content - one for title, one for source type.

How it looks

Title edit

Source type edit

Implementation notes

Since now popovers open to the right of the content, affecting data as you type makes the popover jump horizontally as the position of the edit button shifts.
So, I implemented a "cancel/save" to each popover, hence the underlying table stays put during editing.

[ranbena]

This is so that if edit is cancelled (making state.mapping reset to original props.mapping), it would affect these input components, or else they would have stayed as left.

[ranbena]

Bye bye!

[ranbena]

Moved to getSourceTypeLabel

[arikfr]

@ranbena I can review this one directly instead of the previous one, right?

[ranbena]

Yeah, although it's still incomplete until the dependency is fixed.
And I need to rebase it.

[ranbena]

@arikfr ready!

[arikfr]

1.

I think it makes sense to use a wider Modal:

Update: I actually noticed we already use a wider one when you edit parameters.

2.

Instead of "Change parameter value" maybe "Set Parameter value"?

3.

When adding the widget to a dashboard with a static value it complaints that no value is set for param, while if you refresh it (with the refresh button) it works:

4.

(NTH)

When the Popover is open, clicking on Esc closes the Modal instead of the Popover.

5.

Completely unrelated but I think we should pin to top (along with the header) the parameters input. I added a new widget that takes a dashboard parameter, but the input was not even seen on screen. Feels a bit disorienting. I will open an issue for this.

6.

(should be fixed but not a blocker:)

1. Edit parameters of an existing widget.
2. Map it to a different parameter that has a different value.
3. The widget shows the old value. Expected: refresh and show value with the new parameter.

7.

We use the p_ prefix for all parameter in the URL, but for widgets we use only w{widget-id}_. Shouldn't it be p_w{widget-id}_?

[ranbena]

I think it makes sense to use a wider Modal:

My only reservation is that the above inputs (query and visualization) would be incredibly long.
Lemme think on this.

Instead of "Change parameter value" maybe "Set Parameter value"?

This is trampled in the next commit #3377.

When adding the widget to a dashboard with a static value it complaints that no value is set for param, while if you refresh it (with the refresh button) it works:

That's a bug on master. I'll open a separate issue. EDIT: #3379

When the Popover is open, clicking on Esc closes the Modal instead of the Popover.

Right. I'll have a separate PR to solve this with an Ant Modal. #3387
EDIT: seems it's unsolvable react-component/trigger#113 (comment)

(should be fixed but not a blocker:)

1. Edit parameters of an existing widget.
2. Map it to a different parameter that has a different value.
3. The widget shows the old value. Expected: refresh and show value with the new parameter.

Definitely a bug. I'll look into it. EDIT: fixed

We use the p_ prefix for all parameter in the URL, but for widgets we use only w{widget-id}_. Shouldn't it be p_w{widget-id}_?

Definitely. Will open a separate issue. EDIT: #3380

[ranbena]

Moved to #3332