Improved error handling if service unavailable

[HenrikKorsgaardKnowit]

If the api endpoint is unavailable (dawa.aws.dk), the current implementation will retry with a default delay at 500ms and write an error to console.

This makes it very difficult to handle errors (regardless of how stable Dawa autocomplete2 is).

It would be nice with the ability to handle the potential connection error:

• Throw error
• Emit error event
• provide an optional errorHandler function (similar to selectInitial)

[iamfrank]

@HenrikKorsgaardKnowit A reasonable suggestion, though I am not sure there are any more resources being put into developing dawa-autocomplete further. I'll ask around.

In the interim, consider if Gsearch could be a viable alternative for you. This project does pretty much the same as DAWA-autocomlete and is under active development: https://github.com/sDFIdk/gsearch-ui

[DocDemar]

@HenrikKorsgaardKnowit - we will not add any new features or improvements to autocomplete gsearch is the new autocomplete

if gsearch is lacking in features, perfomance or other issues - please let us know and we will fix it if we are able to to

have a nice weekend

[woutervanvliet]

@DocDemar That would have been very interesting information to have, especially before we started implementing dawa-autocomplete2 in our solution ;).

Perhaps the README file of the data-autocomplete2 repo can be updated to reflect this, just like the documentation found here: https://dawadocs.dataforsyningen.dk/dok/guides

[DocDemar]

sry for that - we weren't quit ready to push this recommendation We will update the docs as soon as possible

[HenrikKorsgaardKnowit]

Just a comment. It is important to notify users DAWA-autocomplete2 about the status and timeline:

• Is DAWA-autocomplete2 being replace (deprecated) by gsearch-ui?
• What is the timeline for DAWA-autocomplete2 and gsearch-ui?
• Are the terms of service changing -- I see an API key in gsearch-ui...

Some of this is strategic roadmap discussions, but they are needed given how many Danish websites and applications use DAWA-autocomplete2.

In many of our applications using DAWA-autocomplete2, gsearch-ui does not seem like a viable replacement. It is a UI component and not a flexible API integration like DAWA-autocomplete2.

[DocDemar]

Hi Henrik

DAWA-autocomplete2 will in time be replace (deprecated) by gsearch and gsearch-ui.

The timeline is not yet decided. We need input from you and other users as to what is missing in Gsearch in order to be able to make the switch fra Autocomplete to Gsearch.

It is neccesary to create a token at dataforsyningen.dk in order to use Gsearch there is no change in terms of use.

We know that autocomplete is a blockbuster API and we will do our best to replace it with something as great as autocomplete.

Any specific input will be very valued in order for us to make Gsearch and Gsearch-iu as great as Autocomplete

[HenrikKorsgaardKnowit]

@DocDemar you are more than welcome to reach out when you need input. I'd be happy to review and give input for gsearch when you are ready.

[DocDemar]

Thanks - if you have any input we will be happy to recieve it now

[kropsi]

Hi @DocDemar,

Could you please clarify the reasoning behind creating a new GSearch-UI component? DAWA-autocomplete2 has proven to be a robust and effective solution that has consistently addressed our use cases over time.

Additionally, we have been extensively utilizing DAWA APIs, like https://api.dataforsyningen.dk/autocomplete, along with other DAWA endpoints, as reliable sources for Danish addresses and the associated information. Are these APIs also at risk of deprecation?

From your implementation of the Gsearch UI, which uses GSearch endpoint https://api.dataforsyningen.dk/rest/gsearch/v2.0/, it appears to function quite differently by calling multiple resources at once, such as:
navngivenvej, husnummer, adresse, stednavn, kommune, region, retskreds, postnummer, opstillingskreds, sogn, politikreds, matrikel, matrikel_udgaaet,
and then combining the data on the frontend without an autocomplete feature. This approach seems more limited in functionality compared to the DAWA web services we are currently using.

Looking forward to your thoughts.