-
Notifications
You must be signed in to change notification settings - Fork 43
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
web: Reuse devices #1165
Conversation
f19083c
to
c080dd8
Compare
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.
c080dd8
to
5420b85
Compare
- Unify columns. - Activate type checking. - Refactoring code.
5420b85
to
dc24960
Compare
aa8e87c
to
7fb343b
Compare
- 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
Relying in the Lea Verou technique described at https://lea.verou.me/blog/2012/04/background-attachment-local. It makes the scrollable table a bit more evident, but still feeling as a workaround.
I've sent the latest changes we were talking about this afternoon, please check e2ae65d and screenshots below.
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. |
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 |
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. 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. |
Let's continue feeding thoughts. How could fit the use of a select instead of a collection of radios? Draft code available at dd3c5fe PS: note that selector already comes with keyboard support. |
And now stop using the table for selecting devices and goes for a select too... 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
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. |
Talking about ideas... #1176 |
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). |
There was a problem hiding this 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 💪
|
||
/** @type {(device: StorageDevice) => boolean} */ | ||
const isAvailable = (device) => { | ||
const isChildren = (device, parentDevice) => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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:
- When a single file can end up with more than one BaseProp. Weird.
@typedef
auto exports types defined at top level, https://alexharri.com/blog/jsdoc-as-an-alternative-typescript-syntax#exporting-types
import { ExpandableSelector } from "~/components/core"; | ||
|
||
/** | ||
* @typedef {import("../core/ExpandableSelector").ExpandableSelectorColumn} ExpandableSelectorColumn |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :).
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
Implement feature for reusing an existing device (i.e., allow formatting a block device or mounting a file system). Main changes:
Note: We have detected some problems with the UI for changing location implemented in this PR:
Check some ideas in the thread of this PR and at #1176.
Toggle screenshots