feat(TagImprovement): Improved tag dropdown and outputselect

[mhbdev]

Summary

Previously we could not filter outputs based on user inputs. From now on outputs of a tool will also support a condition field.

Example: arxiv

Instead of using comments to separate different types of responses like this:

  outputs: {
    // Search output
    papers: { type: 'json', description: 'Found papers data' },
    totalResults: { type: 'number', description: 'Total results count' },
    // Get Paper Details output
    paper: { type: 'json', description: 'Paper details' },
    // Get Author Papers output
    authorPapers: { type: 'json', description: 'Author papers list' },
  },

we can say:

    papers: { type: 'json', description: 'Found papers data', condition: {field: 'operation', value: 'arxiv_search'} },
    totalResults: { type: 'number', description: 'Total results count', condition: {field: 'operation', value: 'arxiv_search'} },

Fixes #(issue)

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

It is not a breaking change but you can focus on checking the functionality in the app.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

Solves #905

[vercel]

@mhbdev is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR introduces conditional output filtering functionality to enable dynamic display of tool outputs based on block configuration values. The implementation adds a condition property to the OutputFieldDefinition type that supports field-based conditions with array values, negation (not), and AND logic.

The core changes span three files:

1. Type Definition (blocks/types.ts): Extended OutputFieldDefinition with an optional condition property that follows the same pattern as existing input conditions in the codebase

2. Output Select Component (output-select.tsx): Added three helper functions (getBlockCurrentValues, evaluateOutputCondition, filterOutputsByConditions) that retrieve current block values and filter outputs based on conditions. The filtering is applied when processing outputs (lines 182-185)

3. Tag Dropdown (tag-dropdown.tsx): Integrated the same conditional filtering logic throughout the tag generation process, ensuring output tags are dynamically shown/hidden based on current block state

This addresses the problem where tools like arxiv had to use comments to separate different output types for different operations (search, get paper details, etc.). Now developers can define conditions like {field: 'operation', value: 'arxiv_search'} to show specific outputs only when relevant, creating a cleaner and more contextual user interface.

The implementation maintains consistency with existing condition evaluation patterns used elsewhere in the codebase, particularly mirroring the logic found in SubBlockConfig for input conditions.

Confidence score: 3/5

• This PR introduces moderate complexity with potential type safety concerns and needs careful testing
• Score reflects the addition of conditional logic that could have edge cases with undefined values and type mismatches
• Pay close attention to the condition evaluation logic and type definitions in blocks/types.ts

_{3 files reviewed, 5 comments}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

logic: Non-null assertion operator used without null check. Consider adding explicit null check for condition.and before accessing nested properties.

[greptile-apps]

logic: Using non-null assertion operator (!) on condition.and!.field could throw if condition.and is undefined despite the guard check. Consider using optional chaining: condition.and?.field

Suggested change

	const andFieldValue = currentValues[condition.and!.field]
	const andFieldValue = currentValues[condition.and?.field]

[greptile-apps]

logic: The undefined type for value in the and condition seems inconsistent with the main condition which doesn't allow undefined. This could lead to unexpected behavior.

Suggested change

	value: string | number | boolean | Array<string | number | boolean> | undefined
	value: string | number | boolean | Array<string | number | boolean>

[greptile-apps]

style: Consider extracting the condition type into a separate interface since it's duplicated in SubBlockConfig (lines 134-154). This would improve maintainability and ensure consistency.

Context Used: Context - When defining properties for components, use a dedicated config file (.ts) for configuration and keep rendered components in their respective component files. (link)

[greptile-apps]

style: The union type for value is quite complex. Consider creating a separate type alias for ConditionValue to improve readability.