Filter tree item by tasks name and tasks states

[kinow]

These changes close #482

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Appropriate tests are included (unit and/or functional).
• Appropriate change log entry included.
• No documentation update required.

[codecov-commenter]

Codecov Report

Merging #483 into master will increase coverage by 0.30%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #483      +/-   ##
==========================================
+ Coverage   61.43%   61.74%   +0.30%     
==========================================
  Files          42       41       -1     
  Lines         918      941      +23     
  Branches       42       55      +13     
==========================================
+ Hits          564      581      +17     
- Misses        341      342       +1     
- Partials       13       18       +5     

Flag	Coverage Δ
#unittests	61.74% <66.66%> (+0.30%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/components/cylc/workflow/Lumino.vue	30.00% <ø> (ø)
src/components/cylc/tree/TreeItem.vue	69.23% <60.00%> (ø)
src/components/cylc/tree/Tree.vue	50.00% <67.56%> (+14.28%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 292d44e...349843b. Read the comment docs.

[kinow]

Aiming at keeping the state of each component instance well separated. First step was to remove the event bus that was shared by instances.

Then wrote the simplest approach to filtering I could think of. Not sure if the best, but testing against five, families2, and complex, might tell whether this performs good enough or not.

It is performing a simple if (haystack.contains(needle)), so searching for needle=oo in each of haystack=['foo', 'boo', 'snoopy'] returns true for all, so all the elements are returned.

I used a text field to test the filter, and will add some text boxes for the states. These are not the final UI elements, and are used only for development. Before merging will check with other what it should look like, and translate that into Vuetify and/or custom components 👍

[kinow]

Build passing, and filters working on five and with the one (offline mode).

Time to test with other workflows.

[kinow]

Worked OK with families2 and deeply nested family structure.

Also no problems that I could tell with complex. Actually, it is a relief to be able to filter that long list of items in the tree. And the memory of the browser tab kept about the same. I even had the impression it was a bit less, maybe for having less nodes to update?

[kinow]

Still need to write unit and functional tests, but before that, I think it'd be good to have more people testing it, so marking it as ready for review 👍

[hjoliver]

This seems to work well, even with two tabs of the complex flow (different filtering in each) 👍

I know the UI aspects are preliminary, so the following comments may be premature or useless!

• I think the "view toolbar" will need to stick to the top of the tab, not scroll with the view
• the only performance issue I noticed (with the complex flow): typing into the task name filter entry seemed a bit laggy
• task state filtering doesn't seem to work quite right, but that's probably because the datastore still has the wrong state info sometimes (since SoD on the back end). (Also worth noting that since SoD, some states - like succeeded - are mostly gone until we have n-distance windows and the UIS populating historical tasks that have left the scheduler task pool).

[hjoliver]

And:

• I'd expect hitting Return after entering a string would activate the filter (I was briefly confused that nothing was happening until I realized I had to press the Filter button)

[kinow]

Hi @hjoliver !

I know the UI aspects are preliminary, so the following comments may be premature or useless!

Definitely not useless. Not sure about premature, but I'm planning to improve the UI elements after I make sure I understand what it must look like with @oliver-sanders .

I think the "view toolbar" will need to stick to the top of the tab, not scroll with the view

Also think that'd be useful. Nobody wants to scroll all the way to the top to change the filter, over and over again. +1

the only performance issue I noticed (with the complex flow): typing into the task name filter entry seemed a bit laggy

That is probably due to the number of elements in the UI, not sure how much related to the filter. When I add a second tree view to the Lumino widget with complex, it also becomes laggy (master/this branch).

I'm hoping the improvements for the data store will improve performance for both the Lumino widget and for the filtering.

task state filtering doesn't seem to work quite right, but that's probably because the datastore still has the wrong state info sometimes (since SoD on the back end). (Also worth noting that since SoD, some states - like succeeded - are mostly gone until we have n-distance windows and the UIS populating historical tasks that have left the scheduler task pool).

Initially I was looking for running and succeeded, but it never matched anything. Then I realized I needed to match whatever as in the task states, not in the job. I spent some time confirming, and at least I think the filter is applied correctly against the states of tasks returned in deltas.

These may need some adjustments later.

Another thing too, is that I'm using a hard-coded list of states, from an Enum that we use in other parts of the UI. While at least this gives us a central list of states, we could also consider fetching the list of states when the application starts from the backend, or just reviewing if this Enum needs to be updated post SoD/deltas.

And:

* I'd expect hitting Return after entering a string would activate the filter (I was briefly confused that nothing was happening until I realized I had to press the Filter button)

Yup, the first version of the filters (from yesterday 😆 ) had v-on:key.enter I think, to capture the enter. I removed it after I added the combobox for task states. As it wouldn't be consistent?

Users could hit enter in the name. But what about the combobox? They would need to use the button. So would we have both, a button and support enter? Or just one option? In the end I went with one option only, the button to filter, to simplify, knowing that this wasn't the final UI.

So open for suggestions on how users should trigger the filter 👍 the effort to implement will be the same I guess.

Thanks a ton @hjoliver !

[hjoliver]

Another thing too, is that I'm using a hard-coded list of states, from an Enum that we use in other parts of the UI. While at least this gives us a central list of states, we could also consider fetching the list of states when the application starts from the backend, or just reviewing if this Enum needs to be updated post SoD/deltas.

We are heading toward the definitive list of task and job states as described here:

• task/job states - see New column
• New abstract task states

I'm pretty confident that those will stick - i.e. will change very infrequently if ever. Also, if the UI fetched a list of states from the back end and found a new one, it wouldn't know how to display it.

[oliver-sanders]

Looks good!

Unfortunately there still seems to be some interaction of trees for running workflows.

[hjoliver]

Unfortunately there still seems to be some interaction of trees for running workflows.

What's the interaction? (I've stared at your gif for a bit without seeing it!)

