langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-22 12:36:14 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[Chore/Refactor] Fix TypeScript errors in app overview components #16136

New Issue
Closed
opened 2026-02-21 19:24:47 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 19:24:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @lyzno1 on GitHub (Aug 13, 2025).

Description

Multiple TypeScript errors exist in the app overview components affecting development experience:

  • 2 TypeScript errors in appCard.tsx related to improper use of SWR Fetcher pattern
  • 8 TypeScript errors in appChart.tsx related to type mismatches in data processing
  • File naming inconsistency using camelCase instead of kebab-case convention

Motivation

These TypeScript errors:

  1. Create a poor development experience with constant error warnings
  2. Indicate potential runtime issues with improper async patterns
  3. Violate project coding standards for file naming conventions
  4. May cause IDE performance issues with constant type checking errors

The errors specifically occur in:

  • fetchAppDetail().then() usage which is incorrect for SWR Fetchers
  • Number.parseFloat() type safety issues with dynamic property access
  • Inconsistent file naming patterns affecting code organization

Additional Context

These are existing components in the application overview section that need refactoring for type safety and code consistency. The errors affect the monitoring cards and application management components.

Originally created by @lyzno1 on GitHub (Aug 13, 2025). ## Description Multiple TypeScript errors exist in the app overview components affecting development experience: - 2 TypeScript errors in `appCard.tsx` related to improper use of SWR Fetcher pattern - 8 TypeScript errors in `appChart.tsx` related to type mismatches in data processing - File naming inconsistency using camelCase instead of kebab-case convention ## Motivation These TypeScript errors: 1. Create a poor development experience with constant error warnings 2. Indicate potential runtime issues with improper async patterns 3. Violate project coding standards for file naming conventions 4. May cause IDE performance issues with constant type checking errors The errors specifically occur in: - `fetchAppDetail().then()` usage which is incorrect for SWR Fetchers - `Number.parseFloat()` type safety issues with dynamic property access - Inconsistent file naming patterns affecting code organization ## Additional Context These are existing components in the application overview section that need refactoring for type safety and code consistency. The errors affect the monitoring cards and application management components.
yindo closed this issue 2026-02-21 19:24:47 -05:00
yindo commented 2026-02-21 19:24:47 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 13, 2025):

Here’s how you can address the TypeScript errors and code consistency issues in the app overview components:

For appCard.tsx, the main problem is using fetchAppDetail with .then() chaining in a callback, which is not the intended SWR fetcher pattern. fetchAppDetail is designed as a SWR fetcher (returns a promise directly), so for direct API calls (like in handleAccessControlUpdate), switch to using fetchAppDetailDirect instead. This avoids async misuse and aligns with SWR best practices. Refactor the callback to use async/await with fetchAppDetailDirect, not .then() on fetchAppDetail. See the fetcher implementations for reference: fetchAppDetail and fetchAppDetailDirect.

In appChart.tsx, the TypeScript errors stem from dynamic property access and type mismatches, especially with Number.parseFloat(get(item, 'total_price', '0')). The chart data types are statically known, but the code uses dynamic keys and @ts-expect-error to bypass type checks. Refactor by mapping chartType to a known field name (e.g., 'message_count', 'conversation_count', 'total_price') and use explicit property access instead of dynamic keys. Avoid Number.parseFloat on fields already typed as numbers (like total_price in AppTokenCostsResponse). This will eliminate the need for @ts-expect-error and improve type safety. See the relevant code patterns: appChart.tsx and type definitions.

On file naming: the codebase does not enforce kebab-case for component files; camelCase and PascalCase are common. If you want to standardize on kebab-case, you’ll need to rename files and update imports, but be aware there’s no tooling or documented policy enforcing this yet. Consistency is more important than the specific convention—choose one and document it for your team. More on naming: project file naming practices.

These changes will resolve the TypeScript errors, improve type safety, and bring code consistency to the app overview components.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 13, 2025): <!-- Answer --> Here’s how you can address the TypeScript errors and code consistency issues in the app overview components: For appCard.tsx, the main problem is using fetchAppDetail with .then() chaining in a callback, which is not the intended SWR fetcher pattern. fetchAppDetail is designed as a SWR fetcher (returns a promise directly), so for direct API calls (like in handleAccessControlUpdate), switch to using fetchAppDetailDirect instead. This avoids async misuse and aligns with SWR best practices. Refactor the callback to use async/await with fetchAppDetailDirect, not .then() on fetchAppDetail. See the fetcher implementations for reference: [fetchAppDetail and fetchAppDetailDirect](https://github.com/langgenius/dify/blob/7286b4ad0610c61d2102d52c40433af3b0ce388f/web/service/apps.ts). In appChart.tsx, the TypeScript errors stem from dynamic property access and type mismatches, especially with Number.parseFloat(get(item, 'total_price', '0')). The chart data types are statically known, but the code uses dynamic keys and @ts-expect-error to bypass type checks. Refactor by mapping chartType to a known field name (e.g., 'message_count', 'conversation_count', 'total_price') and use explicit property access instead of dynamic keys. Avoid Number.parseFloat on fields already typed as numbers (like total_price in AppTokenCostsResponse). This will eliminate the need for @ts-expect-error and improve type safety. See the relevant code patterns: [appChart.tsx](https://github.com/langgenius/dify/blob/7286b4ad0610c61d2102d52c40433af3b0ce388f/web/app/components/app/overview/appChart.tsx) and [type definitions](https://github.com/langgenius/dify/blob/7286b4ad0610c61d2102d52c40433af3b0ce388f/web/models/app.ts). On file naming: the codebase does not enforce kebab-case for component files; camelCase and PascalCase are common. If you want to standardize on kebab-case, you’ll need to rename files and update imports, but be aware there’s no tooling or documented policy enforcing this yet. Consistency is more important than the specific convention—choose one and document it for your team. More on naming: [project file naming practices](https://github.com/langgenius/dify/blob/7286b4ad0610c61d2102d52c40433af3b0ce388f/web/app/components/app/overview/appCard.tsx). These changes will resolve the TypeScript errors, improve type safety, and bring code consistency to the app overview components. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/4719d4cf-e0a4-4bec-87b3-ef81a9297abe?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/4719d4cf-e0a4-4bec-87b3-ef81a9297abe?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/4719d4cf-e0a4-4bec-87b3-ef81a9297abe?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/4719d4cf-e0a4-4bec-87b3-ef81a9297abe?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/4719d4cf-e0a4-4bec-87b3-ef81a9297abe?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/4719d4cf-e0a4-4bec-87b3-ef81a9297abe?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/4719d4cf-e0a4-4bec-87b3-ef81a9297abe?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23900)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#16136
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?