Conversation
…n query string feat(search): add some styles & links for states/blogPosts results
|
I think it could be useful to scrape our own tweets and index them as well, since a lot of useful information/thoughts/explanations happen on our twitter feed. |
|
@muamichali yup that's something we can work on, if someone's willing to create the app and send us the API keys on Slack, we'd be happy to give it a shot when we're done with the basic features! |
The search feature was started as a PoC using State hooks, that was extracted to src/context/search-context, using Context hooks for easier reuse (on /search but also in the header). Added withSearch HOC, which wraps withLocation, to re-use searchContext easily accross the site while retaining access to URL query. All logic specific to search, but not to search page, moved to the hook file. Pages that match have their (full, for now) body rendered with some highlighting (deserves some more emphasis to make it more visible). If the body has no hightlighting we return its truncated value. Finally - more like a side effect, but a nice one - the search is triggered whenever the input value is updated. We need to check: 1. Is this going to consume our API quota too fast, and 2. Will this be, OK as the header will be an autocomplete, and this input refreshes the result page instantly? The UX feels right but maybe I'm just happy that it works.
|
This is a preview version of the site. Built with commit 7eabe66 https://deploy-preview-700--upbeat-lovelace-3e9fff.netlify.app |
schwartzadev
left a comment
There was a problem hiding this comment.
This is just a first pass from visually inspecting the code and chatting with @superbiche over Slack.
I didn't get a chance to run this locally to review, but I'm posting this in the interim regardless
| </div> | ||
| )} | ||
| <div className={searchPageStyle.searchResults}> | ||
| {/* State results */} |
There was a problem hiding this comment.
These could probably be done DRY-er -- we could have a component for the results and then pass the inner content to the component for:
- state results
- blog posts
- pages
Plus, this should make it easier to add items like Twitter in the future!
There was a problem hiding this comment.
Totally agree. Once we've done the first review pass this ought to be a flexible component!
| {searchState.isFetching && ( | ||
| <div> | ||
| <img | ||
| src="https://d1j8pt39hxlh3d.cloudfront.net/products/previews/RES3POBSZ353HFVPZOKR/2329_kKbUTLGEVXhuOIJqrT7QvIJFAXvEpQ3z.gif" |
There was a problem hiding this comment.
This is a placeholder for now -- just flagging it before we push
| <div key={page.objectID} className={searchPageStyle.searchResult}> | ||
| <PublicationTitle> | ||
| {/* FIXME this should be handled during indexing | ||
| (avoids external Link issues) */} |
There was a problem hiding this comment.
This is tricky...it looks like some Links begin with '/', and others don't. We should probably standardize this across the codebase so we don't have to handle this here. Ideally someone could work some grep magic and find out where that's happening.
@kevee which is preferred?
- prefixing
Linkwith/ - not prefixing
Linkwith/
There was a problem hiding this comment.
Actually we have to prefix links with / otherwise Gatsby will throw warnings.
I'm pretty confident this is an inconsistency issue with the slugs and how these are built.
I could comment out this function to get a precise list of failing links, so we can check these individually
There was a problem hiding this comment.
Prefix them all with /
The pages here all have their slug defined in Contentful, which automatically creates the slug based on the title.
There was a problem hiding this comment.
@kevee Added getSanitizedSlug to generate slug depending on result type + handle missing starting /
|
This is going to be a feature in a larger project, so let's not merge it into master. I'll make a project branch for it to merge into tomorrow. |
|
I've also made a separate admin key for both Netlify and CircleCI scoped to just index management. |
|
Thanks for your feedback @kevee @schwartzadev. Fixes and adjustments coming later today! |
|
I added the autocomplete, using the Reach UI Combobox. I kept the form that Michel has been using on the page as well, for discussion's sake. I am not sure what the best approach is, but one thing I was thinking about was the possibility of ditching this autocomplete, and having the search results with snippets that Michel has displaying on the page go full screen on search (so essentially still autocomplete). There are some potential accessibility concerns there I'm sure that we would need to work around. |
superbiche
left a comment
There was a problem hiding this comment.
Did a quick review, some issues to fix but nothing shocking 👍
src/pages/search.js
Outdated
|
|
||
| let searchEvent | ||
| const getSlug = item => { | ||
| if (!item.publishDate) { |
There was a problem hiding this comment.
I think it's risky to rely on item.publishDate, imo adding a type argument to the arrow function would be safer
There was a problem hiding this comment.
Yeah, you're right, that's brittle. The type is not known when getSlug is called, though. We could refactor it to loop over those hits arrays separately and set the type there, I think. That could get a little messy as well, but I'll see if I can come up with something that will work.
There was a problem hiding this comment.
Imo looping over the results while retaining the type is the way to go, added searchResultTypes const to make it easier and gonna make result keys use keys from this constant so it should be more robust
There was a problem hiding this comment.
Used your new keys and getSanitizedSlug function to improve this.
| return `/blog/${item.slug}` | ||
| } | ||
|
|
||
| const goToResult = selectedItem => { |
There was a problem hiding this comment.
It amazes me Combobox doesn't allow choosing what we pass. @kevee do you know if there's a way to pass the item.objectID instead?
src/pages/search.js
Outdated
| }) | ||
|
|
||
| if (item && typeof window !== 'undefined') { | ||
| window.location = getSlug(item) |
There was a problem hiding this comment.
@jasonlcrane check out withLocation HOC, it passes location and navigate if I remember well.
You could add navigate to the component's props export default withSearch(({ search, navigate }) => { so you can then use it to go to the destination while retaining history.
(https://reach.tech/router/api/navigate)
There was a problem hiding this comment.
Thanks, good call. Updated.




Description
Draft PR to add Algolia search (#693)
Original todo from @kevee, please add items here so we don't get lost :) :
feature/header-refreshbranchRelated Issues
#693