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.
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
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. :-)
Comments
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.
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
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. :-)