[oliver-sanders]

In the above demo I filter the left-hand tab to show only running tasks, which woks fine, however, as the workflow continues to run new running tasks do not appear in the filtered view (as they would if there were only one tab).

When I re-filter the left-hand tab later on it works again. It would appear that the presence of the second tab "freezes" the first?

[hjoliver]

Huh, you're right, good spotting.

[kinow]

Ops! Good catch!!!

It was due to how I defined the reactivity between the workflow tree, and the filters being re-applied. It was configured to react on updates to the tree object, which never (rarely?) changes, as instead we change parts of that object with deltas.

Fixed by defining deep: true. Performance should not be that great now. I have something my mind that I think could improve the performance of deltas being applied. Instead of applying deltas with reactivity on each element of the tree, I would like to try applying the deltas first in batch, then once the applyDeltas function is done, triggering the reactivity programmatically.

That way Vue should be less busy keeping track of heaps of Observer/Proxy/etc objects, and have more time to handle DOM/VDOM. But that's for later, unless the performance of the filters is not good enough here 👍

[kinow]

Ah! And on my computer, in development mode, the memory wasn't that bad, but I could tell there was a slight delay between updates to the filtered items, when comparing with the un-filtered three widget.

[hjoliver]

Forgot to mention above, we've also lost the "grey tree blank" (forgot what it's called!) pre-loading graphic, in the tabs.

[oliver-sanders]

(Because switching workflows is broken at the moment I can't test how the filters are effected by changing switching between workflows).

[kinow]

(Because switching workflows is broken at the moment I can't test how the filters are effected by changing switching between workflows).

Fixed in the last commit. Switching between workflows should be working now 🤞

Thanks!

[hjoliver]

Is this ready to go now @kinow ? (You haven't checked the "tests" checkbox in the description, or commented on tests?).

[kinow]

Is this ready to go now @kinow ? (You haven't checked the "tests" checkbox in the description, or commented on tests?).

Writing unit tests today, 50% done, just finishing the unit tests and then adding an e2e test.

[kinow]

Writing these tests I'm finding a few small issues. @oliver-sanders would it be OK if I asked you to review this one again, probably Monday your time, please?

The issues I found are no blockers, but I'd prefer to fix them as I'm writing the unit tests anyway. Example issues (some could have been introduced when I updated code to fix linter issues too):

• If you filter by name, then while workflow is running, type another task name, then the filter is active without pressing the Filter button
• If you type something in the states field, it autocompletes for you, but hitting enter results in a browser console error
• When running the filters, hitting clear may apply the filter without hitting the Filter button

I'm spending more time with unit tests, and intend to write only one or two functional tests. That's because we are using the simple input and combo box UI elements from Vuetify, and I'm not sure if they match our UI design, nor if they work well with mobile, theming, or if they would have to be changed after we add new Dot/Graph views, etc. So I'm guessing these could change later, so no point in writing a lot of functional tests 👍

(plus, you should be able to switch workflows by then too)

[kinow]

Most tests written, did some smoke tests, everything seems to be in order. But it's Friday 7PM, so this code comes with no guarantee 😁 will review the code, and probably write a few more tests to increase coverage on Monday NZ time. Then it should be ready for review after that 👍

[oliver-sanders]

@oliver-sanders would it be OK if I asked you to review this one again

No probs.

[kinow]

Last commit was to fix CSS styles. I was having a hard time looking at the button with a slightly different height than the other two input (text & select). Had to hard-set it to 40 (it's a number per the Vuetify docs, I simply matched the value from the input fields).

The right border of the Lumino Dock panel has always been hidden on master for quite a while, at least for my Chrome & Ffox Linux. Found out that it was due to the padding we were setting (found it comparing with Jupyter Lab). Not specifying a right padding appears to fix it 🤷‍♂️

On mobile, the three elements (text & select & button) get squeezed together. Might need to display one per line. But didn't want to spend too much time working on this UI as it may change later 👍 Just enough to calm down my OCD 😁

[kinow]

Ready for review! 🎉

[hjoliver]

(My usual mainly-functional review on this part of this system) - looks really good, further improvements can be follow-ups IMO. 👍

[dwsutherland]

Haven't delved into the code changes, but functionally it's a pass 🚀

[oliver-sanders]

Looks ok, unfortunately I've totally lost the ability to view workflows at the moment, can't even view them by URL now!

Most likely unrelated?

We've got two approvals anyway so happy for you to merge.

[kinow]

The issue might go away if you delete your node_modules and re-install with yarn install @oliver-sanders 🤞 but shouldn't be related to the latest changes I think.

[oliver-sanders]

Tried that I'm afraid, might have a go at debugging again today.