Skip to content

Add support for configuring WiFi devices#292

Merged
dgdavid merged 81 commits intomasterfrom
feature/wireless-support
Nov 17, 2022
Merged

Add support for configuring WiFi devices#292
dgdavid merged 81 commits intomasterfrom
feature/wireless-support

Conversation

@teclator
Copy link
Contributor

@teclator teclator commented Nov 3, 2022

Problem

In #260 we added basic support for configuring the network, the idea is to extend it supporting also wireless devices.

Solution

We have added support for configuring WiFi networks at least allowing the user to connect to a network without security or using WPA-PSK authentication as well as configuring a Hidden network.

Testing

  • Added some unit tests (but it is still not well covered).
  • Tested manually

Screenshots

Click to show/hide some screenshots
Network summary with Wi-Fi capabilities Available networks Connecting to a network
Installation summary holding a network section with Wi-Fi capabilities Available Wi-Fi networks for connecting to Connecting to a Wi-Fi network
Form for setting a connection Form for setting a hidden connection Detecting errors BEFORE trying to connect
Form for setting a new Wi-Fi connection Form for setting a hidden connection Detecting errors BEFORE trying to connect

@teclator teclator changed the title Feature/wireless support Add support for configuring WiFi devices Nov 3, 2022
@coveralls
Copy link

coveralls commented Nov 3, 2022

Coverage Status

Coverage decreased (-0.2%) to 74.68% when pulling 9c7715f on feature/wireless-support into bca356b on master.

@teclator teclator force-pushed the feature/wireless-support branch from f443dc3 to 95e655e Compare November 7, 2022 09:05
It will encapsulate needed logic to create a connection object from
given data before call to #addConnection method.

Co-Authored-By: Knut Anderssen <kanderssen@suse.com>
@teclator teclator force-pushed the feature/wireless-support branch from e492b22 to 181adbc Compare November 16, 2022 13:16
import { Dropdown, DropdownToggle } from "@patternfly/react-core";
import { EOS_MORE_VERT as MenuIcon } from "eos-icons-react";

export default function KebabMenu({ items, position = "right", id = Date.now(), ...props }) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it might happen that you get the same id twice, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it could happen. However, it's difficult. Anyway, ideally the consumer will provide a better id, this is just the default/fallback value. I could change it for something like parseInt(Date.now() * Math.random()) if you think it worth it.


const security_options = [
{ value: "", label: "None" },
{ value: "wpa-psk", label: "WPA & WPA2 Personal" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should rely on SecurityProtocols. We do not need to fix it know, but we should review it along with other enums. Especially when translations come into play.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case we missed a class enum for adding things like the label for example.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's true. My point is that using a "wpa-psk" looks fragile. But let's address it later.


const securityFrom = (supported) => {
if (supported.includes("WPA2"))
return "wpa-psk";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above: we are using an ad-hoc string when we already have an enum for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above and it also shows that is very related to the adapter... so maybe it should be declared there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure it should not be declared here :-) but as said before, we can live with this.

};

const renderFilteredNetworks = (networks) => {
return networks.map(n => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, use a meaningful name. For a small function, is perfectly fine, but this one has around 60 lines :-)


return (
<Popup isOpen={isOpen} height="large" title="Connect to a Wi-Fi network">
{ renderFilteredNetworks(networksFromValues(networks)) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use a proper component? OK, I know, components are functions, but I would expect to have something like Networks and HiddenNetworkForm. Do you need to share all that state between them?

In any case, about the renderFilteredNetworks, does that function do any filtering? If that's not the case, I do not think you need to mention that in the name. It isn't very clear.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imo, you're right.

Somehow, we forget to extract this to small components after so many changes to get the Wi-Fi selector working. I have tried to improve the situation a bit, but I fear a better improvement/re-organization must wait until next iterations in the network area.

What is more, I'd like to create a custom SelectionList component (Wi-Fi and Product selector are quite similar, though) and reorganize not only that part, but the whole src/ directory.

Hope, however, it looks good/acceptable enough for now.

// Do not include networks without SSID
if (!ap.ssid || ap.ssid === "") return networks;
// Do not include "duplicates"
if (knownSsids.includes(ap.ssid)) return networks;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about filtering networks you cannot configure? For instance, we cannot set up a WEP network, right? Alternatively, we could show them, but we should not allow trying to connect.

@teclator teclator force-pushed the feature/wireless-support branch from bf1fc5a to 4119dbe Compare November 16, 2022 14:09
@teclator teclator force-pushed the feature/wireless-support branch from 4119dbe to b89c9a7 Compare November 16, 2022 14:14
Copy link
Contributor

@imobachgs imobachgs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks much better now. Just a few suggestions, but feel free to ignore them.

Copy link
Contributor

@imobachgs imobachgs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reviewed the tests more closely and found out that they use async too much. Additionally, if you do not need to access the useInstallerClient hook, you can use plainRender instead.

@dgdavid dgdavid merged commit b044a44 into master Nov 17, 2022
@dgdavid dgdavid deleted the feature/wireless-support branch November 17, 2022 13:58
@imobachgs imobachgs restored the feature/wireless-support branch November 23, 2022 09:04
@imobachgs imobachgs deleted the feature/wireless-support branch November 23, 2022 09:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support for configuring WiFi devices

4 participants