There's a buggy behaviour when switching from less selective slice to more selective one when we're outside of a new range:

Slice gets unselected after being edited:

Slices change order in the dropdown. I had test first and all after, then modified test and it became second

Should we sort them by name?

Thanks for the functional feedback, it was an oversight on my part.

I've solved the first 2 by:

• Resetting the dataset row number to 0 (well, 1) when applying a slice
• Selecting the new edited slice instance if it was selected previously

As for the sorting, I'm open to any solution (name or creation date). Sorting by name would still cause a move when editing the name, which we may want to avoid ?

I'll take a look at the code feedback tomorrow :)

Another general feedback: let's have a friendly message when you apply a filter that's too strict so that there are no matching rows instead of showing empty forms.

P.S.
no need to do it at midnight ;)

1. Let's limit the max height of a name element in the slice creation modal so that the update/cancel buttons don't disappear

2. Could you remove the autocomplete (control+space feature)from the code editor that results into a black horizontal line? Have a look at the monaco editor on test creation screen. Also I don't think we need an overview widget neither since the slicing functions will usually be small.

3. Minor improvement: could you add autofocus on "name" field when the modal opens? It could also be more intelligent and focus on name when you create a slice and code when you edit it

4. I'd make a distinction between an "Edit slice" modal title and the slice name itself, maybe print the slice name on a new line?
   

5. Long slice names break saving operation. There could be a character limit on the UI and validation on the backend to prevent it.
   

6. When playing with the feature I found it a bit long to navigate to slice editing, since I had to adapt my slice function frequently and see the results. I think we could remove 1 click by placing edit/delete icons next to the slice name in the list. Maybe in order to make the UI lighter we could only show these buttons for the slice that you've currently hovering over
   

General comment

I feel that it's a bit cumbersome to iterate while creating a slicing function. My workflow was:

• write a simple function
• check that it works (no syntax error, the resulting rows are the ones that I expected)
• modify the condition to make it more sophisticated

on each step, I had to close the modal and reopen it again. It's a bit disappointing, especially if there's a silly syntax error.

It could be great if we could quickly validate the slice function with a chosen dataset without leaving the editing mode.That was the idea behind the "Run" button on this mockup

Secondly, I might have missed some discussions last week, but I think slice creation being part of an inspection makes slices too hidden for users. It also unnecessarily requires a model to exist (without which you won't be able to create an inspection). In principle, a slice function should only require a dataset, so I think the previous location of the slice functions list (next to datasets) made more sense.

Hey Andrey, thanks for the feedback again.

I'll reply here to some of the points you mentionned:

4. Modal titles will be modified to "Editing slice" and "Creating slice", and the name will not be displayed. Since the name field is directly underneath, it just doubles the same information so it can be left out.

6 I agree with this too, using it yesterday made me realise it's not a good workflow currently.
I believe we could have a "Run" or "Validate" button that checks the code against a dataset, but I think having a small pen icon next to the "X" in the slice dropdown would allow for quicker access to editing it.
This way, a user will work on their code, validate it. When they want to test to see how many rows return, they can save. But then they have to open the dropdown, open the menu, open the modal.. Having a shortcut to the modal for the current slice would be nicer IMO.

As for your general feedback, we discussed it with Jean Marie and since Slices are (for now) only relevant for inspections we decided to put them there. With a future version having a test catalogue, we imagined we could have a "function catalogue" that works in a similar way, with slicing functions, perturbation functions and other types as the product evolves.

There is an in-between then and now that we need to figure out if the dropdown solution isn't good enough for now, that's for sure

ack, we discussed it with Jean Marie and since Slices are (for now) only relevant for inspections we decided to put them there. With a future version having a test catalogue, we imagined we could have a "function catalogue" that works in a similar

I agree with both solutions you proposed for 4 and 6. As for the definitive place for the slices list, lets keep it inside inspection for now, but keep the "General comment" in mind for the moment when we start using slices in tests too.

I'd still enhance the slice editor to be able to try to run it on a dataset directly without leaving the editor

Small todo for myself, increase slice name length limit, too restrictive atm

@Googleton , could you have a last look at Sonar results? I don't think everything's coming from your changes though...

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

3.5% Coverage
0.0% Duplication