-
Notifications
You must be signed in to change notification settings - Fork 126
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
[front] - chore(InputBar):support slack URL pasting #11492
base: main
Are you sure you want to change the base?
Conversation
- Added a list of MIME types for nodes that cannot be pasted [front/lib/swr] - feature: support use case distinction in search parameters - Enhanced search function to differentiate between paste and search node use cases [front/pages/api] - refactor: filter search results based on use case - Implemented use case-specific exclusion of node MIME types in search results
…action - Implement URL matching and information extraction for Slack archive links - Support both thread-specific links and message links within a specific week range
… bar container - Include a new 'useCase' prop to enhance the input bar's functionality [front/lib] - refactor: streamline slack URL node ID extraction - Refactor URL node ID extraction for Slack by structuring it in individual methods - Utilize a common utility method 'getWeeklyDateRange' to calculate weekly date ranges for messages
- Removed `client_side_new_id` as it was relying on UUIDs, which are not needed anymore - Deleted `utcDateFrom` function since it's no longer being used in the codebase - Eliminated the `trimText` function to streamline the utilities available
- Implement Slack URL matching and node ID extraction for different Slack URL patterns - Extend utils with `getWeeklyDateRange` function to assist in generating Slack message node IDs [extension/ui] - refactor: include `useCase` in spaces search hook and input bar container - Pass "pasteUrl" as `useCase` to spaces search hook when used within `InputBarContainer` - Ensure the new use case parameter aligns with different usage scenarios for the search hook
- Added a new union type for `ContentNodeSearchUseCase` to handle different search scenarios - Extended `BaseSearchBodySchema` with a `useCase` field to utilize the new search use cases in requests
|
- Removed the 'undefined' type from the useCase union in BaseSearchBody, enforcing explicit useCase specification [sdks] - fix: remove undefined type from ContentNodeSearchUseCase - Corrected the ContentNodeSearchUseCase by removing the option for it to be undefined, ensuring consistency with the API changes
- Extended search API to support a 'useCase' parameter with enum options - The new parameter helps differentiate search contexts, such as 'pasteUrl' or 'searchNode'
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.
👋 We might have misunderstood each other here (no biggie)
The point when I added slack threads back into the mix was "because it was extremely simple" (I thought I had told you that, sorry if I didnt). The converse being that if it turns out not to be simple, we leave it out of the mix
The goal as per the card was only to support threads; wouldn't that have been just adding a matcher and extractor in Provider?
If yes, let's go for that. If not, let's discuss if we move forward, not sure it's worth the added complexity
Happy to discuss IRL :)
- Changed providers object keys to match ConnectorProvider type definition [front/lib] - refactor: align connector provider keys with shared definitions - Updated provider keys in the providers object to ensure consistency with shared connector naming convention
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.
looks great, as discussed aro we can move forward with this PR. left a few you comments but mosty I would avoid using "useCase" and rather expose mimetypes, I think it'd be more readable avoiding creating a new abstraction
extractor: (url: URL): string | null => { | ||
// Try each type of extraction in order | ||
return ( | ||
extractChannelNodeId(url) || |
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.
are we sure we'll never exit with a channel while there was actually a thread?
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.
or like this is a bit tricky to read logic fast, but if we have to keep it IMO start with the most specific (thread) and end with the most general (channel)
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.
Channel have "client" in the URL, while thread and messages have "archives", so we should be safe here 👌🏼
Will reorder checks
|
||
// Extract a thread node ID from a Slack archives URL | ||
function extractThreadNodeId(url: URL): string | null { | ||
const pathParts = url.pathname.split("/"); |
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.
question: threads always have archive?
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.
It seems like it yes and messages too 👍🏼
extension/shared/lib/utils.ts
Outdated
return { startDate, endDate }; | ||
} | ||
|
||
function getWeekEnd(startDate: Date): Date { |
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.
nit: a bit ricky here to have weekstart work with any date but wekend needs the weekstart while they have the same naming patttern.
would either have only one fn returning both or have both woek with any date
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.
Fair
@@ -9,26 +8,13 @@ export function classNames(...classes: (string | null | boolean)[]) { | |||
return classes.filter(Boolean).join(" "); | |||
} | |||
|
|||
export function client_side_new_id() { |
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.
is that related?
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.
Just a clean up 🧹 (saw there was a few unused functions)
- Deleted the `useCase: "pasteUrl"` property from search components and API - Removed `NON_PASTABLE_NODES_MIME_TYPES` as it's no longer needed due to the removal of the pasteUrl use case - Updated SWR hooks and API handlers to exclude the useCase parameter from their logic [sdks] - refactor: eliminate ContentNodeSearchUseCase type - Removed the `ContentNodeSearchUseCase` enum as the pasteUrl use case is no longer supported
… and input bar - Eliminated the 'useCase' property handling from useSpacesSearch hook - Removed 'useCase' from input props to simplify pasteUrl functionality - Cleaned up related effect and params in InputBarContainer to align with hook changes
- Consolidate week boundary logic into a single `getWeekBoundaries` function - Remove separate `getWeekStart` and `getWeekEnd` functions for simplification [connectors] - refactor: update usage of week boundary utilities - Replace `getWeeklyDateRange` with `getWeekBoundaries` to adhere to updated utils - Reorder extraction methods for consistency and potential performance benefits
- Recognize and handle Slack thread and message URLs with "/archives/" in the path - Identify Slack channel URLs that contain "/client/" in the pathname
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.
👍 thanks!
Description
This PR adds support for Slack URLs in the
nodeIdFromUrl
utility function. It now handles three types of Slack URLs:https://app.slack.com/client/TEAM_ID/CHANNEL_ID
→slack-channel-CHANNEL_ID
https://team.slack.com/archives/CHANNEL/TIMESTAMP?thread_ts=THREAD_TS
→slack-CHANNEL-thread-THREAD_TS
https://team.slack.com/archives/CHANNEL/pTIMESTAMP
→slack-CHANNEL-messages-YYYY-M-D-YYYY-M-D
(weekly range)Since those mime types were filtered out during search we introduce a "useCase" parameter on the search endpoint, to filter out relevant mime types depending on the use case at hand.
Risk
Low, behind FF
Deploy Plan
Deploy front