Giters

algolia / search-insights.js

Library for reporting click, conversion and view metrics using the Algolia Insights API

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fix option name compared to API clients & IS:`appId` -> `applicationID`

redox opened this issue · comments

commented

Should be easy to keep the backward compat.

Either with:

insights({
  applicationID: '',
  apiKey: ''
});

or

insights('appid', 'apikey');
commented

@redox When you use search-insights, did you get the type suggestion? If yes, do you think it is not enough and we'd better update the function signature?

image

commented

@redox When you use search-insights, did you get the type suggestion? If yes, do you think it is not enough and we'd better update the function signature?

It's more a question of consistency across our library I think, we're using applicationId everywhere we should do here as well. Also, not everyone has autocompletion so I wouldn't rely on this.

commented

@redox When you use search-insights, did you get the type suggestion? If yes, do you think it is not enough and we'd better update the function signature?

It's more a question of consistency across our library I think, we're using applicationId everywhere we should do here as well. Also, not everyone has autocompletion so I wouldn't rely on this.

It'd be more like

aa("init", {
  applicationID: '',
  apiKey: '',
});

(The first argument is "init".)

Supporting this alias is not a big deal at all and it's easy to do so. I just want to confirm with you that there are many occurrences and references to appId in the docs.

commented

I just want to confirm with you that there are many occurrences and references to appId in the docs.

Right, I think we should ultimately unify everything and rename them all; but the most important was the insights one as it's used in combination to our API client and instantsearch JS libraries were we always use "applicationid".

commented

In InstantSearch we actually used appId back when it was an option: https://github.com/algolia/react-instantsearch/blob/af4b642476f3b3d0b98e0f1afa3d7346fc450893/stories/InstantSearch.stories.js#L11 and https://github.com/algolia/instantsearch.js/blob/v2/src/lib/InstantSearch.js#L40

We have since moved to the option searchClient alone, which indeed has algoliasearch('appId', 'apiKey') without named argument

commented

In InstantSearch we actually used appId back when it was an option: https://github.com/algolia/react-instantsearch/blob/af4b642476f3b3d0b98e0f1afa3d7346fc450893/stories/InstantSearch.stories.js#L11 and https://github.com/algolia/instantsearch.js/blob/v2/src/lib/InstantSearch.js#L40

We have since moved to the option searchClient alone, which indeed has algoliasearch('appId', 'apiKey') without named argument

Oh interesting, this is surprising. I still think we need to align it with our docs mentioning everywhere "YourApplicationID" and with our API clients using "application_id/applicationID".

commented

@redox Before you opened this issue, did you have experience where you were using applicationId as a parameter somewhere else and come to this repo to see it's appId here?

I'm searching for the doc and I see the expression "application ID" in plain texts, but not in the code snippets. So I'm not so sure if changing this signature will align with other libraries we provide. Most of the api clients just accept two strings as parameters, although the description says "applicationID" in many cases.

What do you think?

commented

What do you think?

Not a specific snippet, to me it's more because we speak about "application" and "YourApplicationID" everywhere (in our docs & dashboard) and never speak about "app" or "AppID"; so I felt this was very confusing to introduce a new naming.

commented

@benhinchley I think with the upcoming v3 this is handled, so we should be able to close this soon.