Skip to content
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

Qurator Omni: initial public release #4032

Merged
merged 121 commits into from
Oct 10, 2024
Merged

Qurator Omni: initial public release #4032

merged 121 commits into from
Oct 10, 2024

Conversation

nl0
Copy link
Member

@nl0 nl0 commented Jun 24, 2024

Description

Qurator Omni: Context-aware chat-based AI assistant.

The key changes include:

  1. Added a new Assistant component with model and UI subcomponents:

    • Model: Handles the core logic and state management for the assistant
    • UI: Provides the user interface for interacting with the assistant
  2. Integrated the assistant into the main app layout:

    • Added Assistant.Provider and Assistant.WithUI components to app.tsx
  3. Created new context providers for different views:

    • DirAssistantContext: Provides context for directory listings
    • FileAssistantContext: Provides context for file views
    • SearchAssistantContext: Provides context for search results
  4. Implemented a new Navigation utility for handling route matching and parameter parsing

  5. Added new utility modules:

    • Actor: A lightweight state management solution
    • Effect: Wrapper around the effect library for runtime configuration
    • Logging: Enhanced logging capabilities
    • XML: Utility for generating XML-like structures
  6. Updated existing components to integrate with the new assistant:

    • Modified Search, Bucket, and other relevant components to include assistant context providers
  7. Added new dependencies:

    • effect: For functional programming patterns
    • @effect/schema: For runtime type checking and validation
    • @effect/platform: For platform-specific utilities
  8. Updated TypeScript configuration to support new language features

  9. Removed the standalone Qurator component in favor of the more integrated assistant approach

  10. Made various improvements to existing utilities and components to support the new assistant functionality

This change introduces an AI-powered assistant that can provide context-aware help and information throughout the catalog application.

The assistant is designed to be extensible and can be easily integrated into different parts of the application.

Screenshot 2024-10-10 at 20 05 13

TODO

  • Changelog entry (skip if change is not significant to end users, e.g. docs only)

Copy link

codecov bot commented Jun 24, 2024

Codecov Report

Attention: Patch coverage is 26.14163% with 1116 lines in your changes missing coverage. Please review.

Project coverage is 37.71%. Comparing base (d64c432) to head (1e90cfa).
Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
...omponents/Assistant/Model/GlobalContext/preview.ts 0.00% 117 Missing and 17 partials ⚠️
...log/app/components/Assistant/Model/Conversation.ts 0.00% 112 Missing and 13 partials ⚠️
catalog/app/containers/Search/AssistantContext.tsx 0.00% 106 Missing and 3 partials ⚠️
catalog/app/components/Assistant/UI/Chat/Chat.tsx 0.00% 93 Missing ⚠️
catalog/app/utils/Actor.ts 0.00% 67 Missing and 6 partials ⚠️
catalog/app/components/Assistant/Model/Bedrock.ts 0.00% 49 Missing and 4 partials ⚠️
catalog/app/utils/Logging.ts 22.38% 44 Missing and 8 partials ⚠️
catalog/app/components/Assistant/Model/Context.tsx 29.41% 47 Missing and 1 partial ⚠️
...talog/app/components/Assistant/Model/Assistant.tsx 0.00% 43 Missing and 1 partial ⚠️
...alog/app/containers/Bucket/FileAssistantContext.ts 0.00% 41 Missing ⚠️
... and 32 more
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4032      +/-   ##
==========================================
- Coverage   38.11%   37.71%   -0.40%     
==========================================
  Files         735      765      +30     
  Lines       33844    35149    +1305     
  Branches     4800     5188     +388     
==========================================
+ Hits        12900    13258     +358     
- Misses      20320    20658     +338     
- Partials      624     1233     +609     
Flag Coverage Δ
api-python 91.00% <ø> (ø)
catalog 12.12% <26.14%> (+0.89%) ⬆️
lambda 87.95% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@nl0
Copy link
Member Author

nl0 commented Oct 9, 2024

