Swiftype-node & CORS

I'm having trouble developing locally with GitHub - swiftype/swiftype-node: Node.js client for the Swiftype API as I'm running into CORS errors. I know I can open an instance of Chrome with web security disabled, but I'm hoping to avoid that. Anyone have suggestions or examples?

Hey Katy!

Thanks for joining the community. Hopefully we can help you out.

Can you walk me through what you're trying to build a bit more?

My first thought is that it's unusual to have Node on the client (see this Quora post for a more long-winded think-through). :thinking:

I look forward to hearing from you. :smile:


Thanks for the reply, Kellen.

We were hoping to leverage swiftype-node in a React site to avoid reinventing the wheel. We're hoping to add a Site Search autocomplete feature (similar to https://github.com/swiftype/swiftype-autocomplete-jquery). I didn't see any React wrappers out there for Swiftype Site Search, but it seems like we should roll our own integration to make this work, unless you have other suggestions? We'd be very appreciative!

Katy --

We've been working on something that might help, and we're really excited about it.

Soon we'll be releasing an open source Search UI for building excellent search experiences: https://github.com/elastic/search-ui.

We have built a Site Search connector for it:

mport SiteSearchAPIConnector from "@elastic/search-ui-site-search-connector";

const connector = new SiteSearchAPIConnector({
  documentType: "national-parks",
  engineKey: "Z41R5U3Hi4s5gp1aw7kA"

You can follow the React README, swapping out Site Search for App Search where appropriate.

We'd love people to dig into Search UI and start building things -- we haven't promoted it; we're still applying some polish. Your feedback would be most helpful.

Otherwise, we don't have a JavaScript client that would be a good fit for what you're hoping to accomplish. :expressionless:


Kellen, that is perfect!! Thank you so much. I'm going to demo this today and would be happy to send feedback.


Hello, Katy ~ :wave:

We gave the Search UI README a pretty major revision: https://github.com/elastic/search-ui.

Hopefully that didn't make things too confusing if you were trying to get up and running.

Wondering if Search UI was able to help you out -- any feedback?

Enjoy the week,


Kellen, it's been very fun to use!

I have the early stages of a react component we're working on, if you'd like to take a look: https://github.com/mapbox/dr-ui/blob/search/src/components/search/search.js

The above will be a search component in our docs component library. It will appear as an input and the results will open up a popover as the user types.

A couple things that I haven't been able to smooth out yet:

  • handling of no results - would like to show a custom message, but having trouble with state change. For example, flashes of "no results" as component loads before a user searches. While I could likely handle in React, would be great for a native feature in /search-ui to handle this if possible!
  • setting a spinning loader for when the results are loading, I've been playing with different implementations of isLoading state but haven't hit the sweet spot yet. Or maybe I'm using it incorrectly?
  • debouncing searchAsYouTube with custom view, on SearchBox, when searchAsYouType enabled with a custom view it doesn't appear to debounce results https://github.com/mapbox/dr-ui/blob/search/src/components/search/search.js#L190

Let me know if you'd like me to cut an issue in /search-ui with any of these comments :slight_smile:


Hi @katyd, no need to create an issue. I'll work with you directly here and help you get this thing working.

Something I noticed right off the bat that might be the root of some of your issues... There is no need to instantiate a SearchDriver directly. When using SearchProvider, it instantiates its own SearchDriver internally. Sorry, I'm sure our documentation didn't make that clear, that's something we're actively working on cleaning up.

Take a look at this example, I think this will get you headed in the right direction: https://github.com/JasonStoltz/dr-ui/pull/2/files.

  • handling of no results - I'm not sure exactly what the issue is, but I think for a "No Results" message, I think you want to check the following condition from state:
 {({wasSearched, results}) => {
   if (wasSearched && results.length === 0) {
     return <ANoResultsMessage />

  • setting a spinning loader for when the results are loading - We actually implemented something like this on https://www.elastic.co/ using this library. I think the isLoading property you're using already should work correctly once you have the driver issue resolved above.

  • debouncing "searchAsYouTube" :stuck_out_tongue: - I was able to get this working locally, could you please confirm that you are using the property "debounceLength"?


Try some of these things I mentioned, and then let me know if you're still have issues and I'll gladly work through them with you.

:pray: Thank you so much for your guidance, Jason!

The documentation is great, I think I got myself mixed up because I started using /react-search-ui and then tried /search-ui and then went back to /react-search-ui - I got myself jumbled up.

I have everything smooth out now. Just one thought:

To reduce complexity, I think I'd like to use SearchBox and skip a custom view. I have it working great, but I'm trying to think of an elegant solution to remove the "Submit" button. I'll likely go with CSS to hide it, but curious if you all considered an option for SearchBox to hide the submit button since searchAsYouType supersedes the functionality of the submit button.


That's a great suggestion, thank you.

Generally speaking, I am trying to take the render props approach as the solution to customization. This is kind of in line with libraries like formik and downshift. I think this description says it best: https://github.com/downshift-js/downshift#this-solution.

That being said, it is still fairly impractical to provide your own view to some of these components. SearchBox is a great example, as you pointed out. Providing a simple flag for hiding the button, or maybe an alternate, "buttonless", view would be good options.

I'm planning to publish a 0.6 version of this library soon, I think I may try to include that as an option. I'll enter it as a feature request so that it is tracked.

Thanks again for the input!

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.