33209 force international address auto complete in english char only

[mruff-aeq]

#33209 : /bcgov/entity#33209

Overview of Current Code State:
The Canada Post AddressComplete library (addresscomplete-2.30.min.js) — vendored at public/js/addresscomplete-2.30.min.js (https://ws1.postescanada-canadapost.ca/js/addresscomplete-2.30.min.js), loaded via a global <script> tag in index.html. It runs entirely on window, attaches its API as window.pca, manages its own DOM (the suggestion dropdown is injected directly into document, not Vue-managed) and exposes its own event system via addressComplete.listen(eventName, callback).

Bug in addresscomplete-2.30.min.js that selects non-latin1 text:
Unfortunately there is a bug in the addresscomplete-2.30.min.js in its' populate method by always selecting the first json object index, when working with the address auto complete for countries like China. When a Chinese address is searched by this endpoint http://ws1.postescanada-canadapost.ca/AddressComplete/Interactive/RetrieveFormatted/v2.10 , it returns an array of 2 json objects.
Example:

[{"Id":"CN|UP|B|N2808386","DomesticId":"","Language":"ENG","LanguageAlternatives":"ENG","Department":"","Company":"","SubBuilding":"","BuildingNumber":"","BuildingName":"","SecondaryStreet":"","Street":"","Block":"","Neighbourhood":"\u51E4\u5B89\u9547","District":"\u7D2B\u91D1\u53BF","City":"\u6CB3\u6E90\u5E02","Line1":"","Line2":"\u7D2B\u91D1\u53BF","Line3":"","Line4":"","Line5":"","AdminAreaName":"","AdminAreaCode":"","Province":"\u5E7F\u4E1C\u7701","ProvinceName":"\u5E7F\u4E1C\u7701","ProvinceCode":"","PostalCode":"517452","CountryName":"China","CountryIso2":"CN","CountryIso3":"CHN","CountryIsoNumber":"156","SortingNumber1":"","SortingNumber2":"","Barcode":"","POBoxNumber":"","Label":", \u7D2B\u91D1\u53BF\n517452 \u6CB3\u6E90\u5E02\nCHINA","Type":"","DataLevel":"Street","Field1":"","Field2":"","Field3":"","Field4":"","Field5":"","Field6":"","Field7":"","Field8":"","Field9":"","Field10":"","Field11":"","Field12":"","Field13":"","Field14":"","Field15":"","Field16":"","Field17":"","Field18":"","Field19":"","Field20":""},
{"Id":"CN|UP|B|N2808386","DomesticId":"","Language":"ENG","LanguageAlternatives":"ENG","Department":"","Company":"","SubBuilding":"","BuildingNumber":"","BuildingName":"","SecondaryStreet":"","Street":"","Block":"","Neighbourhood":"Feng An Zhen","District":"Zijin County","City":"Heyuan City","Line1":"","Line2":"Zijin County","Line3":"","Line4":"","Line5":"","AdminAreaName":"","AdminAreaCode":"","Province":"Guangdong Province","ProvinceName":"Guangdong Province","ProvinceCode":"","PostalCode":"517452","CountryName":"China","CountryIso2":"CN","CountryIso3":"CHN","CountryIsoNumber":"156","SortingNumber1":"","SortingNumber2":"","Barcode":"","POBoxNumber":"","Label":", Zijin County\n517452 HEYUAN CITY\nCHINA","Type":"","DataLevel":"Street","Field1":"","Field2":"","Field3":"","Field4":"","Field5":"","Field6":"","Field7":"","Field8":"","Field9":"","Field10":"","Field11":"","Field12":"","Field13":"","Field14":"","Field15":"","Field16":"","Field17":"","Field18":"","Field19":"","Field20":""}]

As we can denote, the first json object contains Chinese characters in format\u51E4\u5B89\u9547 , and the second json contains characters in latin-1 specFeng An Zhen.

Unfortunately, the current behavior in addresscomplete-2.30.min.js's populate method is to always pick the first item in the array, so the Chinese text will we passed to our form in this case.

The Fix:
In JavaScript, .test() is a method used with Regular Expressions to check if a string matches a specific pattern.

It returns a simple boolean:

• true: The pattern was found in the string.
• false: The pattern was NOT found.

/^[\u0000-\u00ff]*$/.test(val)

1. The Pattern: /^[\u0000-\u00ff]*$/ (The "Latin-1 only" rule).
2. The Input: val (The text inside an address field, like "Victoria").
3. The Action: It looks at val and asks: "Does this string consist ONLY of characters between \u0000 and \u00ff?"
4. The Result:
   • If val is "Montreal", it returns true.
   • If val is "Méntrèal", it returns true (accents are in that range).
   • If val is "北京" (Beijing), it returns false (these characters are outside the range).

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the business-filings-ui license (Apache 2.0).

[mruff-aeq]

Current: Address auto complete results in Chinese text being populated

My fix: Address auto complete results in English text being populated

[loneil]

It's a lot of custom code (well, not really in the grand scheme of things) for specific character handling. Doesn't mean it's wrong to do it or anything, just that I don't know the address lookup component on these projects well enough yet.

Maybe @kialj876 does better (?) but would be worth knowing:

• Would other parts of the Registries ecosystem have this same problem (auth? new Nuxt views? Name Request?)
• If they don't, how did they setup the lookup to avoid that?

[mruff-aeq]

• Would other parts of the Registries ecosystem have this same problem (auth? new Nuxt views? Name Request?)
• If they don't, how did they setup the lookup to avoid that?

It seems on other views, they disabled address lookup on countries other than Canada, but here it is the requirement. When dealing with Canadian addresses on other views, they would all go through the filter fine as the api returns latin-1 json for them.

[kialj876]

Hey mark, nice work this was a bit of trickier one!
I think you already have the data you need so there's no need for 'fetchLatin1Alternate' or 'buildRetrieveFormattedUrl' - let me know if you want to discuss

[kialj876]

It's a lot of custom code (well, not really in the grand scheme of things) for specific character handling. Doesn't mean it's wrong to do it or anything, just that I don't know the address lookup component on these projects well enough yet.

Maybe @kialj876 does better (?) but would be worth knowing:

• Would other parts of the Registries ecosystem have this same problem (auth? new Nuxt views? Name Request?)
• If they don't, how did they setup the lookup to avoid that?

yeah @mruff-aeq can you ask vikas about creating a ticket to handle this similarly in our base layer repo - might be low priority but it currently just ignores the auto complete for non english countries there and I think this solution is better

[kialj876]

Looking good - please fix the lint and one minor comment below

[kialj876]

Nice work this looks good to me now, thanks for the updates!