@fiskus pls take a look when you have some spare time (tomorrow-ish?).
i realize this is not quite complete atm and the changeset is huge, but it'd be helpful to have another pair of eyes on this

@fiskus
Copy link
Member

fiskus commented Oct 10, 2024

The elephant in the room is effect, obviously. They lost me on the slides with code on the first page of their website: "with effect"/"without effect" are incorrect, manipulative comparisons. So, I didn't invest time in what I didn't like in the first place.

This places me in a difficult situation regarding this PR. I can't disagree with the core idea here, because there is already a lot of thoughtful, quality work around it. But I can't commit to use it either. At least, at this moment.

@nl0
Copy link
Member Author

nl0 commented Oct 10, 2024

"with effect"/"without effect" are incorrect, manipulative comparisons.

why?

@fiskus
Copy link
Member

fiskus commented Oct 10, 2024

image

On the left: why there is no proper type for output result. Why they throw Error instead of { ok: false, reason }. The code is not elegant but easily readable. If they use pipes on the right side, why they use try/catch instead of .then/.catch on the left?
On the right: code on the left is self-sufficient, why they didn't include HttpClientError and httpClient declaration? Does HttpClientError knows about error: "InvalidJson" | "RequestFailed"?

fiskus
fiskus previously approved these changes Oct 10, 2024
Copy link
Member

@fiskus fiskus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some inline comments so far.

Regarding, UI/UX: probably, it makes sense using plain text for user messages.


I didn't have time to read and test it, thoroughly. But from what I can see everything, except some TSFixMe, XXX and other not quite finished things, - is quite in a good shape.

Effect could be a good addition to our typescript codebase, though, I would like to have a conversation about it earlier and in a separate place.

@nl0
Copy link
Member Author

nl0 commented Oct 10, 2024

On the left: why there is no proper type for output result.
bc it's json and they don't type it (same on the right)

Why they throw Error instead of { ok: false, reason }.

probably on oversight, yeah

The code is not elegant but easily readable. If they use pipes on the right side, why they use try/catch instead of .then/.catch on the left?

🤷

On the right: code on the left is self-sufficient, why they didn't include HttpClientError and httpClient declaration?

these are their standard library component

Does HttpClientError knows about error: "InvalidJson" | "RequestFailed"?

no, it's just an http error


yeah, this looks quite contrived

@nl0
Copy link
Member Author

nl0 commented Oct 10, 2024

Regarding, UI/UX: probably, it makes sense using plain text for user messages.

what do you mean?

Effect could be a good addition to our typescript codebase, though, I would like to have a conversation about it earlier and in a separate place.

yeah, it's just was the easiest way to interface with tool calls (generate runtime types and matching json schemas).
and then i tried out some other features and it was just so much easier to deal with complex stuff, so i went all in
(btw it is a "successor" of sorts to fp-ts/io-ts, so switching over was just a matter of time, and since they have released a "stable" version, that time has come)

@fiskus
Copy link
Member

fiskus commented Oct 10, 2024

Regarding, UI/UX: probably, it makes sense using plain text for user messages.

Are user messages rendered with Markdown? I used [] in my message, and it was converted to an empty checkbox or something very similar. Probably, some font issue, not Markdown

@nl0 nl0 changed the title Qurator omni Qurator Omni: initial public release Oct 10, 2024
@nl0 nl0 requested review from fiskus and drernie October 10, 2024 18:06
@nl0
Copy link
Member Author

nl0 commented Oct 10, 2024

Regarding, UI/UX: probably, it makes sense using plain text for user messages.

Are user messages rendered with Markdown? I used [] in my message, and it was converted to an empty checkbox or something very similar. Probably, some font issue, not Markdown

oh, that. yes, they are

@nl0 nl0 marked this pull request as ready for review October 10, 2024 18:08
@nl0 nl0 added this pull request to the merge queue Oct 10, 2024
Merged via the queue into master with commit 81af353 Oct 10, 2024
38 of 39 checks passed
@nl0 nl0 deleted the qurator-omni branch October 10, 2024 19:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants