-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: zendesk search integration #2722
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git βοΈ
|
π¦ Next.js Bundle AnalysisThis analysis was generated by the next.js bundle analysis action π€ Ninety-three Pages Changed SizeThe following pages changed size from the code in this PR compared to its base branch:
DetailsOnly the gzipped size is provided here based on an expert tip. First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If Any third party scripts you have added directly to your app using the Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. |
Adding do not merge label until support team is ready for launch |
@@ -23,7 +23,7 @@ const PRODUCT_SLUGS_WITH_INTEGRATIONS = | |||
* Each content type tab has a set of properties required for rendering. | |||
*/ | |||
export interface UnifiedSearchTabContent { | |||
type: 'global' | 'docs' | 'tutorials' | 'integrations' | |||
type: 'global' | 'docs' | 'tutorials' | 'integrations' | 'knowledgebase' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type: 'global' | 'docs' | 'tutorials' | 'integrations' | 'knowledgebase' | |
type: UnifiedSearchableContentType |
@@ -7,7 +7,10 @@ import { ReactNode, createContext, useContext, useState } from 'react' | |||
|
|||
const SearchHitsContext = createContext([]) | |||
|
|||
type HitCounts = Record<'docs' | 'tutorials' | 'integrations', number> | |||
type HitCounts = Record< | |||
'docs' | 'tutorials' | 'integrations' | 'knowledgebase', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about using the existing UnifiedSearchableContentType
to replace these unions (albeit with Exclude
to yank 'global' out of there in this specific instance) instead?
'docs' | 'tutorials' | 'integrations' | 'knowledgebase', | |
Exclude<UnifiedSearchableContentType, 'global'> |
@@ -36,6 +36,7 @@ export type UnifiedSearchableContentType = | |||
| 'docs' | |||
| 'integration' | |||
| 'tutorial' | |||
| 'knowledgebase' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about rewriting this union type as an enum (as the source of truth for the values) and then a template literal type to generate the union type.
export enum SearchContentTypes {
GLOBAL = 'global',
DOCS = 'docs',
INTEGRATION = 'integration',
TUTORIAL = 'tutorial',
KNOWLEDGEBASE = 'knowledgebase',
}
/**
* Derived union type from {@link SearchContentTypes}
*/
export type UnifiedSearchableContentType =`${SearchContentTypes}`
It should be functionally the same
However, it would also provide some advantages
-
It would give us the advantages of using an enum (such as the ability to refer canonically to those values elsewhere in the code like here) so we could use
SearchContentTypes.GLOBAL
instead of just the string'global'
. This seems trivial, but during the discovery phase of this ticket, I noticed there are a few typos in the existing code (we have'global' | 'docs' | 'tutorials' | 'integrations'
here, here and here......and thenhit.type !== 'integration'
here) -
It would also allow us to provide documentation for the enum values (if we wanted) like this:
export enum SearchContentTypes { GLOBAL = 'global', DOCS = 'docs', INTEGRATION = 'integration', TUTORIAL = 'tutorial', /** * Data from zendesk */ KNOWLEDGEBASE = 'knowledgebase' }
What do you think?
@@ -16,7 +16,7 @@ import type { UnifiedHitProps } from '../types' | |||
*/ | |||
export function getUnifiedHitProps(hit: Hit): UnifiedHitProps { | |||
// Content type, for icon | |||
const type = hit.type as 'docs' | 'tutorial' | 'integration' | |||
const type = hit.type as 'docs' | 'tutorial' | 'integration' | 'knowledgebase' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const type = hit.type as 'docs' | 'tutorial' | 'integration' | 'knowledgebase' | |
const type = hit.type as Exclude<SearchContentTypes, 'global'> |
π Relevant links
ποΈ What
This PR adds a 'Support' tab to the dev-portal search modal. The content from this tab is sourced from the algolia indexes for zendesk (dev_ZENDESK and prod_ZENDESK depending on environment). It also adds a little external link icon to the end of the url for support items.
Since zendesk articles don't have descriptions like the docs or tutorials articles do, I used the algolia snippet component to get a section of where the search term originated in the body of the zendesk article.
πΈ Design Screenshots
π§ͺ Testing