Message::InputError 시 적절한 처리

[sehkone]

aice-web에 포함되어 있을 때에는 home component에 바로 접근할 수 있었으나, 라이브러리로 동작하는 frontary 에서는 직접 home에 접근할 수는 없다. 따라서, Message::InputError 발생의 경우 에러 메시지를 표시하는 방법을 달리 고안하여야 한다.

[sehkone]

Message::FailLoadFile도 에러 메시지를 표시하는 방법이 고안되어야 한다. InputError와는 다르게 할 수도 있다.

[octoaide[bot]]

Hello @sehkone,

Thanks for raising this issue and for the clarifying comment regarding Message::FailLoadFile. This issue highlights important TODOs in the codebase related to error handling for user inputs and file operations.

Currently, the Message::InputError variant is used in src/ip_range_input.rs, src/text_input.rs, and src/port_range_input.rs, and also appears in src/input/component.rs as a generic fallback when input elements cannot be properly retrieved from the DOM. Similarly, Message::FailLoadFile is noted in src/input/component.rs after a file loading attempt fails. In both cases, the code explicitly points back to this issue with // TODO: issue #5.

To address this, I propose leveraging the existing notification system defined in src/notification.rs. This system is well-suited for displaying user-friendly error messages.

Here are the suggested next steps:

1. Introduce new CommonError variants in src/notification.rs:

   • Add a variant like CommonError::InputProcessingError for cases where input from a DOM element cannot be processed (e.g., due to unexpected DOM structure or event issues, which trigger Message::InputError).
   • Add a variant like CommonError::FileLoadingError for when a file fails to load (corresponding to Message::FailLoadFile).

2. Integrate Message::FailLoadFile handling:

   • In src/input/component.rs, when Message::FailLoadFile is received, create a NotificationItem using gen_notifications(NotificationType::CommonError(CommonError::FileLoadingError)) and display it. This will provide immediate feedback to the user that their file could not be loaded.

3. Integrate Message::InputError handling:

   • For Message::InputError in src/ip_range_input.rs, src/text_input.rs, and src/port_range_input.rs, these components currently have a TODO. Since these are self-contained input components, they should probably emit an event or message that a parent component (which likely has access to the Notification model) can catch and display. This could be done by sending a new message type up the component tree, for example, ParentMessage::DisplayNotification(NotificationItem).
   • In src/input/component.rs, the Message::InputError is a generic catch-all. It should also trigger a notification using gen_notifications(NotificationType::CommonError(CommonError::InputProcessingError)). This would cover any unexpected input parsing failures that aren't caught by more specific validation checks.

This approach would centralize error display through the existing notification system, providing a consistent user experience for these types of errors.

Does this proposed approach align with your expectations for handling these errors? Your feedback would be greatly appreciated to move this forward.

Thank you for your contribution!

[sehkone]

I think this issue looks requiring further brainstorming, therefore I am moving it into the discussion.