
Show HN: Searchkit – React components for elasticsearch - joemcelroy
http://www.searchkit.co
======
vvoyer
Nice! Funny is that Algolia released something very similar some time ago:
[https://community.algolia.com/instantsearch.js/](https://community.algolia.com/instantsearch.js/)

It seems searckit took great inspiration from it:

\- component naming (search box, refinement list, hierarchical menu)

\- documentation organisation:

\+ [http://searchkit.co/](http://searchkit.co/) is using an imdb demo just as
[https://www.algolia.com/](https://www.algolia.com/) homepage

\+
[https://ssetem.gitbooks.io/searchkit/content/](https://ssetem.gitbooks.io/searchkit/content/)
vs
[https://community.algolia.com/instantsearch.js/documentation...](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

~~~
joemcelroy
Yep we did take a look at Algolia components. They made a great library and we
took inspiration from their API. The difference with us is we focused on
building with elasticsearch and we use declarative based components focusing
towards the more experienced developer crowd.

~~~
vvoyer
thanks for your honest reply, good luck with the library!

------
fleshweasel
I'm enthused, but would suggest you don't put an entry in the user's history
for every keystroke in the search box.

~~~
fphilipe
Yes, this! People seem not to know when to use replaceState over pushState.
And in my eyes this is a clear candidate for replaceState. (There are also
examples the other way around, such as GitHub's PR tabs, drives me insane
every time.)

~~~
joemcelroy
Yes! Thanks for noticing a side effect of the way we update our url. It should
be replaceState for the search box. Other actions like pagination, applying
filters and sorting should be pushState however.

We also throttle the searchbox search requests as you type.

------
ssetem
Hi I am the Co-Author of Searchkit

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](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!

------
joemcelroy
(Author) This is our first release of searchkit. Adding more components and
documentation in the next few days. Let us know if theres something missing
you like by opening a github issue. Thanks! Joe

~~~
brasetvik
Have you considered a more permissive license, like Apache/MIT/BSD?

~~~
jamra
What's wrong with the GNU license?

~~~
dllthomas
Assuming your question arises from a state of ignorance, rather than from
rhetorical flourish:

What distinguishes GNU licenses from more permissive licenses is that the GNU
licenses require derived works be released under an appropriate GNU license as
well.

This is not quite anti-commercial, but does put the kibosh on some otherwise
viable business models. If you wish you could incorporate some of this code in
a proprietary product that you can sell licenses to, then what's wrong with
the GNU license - from that stand point - is that it forbids that.

That's the intended purpose of the GNU licenses - to promote software that
respects user freedoms by making it easier to write such software (because of
access to existing GPL/AGPL code) relative to the ease of writing software
that infringes on those freedoms.

As a necessary side effect, it is also the case that you cannot move GNU-
licensed code into a non-GNU-licensed-but-compatible codebase _without
changing the license to an appropriate GNU license_. Code _can_ move the other
way, from compatible permissive license to GPL.

Sort of the worst case, in terms of unintended consequences, is code under an
incompatible-but-otherwise-free license, where code can't move either way for
not really any good reason.

Fortunately, people seem to have _generally_ settled on GPL-compatible
licenses, whether permissive or copyleft.

~~~
jeswin
> Assuming your question arises from a state of ignorance, rather than from
> rhetorical flourish

It is quite clear to me that the parent's intention was to challenge the
ritualistic "Why not MIT/BSD?" type of argument. It is the author's
prerogative to decide which license the software should be under. While I use
permissive licenses for my work usually, I see the merit in GPL licenses and
might even switch back to it at some point. They serve different goals, and I
suspect that in future we're more likely to converge towards GPL-like
licenses.

GPL protects the rights of independent developers better than permissive
licenses; and as software development becomes more accessible, we're likely to
see more work pocketed off by companies without giving due credit, or even
entirely forked off. GPL clearly recognizes that companies will not give back
unless required by the law. If we're to have a fairer and more decentralized
(political) power distribution, we need the protections of the GPL.

If I could flick a switch to turn all OSS projects to GPL, it'll impact the
entire industry in a good way. OTOH, changing everything to permissive
licenses will have absolutely no impact.

~~~
dllthomas
_' It is quite clear to me that the parent's intention was to challenge the
ritualistic "Why not MIT/BSD?" type of argument.'_

It seems plenty possible, hence my explicit note that I was assuming
otherwise. It doesn't seem clear - I've encountered people asking that
question honestly and I tried to give an honest answer. To the degree that I'm
a partisan in this discussion I am pro-GPL, but I think it's worth
acknowledging the legitimate points raised by reasonable people on the other
side.

------
andrewingram
Looks nice. I'd prefer higher-order (wrapper) components to extending the
component classes though, HOCs are more idiomatic.

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.

~~~
ssetem
Thanks, we can look into higher order components for wrapping and overriding
blank states etc.

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

------
egze
Looks great. But don't add every key press to the browser history. Not cool ;)

~~~
ssetem
thanks for the feedback, this is fixed now :)

------
techaddict009
Looks awesome. We are building something on react and we will probably use
this.

thanks.

