[Security Solution] Extend form lib with warnings #203097
Labels
enhancement
New value added to drive a business result
Team:Detection Rule Management
Security Detection Rule Management Team
Team:Detections and Resp
Security Detection Response Team
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
triage_needed
Summary
Form lib should support warnings in a flexible way. Each validation should have an ability to return blocking and non blocking errors (a.k.a. warnings).
Details
Form lib implements warning functionality via non blocking validators.
validations
allows tospecify validation configuration with validator functions and extra parameters includingisBlocking
. Validators marked asisBlocking
will produce non blocking validation errors a.k.a. warnings.The problem with the supported approach is lack of flexibility and necessary API like one for getting only blocking or non blocking errors. Flexibility requirement comes from complex async validators producing blocking and non blocking validation errors. There is no way to use
isBlocking
configuration option to separate errors. Separating such validating functions in two would lead to sending two HTTP requests and performing another async operations twice.On top of just having an ability to mark validation errors as non blocking via
isBlocking: false
configuration we require a way to return blocking and non blocking errors from a single validation function. It'd be possible by returning an error withisBlocking
(orisWarning
) flag along withmessage
andcode
fields from a validator function. Attempts to reuse__isBlocking__
internal field lead to inconsistent behavior.useFormWithWarn
implemented in #202544 provides warnings (non blocking errors) implementatio on top ofFormHook
using validation error codes as a flexible way to determine whether an error is a blocking error or it's a warning. It provides little interface extension to simplify errors and warnings consumptionIn some cases business logic requires implementing functionality to allow users perform an action despite non-critical validation errors a.k.a. warnings. Usually it's also required to inform users about warnings they got before proceeding for example via a modal.
Instead of spawning
FormHook
extensions we should have properly documented necessary warnings functionality in Form lib. It will help engineers building forms with better UX spending less efforts on reinventing warnings functionality.The text was updated successfully, but these errors were encountered: