You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Traceflow form, some inputs / fields are rendered conditionally based on other inputs. For example, when selecting ICMP as the protocol, we do not want to render the "source port" and "destination port" input fields.
Similarly, we use the value of some inputs to determine the default value of other inputs. For example, when selecting UDP as the protocol, the default value for the "destination port" is 53, while it is 80 for TCP.
The current solution works ok, but seems a bit hacky to me. I have observed some strange behavior in some cases. #365 fixes a bug that was not affecting the first form submission, but was preventing subsequent form submissions when clicking the "Run Traceflow" button again without changing inputs. This was "fixed" by relaxing validation for the "destination port" input for ICMP, but it seems that the previous implementation should have prevented the first request from running, not just subsequent ones.
In the Traceflow form, some inputs / fields are rendered conditionally based on other inputs. For example, when selecting ICMP as the protocol, we do not want to render the "source port" and "destination port" input fields.
Similarly, we use the value of some inputs to determine the default value of other inputs. For example, when selecting UDP as the protocol, the default value for the "destination port" is 53, while it is 80 for TCP.
The current solution works ok, but seems a bit hacky to me. I have observed some strange behavior in some cases. #365 fixes a bug that was not affecting the first form submission, but was preventing subsequent form submissions when clicking the "Run Traceflow" button again without changing inputs. This was "fixed" by relaxing validation for the "destination port" input for ICMP, but it seems that the previous implementation should have prevented the first request from running, not just subsequent ones.
There is probably room for improvement, but that would require better knowledge of the react-hook-form library.
It seems that https://react-hook-form.com/docs/useform/watch is meant to be used for conditional rendering of inputs, and maybe https://react-hook-form.com/docs/useform/unregister could be useful as well?
I am also not sure that our usage of
reset
anddefaultValues
is fully correct, or at least optimal...The text was updated successfully, but these errors were encountered: