refactor(web): network connection form UX (part 5)

[dgdavid]

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).

Check the not so good screencast below

auto-generated-connection-name.mp4

Interesting reading:

• https://tanstack.dev/form/latest/docs/framework/react/guides/basic-concepts#field-state

Notes for reviewers

• Merges refactor(web): network connection form UX (part 4) #3351 first.
• Better to review once refactor(web): network connection form UX (part 4) #3351 is merged (this PR is actually about last 2 commits).
• Changelog entry postponed for the final PR from the feature branch against master.

[ancorgs]

I'm not advocating for it, but note it is not unusual to have spaces in the connection names (starting with a capital letter).

For example, the default connection created during the live-ISO boot is called "Wired connection 1". Also, if I use the applet from my desktop and select "New connection" -> "Ethernet" I get the name pre-filled as "Ethernet connection 1".

And for WiFi connections, it is quite common to use the ESSID to name of the connection.

Having said so, I have nothing against the suggested names in this PR. They look like names I myself would have used. 😉

[dgdavid]

Something really easy to change, thought. Let's move the question for the final PR against master branch. Unless you feel it is better addressing it here instead.

Thinking it twice, let's do it now

Done! Check 5f353c1. As said, different format (adding the work connection, omitting the device, whatever) can be changed later by somebody.

[ancorgs]

Two weird things I found during manual testing regarding editing a connection:

• If one connection is created for "any" (unbound), then I go to "edit connection" and choose "by name", then the second select-box is initialized to an empty value (that is not actually among the options I can select if I open the select-box). Saving in that situation takes the connection back to unbound, which is not that bad.
• I was able to edit a WiFi connection and bind it to an ethernet (or even local loopback) device. I feel there should be some relationship between the type of connection and the devices I can choose. Especially because creating a WiFi connection is done in a different format in which I cannot select the bound device.

Maybe the second one is not that much related to this pull request, but about the nature of editing connections as a concept.

[dgdavid]

Two weird things I found during manual testing regarding editing a connection:

• If one connection is created for "any" (unbound), then I go to "edit connection" and choose "by name", then the second select-box is initialized to an empty value (that is not actually among the options I can select if I open the select-box). Saving in that situation takes the connection back to unbound, which is not that bad.
• I was able to edit a WiFi connection and bind it to an ethernet (or even local loopback) device. I feel there should be some relationship between the type of connection and the devices I can choose. Especially because creating a WiFi connection is done in a different format in which I cannot select the bound device.

Maybe the second one is not that much related to this pull request, but about the nature of editing connections as a concept.

Thanks a ton for such a testing. Both were overlooked by me.

The first one is quite weird, but I guess easy to fix.

The second one was totally out of the scope of this refactor because there would be a serie of follow-up PRs adding the ability of creating/editing different types of connections. While Wi-Fi can be already created because historical reasons, it deserves some love yet. In short, for a separated PR in the context of extending the network support.

[dgdavid]

Two weird things I found during manual testing regarding editing a connection:

• If one connection is created for "any" (unbound), then I go to "edit connection" and choose "by name", then the second select-box is initialized to an empty value (that is not actually among the options I can select if I open the select-box). Saving in that situation takes the connection back to unbound, which is not that bad.

Fixed with c5f398b

About dontUpdateMeta,

• docs: add guide about getting and setting field values TanStack/form#2104
• https://github.com/TanStack/form/blob/42761767cf0662559d4f2c1a51b45b3720dbd451/packages/form-core/src/FormApi.ts#L2300

[ancorgs]

LGTM