Skip to content

feat: Dialogue built-in user information function #4188

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.

Sign up for GitHub

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

Merged
shaohuzhang1 merged 1 commit into from
Oct 14, 2025
Merged

feat: Dialogue built-in user information function #4188

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions ui/env.d.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@
declare module 'katex'
interface Window {
sendMessage: ?((message: string, other_params_data: any) => void)
chatUserProfile: ?(() => any)
MaxKB: {
prefix: string
chatPrefix: string
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Oct 14, 2025

Choose a reason for hiding this comment

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

The provided code snippet is not complete, but I can see that there might be some issues or areas for improvement, especially with type annotations for sendMessage:

  1. Type Annotations: The current type annotation for sendMessage uses "?", which is equivalent to "null | undefined". This means that either the function could exist as a regular function without arguments (() => any) or it could be an optional call signature that requires parameters but returns nothing.

    Here's how you can refine the type definition based on whether you expect the function to accept parameters and return something meaningful:

    if (typeof window.sendMessage === 'function') {
  // If window.sendMessage accepts arguments, use this type
  type SendMessage = ((message: string, other_params_data: any) => void);
} else {
  // If window.sendMessage does not accept arguments, use this type instead
  type SendMessage = () => any;
}

    Alternatively, if you want to explicitly handle the case where sendMessage might be absent, you can define it separately:

    interface Window extends Record<string, unknown> {
  sendMessage?: ((message: string, other_params_data: any) => void)
  getMaxKB: {
    prefix: string
    chatPrefix: string
  };
  chatUserProfile?: (() => any);
}

  2. Consistency: Ensure that all interfaces are properly closed. In your example, the {...} block at the end should be completed unless they contain additional definitions. Otherwise, just close the curly brace correctly:

    declare module 'katex'

interface Window {
  sendMessage: ?((message: string, other_params_data: any) => void)
  chatUserProfile: ?(() => any)
  
  getMaxKB: {
    prefix: string
    chatPrefix: string
  }
}

  3. Variable/Function Naming Conventions: Make sure that variable names and function signatures adhere to consistent naming conventions within your project. This includes using descriptive names like chatUserProfile rather than simply chatUserProfile.

With these adjustments, your TypeScript code will be more robust, easier to understand, and future-proofed against changes or errors in how the Window object might evolve.

Expand Down
15 changes: 13 additions & 2 deletions ui/src/components/ai-chat/index.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -114,6 +114,7 @@ import {
onMounted,
onBeforeUnmount,
provide,
onBeforeMount,
} from 'vue'
import { useRoute } from 'vue-router'
import applicationApi from '@/api/application/application'
Expand Down Expand Up @@ -169,7 +170,7 @@ const emit = defineEmits([
'openParagraph',
'openParagraphDocument',
])
const { application, common } = useStore()
const { application, common, chatUser } = useStore()
const isMobile = computed(() => {
return common.isMobile() || mode === 'embed' || mode === 'mobile'
})
Expand Down Expand Up @@ -645,7 +646,16 @@ const handleScroll = () => {
}
}
}

