Firing dropdown using external button and overwriting search method

aks1994 commented 6 years ago

Hi, thanks for making this component.

Just have two questions:

Is it possible to fire the dropdown using an external button? When I click on the external button, I want the dropdown to open automatically and the cursor to be positioned on the search
I was hoping to use a more dynamic search method, for example ('dy ea' should return 'dynamic search' as a result). Basically you don't need to enter a single search term. I have my own implementation of this search but am not sure how I can overwrite the existing search. I think I can use the (typed) event to start filtering the list, but it still uses default search so limits the results that are shown

optimistex commented 6 years ago

Hi, thanks for making this component.

You are welcome! I glad that it is useful for you.

Is it possible to fire the dropdown using an external button? When I click on the external button, I want the dropdown to open automatically and the cursor to be positioned on the search

Currently, no, it is not. But, check the comment and vote for if it is okay for you: https://github.com/optimistex/ngx-select-ex/issues/32#issuecomment-370539352

I was hoping to use a more dynamic search method, for example ('dy ea' should return 'dynamic search' as a result). Basically you don't need to enter a single search term. I have my own implementation of this search but am not sure how I can overwrite the existing search. I think I can use the (typed) event to start filtering the list, but it still uses default search so limits the results that are shown

It seems we have to add an external callback for custom filtering the search. Something like a [searchCallback] which waiting for the function:

   @Input() searchCallback: (search: string, source: string) => boolean;

aks1994 commented 6 years ago

Currently, no, it is not. But, check the comment and vote for if it is okay for you: #32 (comment)

Okay I will vote. Yes, making the optionsOpen() and optionsClose() public would be very helpful

It seems we have to add an external callback for custom filtering the search. Something like a [searchCallback] which waiting for the function:

@Input() searchCallback: (search: string, source: string) => boolean;

Yes, this would be great if possible. Can I request this feature?

optimistex commented 6 years ago

Do not close the thread. It is like a little task for me. When I'll have a free time I'll do it.

aks1994 commented 6 years ago

Okay, that was accidental. Reopened.

Thanks, really appreciate it!

optimistex commented 6 years ago

All that is you ask seems does not difficult for implementation. And. I did it but did not test. For details check the commit: https://github.com/optimistex/ngx-select-ex/commit/72adfd1356c85699ddf4d7e027b0ec45d38af144

Install: npm i ngx-select-ex@dev

Please keep in touch and let me know how it works.

aks1994 commented 6 years ago

Ok great, that was fast! Thanks, I will test it out in the next day or so and let you know.

aks1994 commented 6 years ago

So I've been testing both changes, and overall they are working well. Thanks again for the quick help!

Just a couple notes/questions:

For optionsOpen(), I am able to access it now. However, if I am using an external toggle, it does not work because I think it also registers the document click and auto closes it. On examining the DOM elements, that's what seems to be happening - the options html shows and gets removed instantaneously. The (open) event is also fired. I can still use this new functionality if I want the options to show by default on ngOnInit, but I would like to hide the ngx-select component entirely and only show it upon a button (and open as default). So any suggestions there?
For search, it is working as expected and I am able to overwrite the default search fine. In your current implementation, the matching characters are in bold and I'm not sure if we will be able to maintain the same functionality for the new search. Currently, if I use my search, the bold effect will work as long as the option was in the search results of the default search as well. Eg: For 'abc def', the 'ab' will be highlighted if search term is 'ab', but if I search 'ab de', this will still have 'abc def' in my search results. But no characters will be bold because this would not have been an option in the default search. I think that it might be tricky to get the characters bold if search is overwritten, so my suggestion is to have the bold option entirely disabled if search has been overwritten.

optimistex commented 6 years ago

For optionsOpen(), I am able to access it now. However, if I am using an external toggle, it does not work because I think it also registers the document click and auto closes it. On examining the DOM elements, that's what seems to be happening - the options html shows and gets removed instantaneously. The (open) event is also fired. I can still use this new functionality if I want the options to show by default on ngOnInit, but I would like to hide the ngx-select component entirely and only show it upon a button (and open as default). So any suggestions there?

Bad but fast solution:

setTimeout(() => this.ngxSelect.optionsOpen(), 0);

Later I'll figure out how to do it better.

optimistex commented 6 years ago

For search, it is working as expected and I am able to overwrite the default search fine. In your current implementation, the matching characters are in bold and I'm not sure if we will be able to maintain the same functionality for the new search. Currently, if I use my search, the bold effect will work as long as the option was in the search results of the default search as well. Eg: For 'abc def', the 'ab' will be highlighted if search term is 'ab', but if I search 'ab de', this will still have 'abc def' in my search results. But no characters will be bold because this would not have been an option in the default search. I think that it might be tricky to get the characters bold if search is overwritten, so my suggestion is to have the bold option entirely disabled if search has been overwritten.

We need to figure out how to take it out: https://github.com/optimistex/ngx-select-ex/blob/c594c42de3992a57204f208dc7cb8051a8232ec5/src/app/lib/ngx-select/ngx-select.classes.ts#L28-L30

The code called from there: https://github.com/optimistex/ngx-select-ex/blob/c594c42de3992a57204f208dc7cb8051a8232ec5/src/app/lib/ngx-select/ngx-select.component.ts#L363-L366

aks1994 commented 6 years ago

Bad but fast solution: setTimeout(() => this.ngxSelect.optionsOpen(), 0); Later I'll figure out how to do it better.

Thanks, works for now.

We need to figure out how to take it out:

One option would be to provide a callback function for the highlight as an input property, something like:

if (highlightCallback) {
this.cacheRenderedText = sanitizer.sanitize(1,highlightCallback(this.text, this.cacheHighlightText));
} else {
this.cacheRenderedText = sanitizer.bypassSecurityTrustHtml(this.text.replace( 
     new RegExp(escapeString(this.cacheHighlightText), 'gi'), '<strong>$&</strong>' 
 )); 
}

The highlightCallback function would return something of this form (this is the type of search I am hoping to implement)

highlightCallback(text,searchText) {
  var searchTerm = text.trim().split(' ');
  searchTerm = searchTerm.sort((x,y) => {
                if (x.length > y.length) {return -1}
                else {return 1};
            });
  var searchTermRegExp = new RegExp(searchTerm.join('|'),'gi');
  return text.replace(searchTermRegExp,'<strong>$&</strong>');
}

Performance won't be optimal because we are repeating several steps. If you integrate this search (multiple keywords allowed) as an option into the module itself, you could do the string trim, split, sort and regex formation once for each term.

Only change is the regex, both replace and match work as is to implement this search.

optimistex commented 6 years ago

This https://github.com/optimistex/ngx-select-ex/issues/39#issuecomment-372939588 is released: https://github.com/optimistex/ngx-select-ex/releases/tag/3.4.3