Search panel update should be non-destructive (was: Deleted search text returns unexpectedly)

[ColmDC]

Describe the bug Deleted text in the seach box reappears if you change a filter option

To Reproduce Steps to reproduce the behavior: Watch this video Play

Expected behavior When you change the filter selection changed search text should be used in the new filter/search request.

Desktop (please complete the following information):

• Windows 10
• Firefox
• mykomap@3.0.4_1c2336e-modified-dev

Additional context Add any other context about the problem here.

[wu-lee]

Managed to reproduce and fix this. Fix will be in v3.0.6

The search is executed only on submission of the text-search form (i.e. when you hit enter).

This means that the search has not happened yet if you don't submit it. Changing the filters re-applies all the search steps, including the search, and resets the text to the search text used, which has not changed.

The fix works by submitting as soon as the text input focus is lost, i.e. as soon as you leave the search box, perhaps to click a drop-down. Therefore the reset happens as before, but it resets to the newly searched text.

[wu-lee]

Fix can be tested here:

https://dev.maps.solidarityeconomy.coop/obo-public/

[ColmDC]

This does address the symptom, but it still feels wrong. If you type a term to search and then click on a filter, you see that the text search happens, but then your click on the filter gets ignored, so you need to click again. Needs a little thinking...

[wu-lee]

Ok, so I've attempted to stop that happening. There's a problem, which might be solvable but probably requires rewriting the way the sidebar, or at least the search panel, refreshes itself. The workarounds I can think of would have similar funny bugs, like the original state did. The UI would not be reflecting the search properly, or vice versa.

Background: there is a composite filter operation, made up of (maybe) a text filter and (maybe) some property filters. Whenever this is changed, the visible initiative list is regenerated, and the sidebar is redrawn with the search text, and the filters showing the available options which remain selectable given this new smaller list of visible initiatives.

What used to happen:

• User alters search text, but doesn't submit
• User clicks on a filter dropdown, opening it
• User selects a filter option which isn't greyed out
• This changes the composite filter and so triggers a redraw for the new list of initiatives
• The search text is reset to the value used in this filter - the old search text.

What happens now

• User alters search text, but doesn't submit
• User clicks on filter drop down
• This triggers the search filter first. By updating the current composite search to include this new text first, we prevent the UI getting reset to the older search text later when the drop-down is changed.
• But this this change also triggers a redraw, necessarily, so that the narrowed options are shown correctly. Not doing this would mean the UI allows more than it should.
• The redraw recreates the sidebar, deleting the opening drop-down and redrawing it closed.

To the user, this looks like the filter drop down opening for an instant, then getting closed.

The problem is the redraw deleting the whole panel and redrawing it from scratch. If the there are filters open, they are replaced with something that's lost its open state.

I think what might work correctly would be to just update the drop-down options in a non-destructive way, without redrawing the whole thing from scratch. But that means redesigning the search panel UI logic in a major way. Doable, maybe within a few hours to a day or so - so a bit expensive, and may create more bugs.

Is that warranted now?

[ColmDC]

Clear explaination. Full fix not worth it atm. Shall we change the title to refeflct the new symptom, and move this back into the backlog for the moment?

[ColmDC]

No longer a problem after the major reworkings of the search panel by mykomap@3.1.7