Feautre/add input fields to searchbar #689
Conversation
…n about behaviour
…is triggered This let the user know, that this input is not displayed in the current search.
There was a problem hiding this comment.
I think the DatePickerComponent should be less concerned with the search bar functionality.
To keep up/down arrow navigation functionality I think it would be fine to use a capture phase event handler (https://svelte.dev/tutorial/svelte/capturing) in the search bar drop down to intercept up and down arrows before they even reach the text input using event.stopPropagation(). For numbers this would be fine in my opinion. I don't consider the up/down arrow to increment/decrement numbers important. I hope the date picker calendar arrow key navigation would not break.
I think you could use a similar strategy for detecting focus without touching the DatePickerComponent. Or alternatively just add a onfocus prop to the DatePickerComponent and handle everything else outside of the component.
|
|
||
| export default defineConfig([ | ||
| globalIgnores(["dist", "book/book", "docs/assets"]), | ||
| globalIgnores(["dist", "book", "docs/assets"]), |
There was a problem hiding this comment.
Generally I would want to lint the book markdown files. Can we fix the issues without disabling linting of those files completely?
There was a problem hiding this comment.
I agree. but book/book doesn't exist anywhere, so this was unnecessary, right?
There was a problem hiding this comment.
When you install mdbook and build the book locally it generates the HTML files there.
monitor performance with big catalogues
There was a problem hiding this comment.
The code in the search bar component looks much better now. And great that you added regex escaping to the search highlighting.
Do you think we can move some of the search bar and focus handling out of the input components? Maybe you can try my suggestion to intercept the arrow keys before the input components receive them. But I haven't thought a lot about that so I understand if you decide to stick with the current approach where you press escape to back out of the input component and then use the arrow keys.
| let inside: boolean = $state(false); | ||
| function handleClickInside(): void { | ||
| inside = true; | ||
| } | ||
| function handleClickOutside(): void { | ||
| if (!inside) { | ||
| autoCompleteOpen = false; | ||
| } | ||
| inside = false; | ||
| } |
There was a problem hiding this comment.
Are these click handlers needed? I tried without them and didn't noticed a difference
There was a problem hiding this comment.
Should have handled the click onto an input element of the options but didn't work because the inside check was missing in handleFocusOut(). Added it and now it works as intended: when the click is outside the form elements but still inside of the input element it won't close.
| } | ||
| let searchBarContainer: HTMLElement; | ||
| let optionsList: HTMLUListElement; |
| onmousedown={() => | ||
| addInputValueToStore( | ||
| inputOption, | ||
| extractTargetGroupFromInputValue(), | ||
| )} |
There was a problem hiding this comment.
Does this do anything? The NumberInputComponent adds the item to the query itself.
I'm always careful when it comes to altering browser native behaviour. the user will expect the form fields to work the same way throughout the application. if we make that change, the input will behave differently from the ones in the catalogue. also it's a behaviour known to users for as long as they use the internet 😅 But maybe the convenience for the user is high enough to make that change. I guess this would come down to a short user test. I will recruit some non-IT-people. |
I tried from the beginning and failed miserably 😄. 100% open to elegant solutions. |
I agree. In this case I think it might be worth it to prioritize the arrow keys but I'm not dead set on it.
I'd try to use a capture phase event handlers (https://svelte.dev/tutorial/svelte/capturing) on the input components to catch the |
|
@MatsJohansen87 could you check why this feature is not working on safari? On chrome it works fine |
Description
Add input fields to Search bar
Related Issue
#498
How Has This Been Tested?
UI user test