It seems searckit took great inspiration from it:
- component naming (search box, refinement list, hierarchical menu)
- documentation organisation:
+ http://searchkit.co/ is using an imdb demo just as https://www.algolia.com/ homepage
+ https://ssetem.gitbooks.io/searchkit/content/ vs https://community.algolia.com/instantsearch.js/documentation... (see "components" menu on the left)
- react based (but only works if you have react though)
- and more parts maybe
@Author could you give some more details on the parts of instantsearch.js that were inspiring to your project?
Thanks
We also throttle the searchbox search requests as you type.
We have now switched to Apache license Due to interest and our wish is for many new contributors to add to Searchkit's ecosystem + component library https://github.com/searchkit/searchkit/blob/master/LICENSE We will be working hard in the next weeks to add to the developer documentation, and walkthroughs on making custom components. Thanks!
https://github.com/searchkit/searchkit/blob/master/LICENSE
We will be working hard in the next weeks to add to the developer documentation, and walkthroughs on making custom components.
Thanks!
I'll normally create an app bundle that includes all the libraries, and the users will only execute that one file. Does that count as distribution? Would that make it such that the whole app must now be licensed under GPLv3? I make source maps available in production (that get dynamically loaded when you open dev tools), is that enough to meet the requirement of sharing the source?
Heck, even if you split off the GPL'd files from the main app bundle and it's loaded dynamically, you'll still be executing it on the same DOM... So it's still eating up the rest of the app into becoming GPLv3, right?
Another question, somewhat off-topic. How do people feel about talking to elastic search directly (via proxy or not), versus going through another service layer. The argument for a service layer is providing a cleaner and more stable API for front-end developers. The downside is that elasticsearch has a lot of useful features, and it's hard to imagine an API that's much simpler that exposes them in a useful way, you'd end up significantly slowing down development of front-end search features.
My reason for asking here, is that libraries like this are appealing, but may not fit well with the way more micro-service-y teams approach search.
The service layer is purely opt in, and its a thin proxy incase you want to apply permissions, it speaks elasticsearch purely, this is one thing we don't want to change. E.g. our demos actually connect direct to a read only elasticsearch instance
Wow. Thanks for that name. I found this solution when I needed to pass some async stuff to React component. But I called it hacky wrappping function. Now I can call it higher order component, give it capital letter name and be proud. :-)
thanks.
