refactor(web): network connection form UX (part 4)#3351
refactor(web): network connection form UX (part 4)#3351dgdavid merged 8 commits intoenhance-network-connection-formfrom
Conversation
Previously both fields defaulted to ConnectionMethod.AUTO, causing a
connection saved without an explicit method to round-trip as "auto",
making every edited connection appear as "Advanced" in the form instead
of "Automatic".
- Remove the AUTO default so absence of a method is represented as undefined
- Mark APIConnection.method4/method6 optional to reflect the backend may omit them
- toApi(): omit the fields when undefined
- fromApi(): assign as explicit own properties so object spreading when
merging config and system connections overrides system's "auto" correctly
Splits ConnectionForm into NewConnectionForm and EditConnectionForm. EditConnectionForm reads the connection from system state and pre-populates form fields via connectionToFormValues, so the user sees the current values when editing an existing connection.
When editing a connection, merge config and system connections giving precedence to config. This ensures the form reflects what the user explicitly saved: e.g. a connection with no method4 in config (the user chose "Automatic", meaning "do not put method in the config") correctly shows as Automatic instead of Advanced, which Agama backend or NetworkManager might report for automatic connections.
This prevents users changing the connection id, which is not fully supported at backend side yet.
The commit also extracts the Page shell to ConnectionForm and please linter.
…emoval WiredConnectionDetails now shows "None set" when method4/method6 is undefined, and the test mock explicitly sets AUTO to represent a DHCP connection. IpSettingsForm tests are skipped since the component is pending deletion.
| // TODO: evaluate whether this page and WiredConnectionDetails should merge config | ||
| // and system connections (like EditConnectionForm does) so that displayed values | ||
| // reflect what the user actually configured. Currently useConnections reads from | ||
| // the proposal source, which always reports e.g. method4: "auto" even when the | ||
| // config has no method set. If merging is not adopted here, ConnectionForm should | ||
| // be made consistent and drop its own merge too. |
There was a problem hiding this comment.
We were discussing this morning in a meeting the counterpart of this for properly displaying the right values when editing a connection. Maybe I missunderstood you, but I solved it by merging config and system documents, prioritizing the firtst one (see relevant commit if interested on it).
Later, I realized that fixing some stuff for it in current types (which are supposed to change too) made some other components fail, like the one in charge of displaying the details. It is using the proposal document.
Hence, this comment in the code.
I guess we should put some order in all of this. Meanwhile, I will continue ahead with the network connection form re-implementation, which is almost done as you can see. IMHO, this kind of decisions shouldn't block this feature branch, but being addressed as another PR instead.
Please, be aware of this concern.
Improvement suggested in code review.
A continuation of network connection form reimplementation, built on top of #3351. It prefills connection name when creating a new connection with a value based based on the connection type and the selected binding: - Any device: connection type only, no suffix. E.g., "Ethernet" - Chosen by name: connection type and device name. E.g., "Ethernet enp1s0" - Chosen by MAC: connection type and device MAC address. E.g., "Ethernet 001122334455" (colons stripped) The name updates reactively as the user changes the binding or device selection. Once the user manually edits the Name field, auto-filling stops. If the base name is already taken by an existing connection, a numeric suffix is appended (`Ethernet 2`, `Ethernet 3`, etc). Interesting reading: * https://tanstack.dev/form/latest/docs/framework/react/guides/basic-concepts#field-state
Prepare to release version 20. * #3294 * #3295 * #3296 * #3297 * #3298 * #3299 * #3300 * #3301 * #3302 * #3303 * #3304 * #3305 * #3306 * #3307 * #3308 * #3309 * #3310 * #3311 * #3312 * #3313 * #3315 * #3316 * #3317 * #3318 * #3319 * #3320 * #3322 * #3323 * #3325 * #3326 * #3327 * #3329 * #3330 * #3331 * #3333 * #3334 * #3336 * #3338 * #3339 * #3342 * #3343 * #3349 * #3351 * #3352 * #3353 * #3354 * #3356 * #3357 * #3358 * #3359 * #3360 * #3361 * #3362 * #3363 * #3364 * #3365 * #3366 * #3367 * #3368 * #3371 * #3372 * #3373 * #3375 * #3376 * #3378 * #3379 * #3380 * #3381 * #3382 * #3385 * #3386
This PR continues the network connection form reimplementation, built on top of #3349. It adds edit mode, fixes how the form derives the IP method when editing, and introduces a not-found empty state.
Edit mode
ConnectionFormis split intoNewConnectionFormandEditConnectionForm, both delegating to a sharedConnectionFormContent. When a routeidparam is present, the form pre-populates from the existing connection: IP mode, addresses, gateways, DNS servers, and search domains are all restored. The connection name field is not shown: it cannot be changed and the name is already visible in the breadcrumb.Not-found empty state
When the connection id from the route does not match any known connection,
EditConnectionFormrenders aConnectionNotFoundempty state page instead of crashing.Postponed for follow-up PRs
Notes for reviewers
Changelog entry postponed f r the final PR from the feature branch against master.