fix: Add application nodes in advanced orchestration, unpublished applications are not filtered out

[shaohuzhang1]

fix: Add application nodes in advanced orchestration, unpublished applications are not filtered out

[f2c-ci-robot]

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[f2c-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[shaohuzhang1]

This code does not contain any obvious errors, but there are some areas that could be improved for better performance and readability:

1. Avoid Using map Inside Filter: The current implementation uses map inside the filter function to log each element before filtering. This is redundant because logging an element does not affect its inclusion in the filtered result.

2. Reduce Nesting Level: You can simplify the expression within the map function by removing the unnecessary wrapping with anonymous functions. Here’s how you can improve it:

   if (['global', 'chat'].includes(item.value) && item.children && item.children.length > 0) {
     console.log(item);
     return item;
   }

3. Consider Caching Results: If this function is called frequently and potentially involves expensive operations, consider caching results of expensive expressions like nodeModel.get_up_node_field_list() so they do not need re-computation unless necessary.

4. Error Handling: Ensure robust error handling is in place, especially around props.nodeModel, which might throw exceptions under certain conditions. This can prevent runtime errors from breaking the rest of your application.

Here's the refined version of the code based on these observations:

function visibleChange(bool: boolean) {
  const fields = props.global ? props.nodeModel.get_up_node_field_list(false, true).filter(
    (item: any) => ['global', 'chat'].includes(item.value) && item.children && item.children.length > 0
  );
  
  fields.forEach((field: any) => {
    console.log(field); // Log field only when included in the final list
  });

  options.value = fields; // Update options value only after processing
}

These changes make the code cleaner and more efficient while maintaining the intended functionality.

[shaohuzhang1]

The provided code is mostly correct, but there are a few areas to consider:

1. Type Annotations: While TypeScript annotations (any) can be useful for dynamic typing, they make it harder to catch type errors. Consider explicitly defining types for item, such as an interface or type. This will help catch issues at compile time.

2. Error Handling: The function does not include error handling mechanisms. If the API call fails, no alert or exception is thrown. It would be beneficial to add try-catch blocks around the API call to handle these cases gracefully.

3. Code Organization: While the logic looks clean, you might want to further divide the functionality into smaller, reusable functions if this function grows in complexity.

4. Performance Considerations: Ensure that the filtering operation on res.data is efficient. If applicationList.value could potentially contain a lot of data, consider memoization techniques or more optimized filtering strategies.

Here's an example with improved type annotations and added exception handling:

async async getApplicationList() {
  let folderId;
  
  try {
    const workspaceId = user.getWorkspaceId();
    
    // Fetch folder ID or use default workspace ID
    const response = await axios.get('/api/folders/current', { params: { workspaceId } });
    folderId = response.data?.folder?.id || workspaceId;

    const res = await fetchApplications(folderId);
    applicationList.value = res.data.filter((item: ApplicationItem) => {
      return item.resource_type === 'application' && item.id !== props.id && item.is_publish;
    });

    console.log('Successfully fetched application list');
  } catch (error) {
    console.error('Failed to fetch applications:', error);
    // Implement fallback mechanism or show an error message to the user
  }
}

Additional Recommendations:

• Environment Variables: Replace hardcoded URL paths like /api/folders/current with environment variables or configuration settings to improve maintainability.
• API Call: Use appropriate HTTP libraries or Axios consistently throughout your codebase for consistent API interactions.
• Testing: Write tests to cover different scenarios and edge cases, including failed API calls, to ensure robustness of the function.