⚡️ A fully-featured and blazing-fast JavaScript API client to interact with Algolia.
Home Page: https://www.algolia.com/doc/api-client/javascript/getting-started/
License: MIT License
TODO:
To be able to build such facet tree without messy code.
var algoliasearch = require('algoliasearch');
var client = algoliasearch({
applicationID: '',
apiKey: ''
});Our current JavaScript client is not commonJS compatible.
It cannot be used with requireJS or browserify.
The only way to use our module is to copy paste the <script src=..> tag in a webpage and use the globally available AlgoliaSearch.
This type of JavaScript library usage pattern is old and we must provide modern module loaders compatibility.
browserify -s algoliasearch index.jsThank you for this cool search service/client!
My app's integration tests have been crashing quite a bit whenever deletion of a non-existant index occured. The crash happened because src/server/builds/node.js expects data as parseable JSON
which you can see from:
// algoliasearch-client-js/src/server/builds/node.js#L135-140
resolve({
statusCode: res.statusCode,
body: JSON.parse(Buffer.concat(chunks))
});but it actually received back response
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>Hey,
When we modify the content object to display it, we sometimes have a problem when content is sent from the cache, because it has already been modified before.
Would it be possible to deepclone this cached object before sending it?
Thanks!
And move the long sentences to the migration guide.
In order to realise full blown hyper trendy isomorphic apps, we should be able to use the same library on both side of the internet (client and server). And from what I understand, it's not only an implementation problem, it is also an API problem. The signatures being slightly divergeant in one implementation or the other which prevents us from doing a drop in replacement of the lib on each side of the wire.
There's no plugin infrastructure in the code, resulting in if (angular) if (jquery).
Create one that allows us to remove the specific builds code from the main algoliasearch.js.
algoliasearch.js file.We have jQuery and Angular.js builds but the code needed by theses plugins is stored inside the main algoliasearch.js file.
This is not good because once we have 10 plugins we will be screwed and it complexifies the code a lot.
We must find a way to plug theses builds
We must have one entrypoint per plugin like today: src/algoliasearch.angular.js but it should store his own custom code.
Jsdoc comments were not updated while doing V3, lets update them
f97236b commit reverted the setting of custom request headers because it didn't stop the OPTIONS request for CORS.
It mentions the request being POST still demands a OPTIONS request.
I found that if you set the Content-Type to: application/x-www-form-urlencoded and no custom headers you skip the OPTIONS request.
Try my version: http://directlyrics.com/algolia/ac.html
And obviously it is not the expected behaviour, so when the lib tries to uses a protocol different from http or https, we should default to http.
Hi, how can I remove all console.log calls on the browser version (I'm using v3)? I couldn't find anything about this on the docs.
Thanks!
It's currently v0.9.3, latest is 0.10.1. Any reason not to update? (after applying the patch / PR that is)
in v2, the signature of this method is :
( query: String, cb: function || falsy, options: Object || falsy ) => Promise || ()
What I'd like to have is :
( params: Object || falsy, cb: function || falsy,) => Promise || ()
Motivation
The changes make the api on par with the REST api. This then simplify explanations about the fact you can have the query both in arguments and in the options. This also makes complex case, with parameters for the query more straightforward.
Cons
Other than breaking the API compatibility, it's less straightforward for simpler cases.
When calling the rest API, send a new header that will state the client version. Parameter name proposition : X-algoliaclient-version
Create a migration guide from V2 to V3, hosted on github wiki
Hi Team, I was implementing a browse solution and I noticed that could be a good idea on adding a method to set/change the index name in the helper.
Why? well, since we have to create different indexes for each "sort" option, we could just change the index name in the helper and then for example got to the page 0, that will let us to keep all the options, filters and also the callback method in the helper and refresh the same results in different order.
Thinking out loud, a sort method could be added to receive the index name, set the index and invoke to the "private" _search() method.
is there any reason about why don't have a function to change the index easily?
Use the changelog and migration guide to find the new features, breaking changes and new usages examples.
TODO:
I first used lodash-compat as a way to use forEach, map, etc.. in ES3 environments.
In the end, it adds a looot of code for 3 function calls (~6kb gzipd). So let's use our own implementations our small unique modules.
@redox fixed the bug in master, but I'd like to install it properly through bower
Thx
Something like:
helper.clearRefinements(function(facet, value) {
return facet === "foo" && value.indexOf("bar") === 0;
});
var client = algoliasearch(applicationID, apiKey, {
protocol: 'http', // force using https or http, previously named "method"
hosts: [], // which hosts to use for all other requests but the first one
tld: '', // which tld to use when computing default hosts
timeout: 2000,
jsonp: null // feature-detect/force/disable JSONP (null/true/false)
});
var helper = algoliasearch.helper(client, indexName, opts);The current constructor code has a lot of code going on and can be instanciated with a lot of different options/arity.
Also as it is a constructor, it must be used with new AlgoliaSearch().
I propose to have only one way to instanciate the client, use only named parameters and a factory function instead of a constructor.
This reduces the overhead while using our library.
Current signature is function(applicationID, apiKey, methodOrOptions, resolveDNS, hosts) and must be used with new AlgoliaSearch.
New signature will have only named parameters and will be used with algoliasearch(params).
resolveDNS. It's not usedHello, I read in the docs that:
query: (string) The instant-search query string, all words of the query are interpreted as prefixes (for example "John Mc" will match "John Mccamey" and "Johnathan Mccamey"). _If no query parameter is set, retrieves all objects_
However, when I search like this:
index.search(undefined, searchCallback, {facets: '*', page: pageNum});
It will search for the literal word 'undefined'. Same for 'null'.
Digging a bit on the code, I found that algoliasearch.js, line ~1206, does:
var params = 'query=' + encodeURIComponent(query);
(please mind I'm using v2.9.1).
Now, I didn't go to the spec, but it seems that encodeURIComponent(undefined) returns the string 'undefined', at least in the latest Chrome. This results in searching my Algolia index for that word, instead of retrieving all the results, as I intended to.
Is there a special syntax for retrieving all the results or is it a bug?
We are testing on a LOT of browsers, we should reduce them a little before we can run two test matrix easily (recent browsers, then old browsers).
We currently have two JavaScript-like clients:
Merge them in only one client: algoliasearch.
We can have isomorphic JavaScript! Let's use the same JavaScript client on both Node.js and the browser.
As the request strategies are a little bit different between Node.js (keepalive using node-modules/agentkeepalive) and the browser (fallback to JSONP, non relevant for Node.js), there will be some code differences.
Luckily, using browserify we are able to swap out requires when in the browser.
require('algoliasearch/Parse'), but build in src/server/builds/parse.jsHi, I have two page. One is Okay but on the second page, I have this error :
Uncaught TypeError: Cannot read property 'location' of undefined
caused by :
var protocol = global.document.location.protocol;
inside this lib :
http://cdn.jsdelivr.net/algoliasearch/3/algoliasearch.js
"global" is not null
I don't understand why and I haven't found the solution. Only replace this line by :
var protocol = window.document.location.protocol;
and all is okay but it's not a good solution...
This issue is not exactly an issue, but I thought it might be a good thing to raise the subject before the client gets very popular. Have you thought of using a dictionary as an argument for the creation of the Algolia object?
As a benefit,
you could give the JSON representation of this dictionary in all the place where you present the user credentials. It will be a valid literal, ready for copy-paste for JS, NodeJS but also python !
it will make it easier for you to grow the API options.
it will help people, as their configuration will probably, be in one way or another, serialized or defined beforehands in their code.
It would be very nice to have Algolia js library on Bower, in our company we use Bower to handle js files and make the pertinent upgrades.
Thank you!
There is no faceted search example . We need counters on the attributes/categories the query matches so that we can provide the navigation bar.
I have a strange problem where my node.js app doesn't return any search results and gives the error [TypeError: string is not a function].
It is running on Heroku, and there are 3 environments (and 3 github branches). For some reason it all works fine on all but the master branch and live environment. I have merged a working branch with the master but still no luck. Running the master branch on my local machine with the same variables as the live Heroku site works fine too. Since the error does not say the line number or anything, I don't know how to investigate further. But since it just occurs when searching, I believe it's the Algolia API.
Any help appreciated.
Here is the code
exports.search = function ( req, res ) {
getUser( req.token )
.then( function ( user ) {
index.search( req.query.terms, function( error, result ) {
if ( error ) {
console.log( error )
return res.status( 500 ).json( error.message )
}
return res.status( 200 ).json( result.hits )
}, { facetFilters: [ 'user:' + user.id, 'stream:' + req.query.stream ], page: req.query.page, hitsPerPage: req.query.show } )
})
.catch( function ( error ) {
console.log( error )
return res.status( 500 ).json( error.message )
})
}
JSON2.js is added to every build so that IE <= 7 is working with algoliasearch.js
It's adding a lot of code for a veryvery few users.
So we better add to our documentation that if you want to support IE7, include https://cdnjs.com/libraries/json2 and be happy.
Hi folks. After getting this set up in a new project, I'm seeing this error:
Module not found: Error: Cannot resolve module 'package.version'
happening here: https://github.com/algolia/algoliasearch-client-js/blob/master/src/create-algoliasearch.js#L13
If I go in and change it to just 3, all is well.
Example:
index.search signature is cryptic and embeds strange parameters like delay. It does not makes it clear that we must have a callback in last parameter.
Other signatures does not always have callback as last parameter.
Are you interested in merging the client-side algoliasearch library along with
the server-side (Node.JS) library?
The goal would be to have one codebase and the browser side built with browserify.
Browserside should only embed search features like today.
I wonder if you already thought about it.
The jsonp:null/true/false parameter was used to force/disable jsonp.
After speaking with @redox, we decided that we could get rid of it for V3.
The V3 has a good implementation of the retry strategy and will not retry hosts.length * CORS when they are blocked.
As soon as there's an error (network error, server error) we will always use the fallback.
For V3 we can remove the algoliasearch helper from the main library.
The first step is to externalize it, make it work with V3, this is V1.
A second pass can be done by @bobylito to then enhance and refactor the helper
so that it answers our user needs efficiently.
See www.jsdelivr.com
PS There search page could use some help.
It seems like the AlgoliaSearch object is the only public API and that
AlgoliaUtils_* are just internal functions.
If this is the case, algoliasearch might benefits from a (function() {...})() wrapper in order to avoid global namespace pollution.
In addition, AlgoliaUtils_stringifyParamValues does not actually seems to be called anywhere.
var client = algoliasearch({
applicationID: '',
apiKey: ''
});
var index = client.initIndex('indexName');
index.search('YAW callback', function searchDone(err, res) {
if (err) {
// do something with err, it's an instance of `Error`
return;
}
// everything is cool, use response
console.log(res.hits);
})The current callback convention for our JavaScript client is index.search(callback) where callback will be called with callback(success, res or err).
A popular way to handle asynchronous JavaScript is to use the callback(err or null, data or undefined) convention.
Notable projects using or leveraging this callback convention:
In the days of "isomorphic JavaScript", we must stick with a well used convention to not fall into the "guys using fancy callback pattern" basket.
callback(err, res)Linked with algolia/algoliasearch-client-node#18.
"params:" is missing
We need to make the V3 release as smooth as possible in all cases. Even when the user includes the auto-updated "latest" algoliasearch.js
We advocated for some time to use http://cdn.jsdelivr.net/algoliasearch/latest/algoliasearch.js which means "Use the latest alogliasearch library which udpates automatically, YOLO".
We want our users to be up-to-date but using versions strings like V2.x V2.9x V3.x etc.. So the user is able to get patch updates and new features updates while being sure his website will always work.
For now we must make the V3 release backward compatible in some way.
For all our JavaScript projects, we use http://www.jsdelivr.com/ as a great way to distribute our builds to clients.
One drawback is that we have to commit dist/ files to our github repository for them to be picked up by their bot.
As committing dist/ files can be tedious and error prone, we should be able to avoid it.
It seems that by combining https://github.com/jsdelivr/libgrabber#add-updatejson-schema and npm prepublish and gitignore we would be able to push our dist files to the npm repository only and then have jsdelivr pick them up from here.
What do you think @bobylito @pixelastic?
instead of setting the value of obj (obj.value) equal to the first match, would it make more sense to allow an argument in the constructor to explicitly the set the mapping between the propertyName and the object.value so that the order in which the object attributes are created in the index does not determine how the object.value <--> attributeName mapping is determined?
// Method used by Typeahead.js.
get: function(query, processRemoteData, that, cb, suggestions) {
self = this;
this.search(query, function(success, content) {
if (success) {
for (var i = 0; i < content.hits.length; ++i) {
// Add an attribute value with the first string
var obj = content.hits[i];
var found = false;
if (typeof obj.value === 'undefined') {
for (var propertyName in obj) {
if (!found && obj.hasOwnProperty(propertyName) && typeof obj[propertyName] === 'string') {
obj.value = obj[propertyName];
found = true;
}
}
}
suggestions.push(that._transformDatum(obj));
}
cb && cb(suggestions);
}
}, self.typeAheadArgs);
return true;
},index.search('smg')
.then(function(res) {
// console.log(res.hits);
})
.catch(function(err) {
console.error(err);
});Current JavaScript API client only sends promises when using Angular.JS or jQuery build.
We must return promises to every API command.
We won't use Q or then, we use the native promise API, this is not a taste choice, only more relevant.
Using js client v2 or v3, the search callback does not execute. I'm testing on IE9 via browserstack.com. Live search can be found at http://mytennislessons.com/search?q=Austin
I only have access to Firebug Lite in browserstack, but with that, I don't see any js exceptions. Any ideas?
Relevant snippet
index.search('',
{ aroundLatLng: coordinates, aroundRadius: 32187, getRankingInfo: 1,
hitsPerPage: self.perPage
},
searchCallback
);
function searchCallback(err, content) {
alert('searchCallback'); // not executed
}the client initialization changed in V3 so previously exported globals should also throw:
Add a precise message linking to the migration guide to V3 hosted on github
The NodeJS version takes a list of hostname, while the JS client takes a list of URI.
The confirmation email returns a host. Maybe that would be nice to choose either way
or detect that http:// is missing and add it in JS.
In file src/server/builds/node.js the method generateSecuredApiKey() uses the crypto module without importing it.
The method throws a ReferenceError
Add the line:
var crypto = require('crypto');The parse integration is broken because the content type is set to 'application/json' instead of 'application/json;charset=utf-8' "https://github.com/algolia/algoliasearch-client-js/blob/master/src/server/builds/parse.js#L60"
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.