Changed watch enter to not got to server #18
Conversation
- Most of linters are complaining about ; in the end of the line.
- Removed the opts variable. It is not used outside initOpts. - Moved initOpts function to be inside the variable watcher.
|
First, can you tell me if the issue you are talking about is fixed in the example here? To see the issue I'm talking about, take out jQuery from the example I linked, then type in "a" to the autocomplete, press enter, then type in "s", and click on one of the answers, it won't update properly. I'm not sure why having jQuery as a dependency fixes this but it seems to work. Originally I was going to implement the enter functionality the way you have, with it simulating the down arrows and enter keys, but I wanted to implement it in a way that doesn't break if Google changes the autocomplete's CSS layout, and I'm a bit wary of simulating keys. The current implementation relies on an extra server call, but it uses Google's public API's which are less likely to change, and doesn't rely on the CSS layout. So it's a bit of a tradeoff, I'm really interested in hearing more of your thoughts on this, and I really appreciate the PR's. |
|
I was planning to use your component without any changes. The problem is that I found some bugs in my use cases :(. I am using the watchEnter functionality and whenever the component loose the focus, the text is returning to the state when I hit ENTER. I debug the code and I found that the lostfocus event that you bound to the element was occurring before the lostfocus event of google's component. So In my case, this workaround was not working. Another problem is, since you are using the PlaceService API, the result returned by this API is not the same as the first element from the AutoComplete list. In my case (Germany), I was searching for Alexander Platz using (al) and when I hit ENTER it returned me Germany (and it should return Alexander Platz, Germany). With the changes that I did, both bugs are gone. IMO we shouldn't care about changes on Googles's API. We can always set which API version we want to use. So we must provide in the documentation which google's API version we tested with. PS: Browser Tested - Chrome, Safari and Firefox |
This is concerning, could you link your use case or put up an example of this? I'd really like to look more closely at this.
It's not the API I'm worried about changing, but rather the non API things like the autocomplete's HTML/CSS layout, which the directive now depends on because of the Currently the directive only utilizes the public APIs, this change would also make it reliant on HTML/CSS layout of the autocomplete widget, which might be subject to undocumented change.
This is definitely an issue, I was under the impression they returned the same results, but apparently not always. |
|
Just try: http://plnkr.co/edit/GF3nM3XfYX9El2w11pGo?p=preview al (ENTER) (TAB) Tested on: Chrome and Firefox |
|
Ok, I see what you mean. I need to look at this some more. |
|
NP. Take your Time. I think the check $(".pac-item-selected").length is not needed. I will do some tests and update the PR. |
- Simulating an arrow down and enter on the listbox, so the app don't need to do one extra server call to get the information. This change will also fix the lost focus issue, where the AutoComplete is reverting the changes when user press enter.
|
So, What is the status of this PR? |
2 participants
Simulating an arrow down and enter on the listbox, so the app don't
need to do one extra server call to get the information.
This change will also fix the lost focus issue, where the AutoComplete is
reverting the changes when user press enter.