Over-verbose variables like results.results

[peterblazejewicz]

I've already tried some examples and I've found these very verbose:

• suggestions.suggestions
• results.results
  For example:

if(state.results.results && state.results.results.length) {

It looks like System.Configuration.Configuration from .NET and I think the JS users are not accustomed to such verbosity

[EvanBoyle]

Interesting point. Do you have suggestions on how you'd improve the api? Verbosity in general comes with the benefit of being self documenting. I agree that results.results is redundant, but results also contains other information such as fetching status, last executed time stamp, etc.

[peterblazejewicz]

I do not have strong opinion on how to format results data. That's just my observation. An older sample code written by you is less verbose though:
https://github.com/AzureSearch/AzureSearchNodeJSIndexerDemo/blob/master/js/UI/components/SearchUI.js
The AzureSearch REST api just return an 'value' key with list of objects I think. This sample implementation returns just an array of raw values from API:
https://github.com/azure-contrib/node-azure-search
The Algolia search bindings are not so verbose:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/algoliasearch/index.d.ts
The React bindings for Algolia just use searchState, searchResults common terms:
https://github.com/algolia/react-instantsearch

[EvanBoyle]

I think the intention of the two are different. The algolia library you pointed at seems to be a client to talk to their service. The goals of this SDK are to handle not only requests to the service, but also maintaining the state of the application, eg which results are loaded, which facets are selected, etc.

The idea with this library is that a large number of the UI patterns for search are generic, but require lots of state management and additional code beyond what a standard SDK wrapper over an API would provide. This library has the goal of making common rich UI scenarios like checkbox and range faceting very easy to build UI against.

Actually I see three sorts of JS SDKs:

1. the community node package that you linked above, this is a plain wrapper over the api and doesn't provide additional functionality to help build an app.
2. AzSearchStore, the "App SDK". Ideally AzSearchStore will help you get your custom search app up and running quickly with common search UI paradigms.
3. AzSearch.js, the search UI SDK. AzSearch.js has the goal of getting a fully functioning search app up and running instantly with very little configuration and required. The provided controls will eventually be fully customizable, and act as a reference of how to consume AzSearchStore.

I'm happy to have the feedback on the verbosity of the API. We can definitely look at making the signatures shorter, but we'll have to balance readability and the self-documenting nature of the current APIs. I'll be opening some issues over the next day or two to start a discussion on the API surface area. It would be great to have you participate in that discussion.