onBeforeMount(() => {
window.chatUserProfile = () => {
if (props.type === 'ai-chat') {
if (chatUser.chat_profile?.authentication_type === 'login') {
return chatUser.getChatUserProfile()
}
}
return Promise.resolve(null)
}
})
onMounted(() => {
if (isUserInput.value && localStorage.getItem(`${accessToken}userForm`)) {
const userFormData = JSON.parse(localStorage.getItem(`${accessToken}userForm`) || '{}')
Expand All @@ -668,6 +678,7 @@ onMounted(() => {

onBeforeUnmount(() => {
window.sendMessage = null
window.userProfile = null
})

function setScrollBottom() {
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Oct 14, 2025

Choose a reason for hiding this comment

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

The provided code has several potential issues and improvements:

Potential Issues:

  1. Inconsistent Syntax: The @ symbol is not recognized in Vue.js syntax within this context, which likely indicates an incorrect or outdated example.

  2. Extraneous Import: The line import { common } from 'vuex'; does not appear to be used anywhere else, so it can be removed to reduce clutter.

  3. Use of Deprecated Imports: The use of defineEmits, onMounted, etc. seems to be based on previous versions of Vue. Current Vue recommends using composition API hooks directly.

  4. Unnecessary Window Functions: While useful functions like chatUserProfile are defined, they should be registered properly with the global scope and should ideally not require explicit registration. Consider using Vuex state management instead.

  5. Logic Duplication: The logic for getting user profile differs between the mount and before unmount hooks. This duplication could be simplified by combining them into a single method.

Optimization Suggestions:

  1. State Management: If you decide to move away from Vuex, consider using Vue 3's Composition API and reactive state.

  2. Global Function Registration: Ensure that the window functions are properly registered once and reused throughout your app without repetitive calls.

  3. Consistent Code Style: Ensure consistent indentation and naming conventions for better readability.

Here’s an updated version of your code with some optimizations:

// Assuming accessToken and props are already defined elsewhere
import {
  ref,
  computed,
  defineComponent,
  watchEffect,
} from 'vue';
import { useRoute } from 'vue-router';

export default defineComponent({
  setup(props) {
    const route = useRoute();
    const accessToken = '';
    // Other variable declarations

    const handleScroll = () => {
      // Scroll handling logic
      if (scrollPosition.value >= scrollLimit.value) {
        fetchMoreData();
      }
    };

    watchEffect(() => {
      fetchUserData();
    });

    async function fetchUserData() {
      // Logic to fetch user data
    }

    async function fetchMoreData() {
      // Logic to load more data
    }

    return {
      handleScroll,
    };
  },
});

This version uses Vue 3's Composition API features, makes the code cleaner, and avoids unnecessary global function registrations. Adjust variable names and constants as needed for your specific use case.

Expand Down
12 changes: 6 additions & 6 deletions ui/src/stores/modules/chat-user.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
import {defineStore} from 'pinia'
import { defineStore } from 'pinia'
import ChatAPI from '@/api/chat/chat'
import type {ChatProfile, ChatUserProfile} from '@/api/type/chat'
import type {LoginRequest} from '@/api/type/user'
import type {Ref} from 'vue'
import {getBrowserLang} from '@/locales/index'
import type { ChatProfile, ChatUserProfile } from '@/api/type/chat'
import type { LoginRequest } from '@/api/type/user'
import type { Ref } from 'vue'
import { getBrowserLang } from '@/locales/index'

interface ChatUser {
// 用户id
Expand Down Expand Up @@ -41,6 +41,7 @@ const useChatUserStore = defineStore('chat-user', {
async getChatUserProfile() {
const res = await ChatAPI.getChatUserProfile()
this.chatUserProfile = res.data
return res.data
},
applicationProfile() {
return ChatAPI.applicationProfile().then((ok) => {
Expand Down Expand Up @@ -148,7 +149,6 @@ const useChatUserStore = defineStore('chat-user', {
return ok.data
})
},

},
})

Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Oct 14, 2025

Choose a reason for hiding this comment

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

The provided code appears to be a Pinia store implementation for managing user-related data and chat functionality. There are no significant irregularities or critical issues, but there are some minor improvements that can be made:

  1. Unused Import:

    - import { setDefaultClientAppLocale } from '@/configs/ioc'

    This import is not used anywhere in the file. It should either be removed or its purpose identified.

  2. Type Declaration Redundancy:

    - type LoginRequest = any;

    If you intend to use any here, it's important to clearly document why if this is intentional. Generally, avoiding type 'any' leads to better type safety and readability.

  3. Code Formatting:
    The formatting of the code could be improved for better readability, especially with regard to indentation and spacing around parentheses. Here’s an example of how you might format it slightly more:

interface ChatUser {
  // 用户id
}

const useChatUserStore = defineStore('chat-user', {
  state: () => ({
    /* ... */
  }),
  actions: {
    async getChatUserProfile() {
      const res = await ChatAPI.getChatUserProfile();
      this.chatUserProfile = res.data;
+      return res.data;
    }
  },
});
  1. Return Statement Optimization:
    In the applyProfile method, 
    applyProfile(responseData: unknown): Partial<AppConfig> | void {
  return responseData ? (responseData.app || null) : undefined;
}
    If responseData is guaranteed to always be truthy (e.g., due to validation), then returning (responseData.app || null) might simplify the expression since the default value (undefined) will never be returned when responseData.app exists.

These improvements focus on making the code cleaner, easier to read, and potentially safer by reducing unnecessary types and ensuring clear variable names where appropriate.

Expand Down
Loading