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
It seems that the default in browsers is to not include unchecked checkboxes at all (and the Switch is acting like a checkbox), but that link suggests this approach as an alternative if you'd like to include it.
It seems cleaner to capture the full state of the form (e.g. include disable_metric: false, multithreading: true, ... instead of just multithreading: on. This allows us to capture it, store it, display it, etc without assumptions about the state of the form in the past.
We could also add defaults on the server, however at this point I'm assuming tight coupling between the client (frontend) and server (sidecar/controller). Maintaining backwards compatibility is simply out of scope at this point, as the whole thing is not at all mature enough.
This flow will soon change, as the queries will be started from a queue, and not directly from a form. There is an opportunity to change this (e.g., we read the params from the DB, populate defaults, submit to controllers), if we have a strong opinion.
Maybe my understanding of how UI works is obsolete, I was imagining before rendering we sent a JS object that represents the defaults for query parameters. Then, when form_data comes back, we merge them, overriding the values set in UI and ignoring the ones that didn't come. This can be done in one place without requiring patching each individual checkbox.
A few notes from #41:
disable_metric: false, multithreading: true, ...
instead of justmultithreading: on
. This allows us to capture it, store it, display it, etc without assumptions about the state of the form in the past.Originally posted by @eriktaubeneck in #41 (comment)
The text was updated successfully, but these errors were encountered: