Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

web: Reuse devices #1165

Merged
merged 32 commits into from
May 3, 2024
Merged

Conversation

joseivanlopez
Copy link
Contributor

@joseivanlopez joseivanlopez commented Apr 24, 2024

Implement feature for reusing an existing device (i.e., allow formatting a block device or mounting a file system). Main changes:

  • Redesign the dialog for changing location:
    • Shows a table with all the devices that can be selected as location for the volumes.
    • Allows selecting how to allocate the file system at selected device (create partition, create dedicated LVM, format, mount).
  • Add a menu option in the table of volumes for resetting the location (i.e., to use the installation device instead of a custom location).

Note: We have detected some problems with the UI for changing location implemented in this PR:

  • The table is scrollable. If there are too many devices, then there is a chance of overlooking some devices if you don't realize about the scroll.
  • Having a table and group of radios at the end looks quite overwhelming. The very same information could be provided in a simpler way.
  • Ideally, this change location option should be integrated in the form of the volume.

Check some ideas in the thread of this PR and at #1176.

Toggle screenshots

localhost_8080_ (44)

localhost_8080_ (45)

@joseivanlopez joseivanlopez force-pushed the reuse-device branch 2 times, most recently from f19083c to c080dd8 Compare April 26, 2024 14:02
In a temporary wrong placement. Incoming commit will fix it by
refactoring the code for building the volume actions.
To make it a bit simpler and keep actions in the desired order.
Although these components are just convenient internal components of
VolumeRow, they can be defined outside of it for helping to reduce the
components redefinition each time the parent component gets rendered.
- Unify columns.
- Activate type checking.
- Refactoring code.
@coveralls
Copy link

coveralls commented Apr 30, 2024

Coverage Status

coverage: 75.032% (-0.01%) from 75.046%
when pulling ca7e244 on joseivanlopez:reuse-device
into a554ab0 on openSUSE:master.

joseivanlopez and others added 10 commits April 30, 2024 13:29
- Volumes were using the human string of the file system type, but the
  devices were using a different represetation for the file system type.
- Documentation
- Types
To be precise, changes try to force the content to fit in the available
space by adding scroll to the devices table if needed in an attempt to
keep allocation options always visible.

This is temporary and should be changed/improved.
To create more difference between them and the radio descriptions. As
previous changes, this aims to be a temporary solution and should be
re-evaluated.
 * Hide the expand button
 * Indent children devices
joseivanlopez and others added 4 commits May 2, 2024 16:26
@dgdavid
Copy link
Contributor

dgdavid commented May 2, 2024

@ancorgs, @joseivanlopez

I've sent the latest changes we were talking about this afternoon, please check e2ae65d and screenshots below.

Table not scrolled Table scrolled
Screenshot from 2024-05-02 17-54-12 Screenshot from 2024-05-02 17-54-17

Although making it work was a bit more difficult than I though, I think it is enough for mitigating the inherited problems from an scrollable HTML node in the middle of the UI because the browsers hiding the scroll bars.

However, I still thinking we have chosen the wrong layout here. If I'm able to find time, I will try to come up with an example with a different one to see if I'm right and, if so, I'm able to convince you about it.

In any case, let's considered this scrollbox thingy implementation as temporary workaround that must be improved if finally it stays.

@dgdavid
Copy link
Contributor

dgdavid commented May 2, 2024

Although making it work was a bit more difficult than I though

BTW, while scrolling you will see how these chips in the "Usage" column overlaps the scroll shadow. I'm sorry but at this time I do not know how to fix it. I was playing with the z-index property without success. I'll try it again early in the morning, with a fresh mind :)

@dgdavid
Copy link
Contributor

dgdavid commented May 2, 2024

I will try to come up with an example

Here you have a rough test. Of course, need refinements (as use just one column in very small devices), but I hope it can be used for evaluation.

Click to show/hide screenshots

Kind of medium resolution

Screenshot from 2024-05-02 19-37-23
Screenshot from 2024-05-02 19-37-26
Screenshot from 2024-05-02 19-37-18

Bigger resolution

Screenshot from 2024-05-02 19-37-42

Changes can be found at ca0ad81

I might be completely wrong but at this time I'm convinced that it provides a more guided, clear, and less prone to surprises experience.

@dgdavid
Copy link
Contributor

dgdavid commented May 2, 2024

I will try to come up with an example

Here you have a rough test. Of course, need refinements (as use just one column in very small devices), but I hope it can be used for evaluation.

...

Let's continue feeding thoughts.

How could fit the use of a select instead of a collection of radios?

Click to show/hide screenshots

Screenshot from 2024-05-02 22-15-20
Screenshot from 2024-05-02 22-15-25
Screenshot from 2024-05-02 22-15-35

Draft code available at dd3c5fe

PS: note that selector already comes with keyboard support.

@dgdavid
Copy link
Contributor

dgdavid commented May 2, 2024

Let's continue feeding thoughts.

How could fit the use of a select instead of a collection of radios?
...

And now stop using the table for selecting devices and goes for a select too...

Click to show/hide screenshots

Screenshot from 2024-05-02 23-09-14

But with better format for the disk content information (it was just stolen from the table for the test). See 09ad6b4

I'm going to stop here, but please take your time for thinking about this before outright rejecting any of the proposals (for future iterations, sure). Specially, try to imagine the last one with better styles and horizontal alignment

A good label

| Format ....  ⌄ |           | /dev/vdc1....  ⌄ |

Apart from a good, simple, keyboard navigation... it could be easily integrated in the VolumeDialog as yet another field.

Also, the device selector could use the https://www.patternfly.org/components/menus/select#typeahead feature.

Disclaimer: I'm not saying to go for it. Just to, at least, arrange time for evaluating it. Maybe we don't need tables everywhere.

@ancorgs
Copy link
Contributor

ancorgs commented May 2, 2024

Talking about ideas... #1176

@joseivanlopez joseivanlopez marked this pull request as ready for review May 3, 2024 08:47
@ancorgs
Copy link
Contributor

ancorgs commented May 3, 2024

Some notes about review.

We agreed we want to merge the UI implemented in this pull request... just as a first approach with close expiration date. We need to merge it in order to proceed with other important tasks.

The idea is to substitute this with an UI based on drop-downs (as sketched in a previous comment by @dgdavid). I would suggest to start with that next week.

I tested this pull request and works as expected. So from a functional POV, it LGTM.

But code-wise I would prefer @dgdavid to review it (taking into account some parts would be short-lived, as explained above).

Copy link
Contributor

@dgdavid dgdavid left a comment

Choose a reason for hiding this comment

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

LGTM, what a big and nice job. Thank you.

Please, do not take into consideration my NP comments. Think on them as just reminders for myself to discuss a few things in a near future.

From my side, you can go ahead with the merge 💪

web/src/client/storage.js Outdated Show resolved Hide resolved

/** @type {(device: StorageDevice) => boolean} */
const isAvailable = (device) => {
const isChildren = (device, parentDevice) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

NP: If I'm not wrong, we already have a isChildren function somewhere. Anyway, this kind of functions looks like a potential util that should live elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, there is a #deviceChildren function to generate the list of children. In this case the function checks if it is a children of a device. Anyway, I think we need to improve this part, see https://github.com/openSUSE/agama/pull/1165/files#diff-8cfada04978222410b4703fc1ca52a1ff139c6497329b3ca2e4e176ba5d14d00R26.

* @param {string[]} [props.initialExpandedKeys=[]] - Ids of initially expanded items.
* @param {(selection: Array<object>) => void} [props.onSelectionChange=noop] - Callback to be triggered when selection changes.
* @param {object} [props.tableProps] - Props for {@link https://www.patternfly.org/components/table/#table PF/Table}.
* @typedef {object} ExpandableSelectorBaseProps
Copy link
Contributor

Choose a reason for hiding this comment

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

NP: Just a note not related with this PR. We are following this pattern of defining ComponentBaseProp and for now it is ok. But I wonder if, since it is something internal, we could call them just BaseProp instead. I see two problems, however:

import { ExpandableSelector } from "~/components/core";

/**
* @typedef {import("../core/ExpandableSelector").ExpandableSelectorColumn} ExpandableSelectorColumn
Copy link
Contributor

Choose a reason for hiding this comment

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

NP: Did ~/components/core/ExpandableSelector not work? Or maybe did you though it is too long? By the way, maybe ExpandableSelectorColumn can be names just Column in core/ExpandableSelector.jsx You have to rename it anyway when importing it.

 * @typedef {import("~/components/core/ExpandableSelector").Column} ExpandableSelectorColumn

Again, not related with this PR but this kind of things makes me tend to think that we are actually running away of TypeScript with no strong reason.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! The path was automatically added by my editor :).

@joseivanlopez joseivanlopez merged commit aa89adb into agama-project:master May 3, 2024
4 checks passed
@imobachgs imobachgs mentioned this pull request May 17, 2024
imobachgs added a commit that referenced this pull request May 17, 2024
Prepare for releasing Agama 8. It includes the following pull requests:

* #884
* #886
* #914
* #918
* #956
* #957
* #958
* #959
* #960
* #961
* #962
* #963
* #964
* #965
* #966
* #969
* #970
* #976
* #977
* #978
* #979
* #980
* #981
* #983
* #984
* #985
* #986
* #988
* #991
* #992
* #995
* #996
* #997
* #999
* #1003
* #1004
* #1006
* #1007
* #1008
* #1009
* #1010
* #1011
* #1012
* #1014
* #1015
* #1016
* #1017
* #1020
* #1022
* #1023
* #1024
* #1025
* #1027
* #1028
* #1029
* #1030
* #1031
* #1032
* #1033
* #1034
* #1035
* #1036
* #1038
* #1039
* #1041
* #1042
* #1043
* #1045
* #1046
* #1047
* #1048
* #1052
* #1054
* #1056
* #1057
* #1060
* #1061
* #1062
* #1063
* #1064
* #1066
* #1067
* #1068
* #1069
* #1071
* #1072
* #1073
* #1074
* #1075
* #1079
* #1080
* #1081
* #1082
* #1085
* #1086
* #1087
* #1088
* #1089
* #1090
* #1091
* #1092
* #1093
* #1094
* #1095
* #1096
* #1097
* #1098
* #1099
* #1100
* #1102
* #1103
* #1104
* #1105
* #1106
* #1109
* #1110
* #1111
* #1112
* #1114
* #1116
* #1117
* #1118
* #1119
* #1120
* #1121
* #1122
* #1123
* #1125
* #1126
* #1127
* #1128
* #1129
* #1130
* #1131
* #1132
* #1133
* #1134
* #1135
* #1136
* #1138
* #1139
* #1140
* #1141
* #1142
* #1143
* #1144
* #1145
* #1146
* #1147
* #1148
* #1149
* #1151
* #1152
* #1153
* #1154
* #1155
* #1156
* #1157
* #1158
* #1160
* #1161
* #1162
* #1163
* #1164
* #1165
* #1166
* #1167
* #1168
* #1169
* #1170
* #1171
* #1172
* #1173
* #1174
* #1175
* #1177
* #1178
* #1180
* #1181
* #1182
* #1183
* #1184
* #1185
* #1187
* #1188
* #1189
* #1190
* #1191
* #1192
* #1193
* #1194
* #1195
* #1196
* #1198
* #1199
* #1200
* #1201
* #1203
* #1204
* #1205
* #1206
* #1207
* #1208
* #1209
* #1210
* #1211
* #1212
* #1213
* #1214
* #1215
* #1216
* #1217
* #1219
* #1220
* #1221
* #1222
* #1223
* #1224
* #1225
* #1226
* #1227
* #1229
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.

4 participants