-
Notifications
You must be signed in to change notification settings - Fork 7
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
August 2024 UI and usability improvements #596
August 2024 UI and usability improvements #596
Conversation
@@ -185,6 +185,20 @@ export const locationTableCells = (): PropertyConfig[] => [ | |||
class: 'w-52', | |||
objectMapping: { text: 'LocationInfo.RegionInfo.Name.{language}' }, | |||
}, | |||
|
|||
// FIXME: ADD FOR TESTING 533 |
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.
@a-crea did you forget to remove the code you added for testing or shall we remove the comment // FIXME?
@MatteoBiasi @a-crea general remark for this PR: it is not up-to-date with the current |
I just noted that for this PR in TableView on mobile, the "Lines per page" - selectbox seems broken, see images below. Note that the visualization on desktop seems odd, to. Current development version (e.g. https://databrowser.opendatahub.testingmachine.eu/dataset/table/tourism/v1/Accommodation): |
In the TableView, the new header has lots of white spaces (#575 is about a compacter TableView) and the select-bi / buttons / search input have different heights (small issue). See image below. |
DetailView / EditView: opening the page of an additional property directly by inserting the URL into the browser opens the the page correctly, but the menu on the left is not updated correctly Example link: |
Strange things happen when the Toolbox in one of the Table/Detail/EditViews is open in desktop width (e.g. 1400px) and the browser window is resized to mobile widths (e.g. 600px): In that case, nothing is visible anymore, see images below. Note that this does not happen when the Toolbox is closed. Note that this does not happen in the current development version. |
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.
Lots of changes, lots of new stuff, some problems encountered ;) please fix
/> | ||
<OverviewTagAccess :dataset="dataset" /> | ||
<CardContainer no-padding> | ||
<CardLinkContainer :to="tableLocation as string"> |
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.
Casting tableLocation
to string seems wrong (casting in general is a code smell and should be avoided if possible), because the type of tableLocation
is DatasetLocationRoute, whose string representation is [object Object]
. I'm pretty sure that was not intended.
The only reason why this works is, because DatasetLocationRoute
and the to
property of router-link
used inside the CardLinkContainer
have some object properties in common.
Furthermore, the assignment creates lots of warnings in the console (see image below). Please fix this.
databrowser/package.json
Outdated
@@ -34,7 +34,8 @@ | |||
"vue-hotjar-next": "^1.4.0", |
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.
vue-hotjar-next was removed as of 4f0dd6e, please rebase this PR
databrowser/package.json
Outdated
@@ -34,7 +34,8 @@ | |||
"vue-hotjar-next": "^1.4.0", | |||
"vue-i18n": "^9.2.2", | |||
"vue-json-pretty": "^2.2.3", | |||
"vue-router": "^4.2.2" | |||
"vue-router": "^4.2.2", | |||
"vue3-cookies": "^1.0.6" |
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.
Please do not use cookies to store client-side data. Use localStorage / sessionStorage instead, like in the EditHint component.
|
||
<script setup lang="ts"> | ||
defineProps<{ | ||
to: string; |
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.
I'd use RouteLocationRaw
here as that is the type router-link
expects, see e.g. InternalLink component.
RouteLocationRaw
is a union type that also accepts strings. This makes the component more flexible in terms of the route locations it can handle.
:label-placeholder="t('components.inputSearch.labelPlaceholder')" | ||
label-button="Search" |
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.
The button text is already translated, I think hard-coding it here was maybe by mistake? ;)
category.subElements.map((item) => { | ||
const pathArray = R.split('.', item.objectPath); | ||
const existsProperty = R.path(pathArray, _data) !== undefined; | ||
|
||
return (item.elements.visible = existsProperty); | ||
}); |
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.
The usage of map
here is not advised, as you change the contents of category.subElements
inside the map function, thus provoking side effects that should never be part of a map function.
Please use either category.subElements.forEach
or iterate with a good old for
- loop.
@@ -22,8 +22,13 @@ export const computeTableCols = ( | |||
return []; | |||
} | |||
|
|||
return view.elements.map<Column>((element) => { | |||
const elements = useTableViewColsStore().showDeprecated |
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.
Please provide the value of useTableViewColsStore().showDeprecated
as property of the function computeTableCols
, instead of rereading it from the store.
That way, this function remains pure, which is something really nice to reason about.
actions: { | ||
setShowDeprecated(value: boolean) { | ||
this.showDeprecated = value; | ||
}, | ||
}, | ||
}); |
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.
This action is most probably not needed, see also comment on DatasetHeaderConfigPopup
component here: #596 (comment)
|
||
const preferredToolboxVisibility = !mdAndLarger.value | ||
? 'false' | ||
: cookies.get('isToolboxVisible'); |
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.
Use localStore instead of cookies for client-only data. See EditHint component as an example
export const toggleToolboxVisibility = (isVisible: boolean) => { | ||
const toolBoxStore = useToolBoxStore(); | ||
toolBoxStore.visible = isVisible; | ||
cookies.set('isToolboxVisible', String(isVisible)); | ||
}; | ||
|
||
export const toggleShowAll = (showAll: boolean) => { | ||
const toolBoxStore = useToolBoxStore(); | ||
toolBoxStore.settings.showAll = showAll; | ||
}; | ||
|
||
export const toggleShowDeprecated = (showDeprecated: boolean) => { | ||
const toolBoxStore = useToolBoxStore(); | ||
toolBoxStore.settings.showDeprecated = showDeprecated; | ||
}; | ||
|
||
export const toggleShowReferences = (showReferences: boolean) => { | ||
const toolBoxStore = useToolBoxStore(); | ||
toolBoxStore.settings.showReferences = showReferences; | ||
}; |
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.
Please put all of this stuff inside the store as actions. Here it is the right thing to do!
@MatteoBiasi @a-crea thanks for the fixes, should I do another code review? Another important thing about branch alignment: I saw that the current development branch and your PR branch august-2024-ui-and-usability-improvements divert after commit "This branch is 30 commits ahead of, 12 commits behind" This could be problematic for merging and tooling. I would be very grateful (and strongly recommend) if you could apply your changes on TOP of the current That way we avoid possible merge problems that go unnoticed. Otherwise there will be double (same) commits (see image below), maybe stuff that was changed and is overwritten by your changes and all kinds of other nasty things. You can take a look at the result if you try to do the merge locally. If you have any problems with rebase / merge or want to discuss this topic, just let me know 👍 |
@MatteoBiasi @a-crea @xleddyl guys, while i appreciate that you are ironing out this PR, I have some trouble with the way you provide your contributions. First, this PR becomes very big, touching a lot of stuff. While I myself sometimes go down the unhappy route of big PRs, it remains to say that they are usually problematic in terms of code and feature changes and especially for code review and testing. I thought we agreed to not create massive PRs if there are not very good reasons. Second, I'd like to ask you for the THIRD TIME to bring this PR up do date with the current Third, I see that you introduce / change project dependencies (previously it was a cookie library, now you update tailwind). While updating libraries is fine to some degree, if its not strictly necessary I'd ask you to not do that in such a massive PR. Finding the reason for bugs or degradations becomes hard when everything is mixed together - I know what I'm talking about from different perspectives. If you think you have to change dependencies, lets discuss it briefly. @sseppi: whats your take on this? |
@MatteoBiasi @gappc thank you for the contribution of both of you in trying to close this PR. In my point of view there is space for optimization, as always, but now we have to find the best and quickest way to fix and close this issue. Since is the release of the features included in this PR is quite urgent, what about organizing a pair programming session to review the code together and close the PR? @gappc is there a way to publish this PR in a dedicated staging environment, to share it with the customer care team and let them test and prepare the documentation we need for the clients? |
@sseppi @MatteoBiasi the branch in its current state cannot be build, at least in my environment I get 2 errors when I run The ouput is as follow:
As soon as the problems get fixed, I can deploy the PR onto a temporary location where you can check its current state. |
@gappc The issues with the build have been resolved. Regarding the cookie package, the problem hadn't actually resurfaced; the code had been corrected using localStorage, but the package was forgotten and not removed. I've now removed it. So, everything is fine on that front as well. |
@MatteoBiasi thx for the fixes, @sseppi you can find the deployed PR here: https://0.databrowser.gappc.net/ |
@MatteoBiasi please note that there seems to be a bug in the TableView filters, where the selectbox options don't show up. Maybe a problem of z-index (see image below). Example URL: https://0.databrowser.gappc.net/dataset/table/tourism/v1/Accommodation |
@gappc thank you for the link! I shared it with the customer care, to test and document the new features. |
I use this comment of the PR, to list all issues I found while I was testing. Please find the link in the list below:
@MatteoBiasi can you please have a look at it? |
@MatteoBiasi from mi side I did some testing yesterday and I inserted everything I found. Being the feature changes that big is difficult to be sure to have tested everything, but we need to go online till the end of the month. For that reason I would suggest to proceed fix everything we found and try to go online. |
@gappc I think the PR is ready to be reviewed |
@sseppi @MatteoBiasi I've reviewed the changes. Although there are some minor bugs / issues (see below), I believe the PR is ready to be merged.. I would greatly appreciate it if we could address the findings mentioned below, perhaps in a dedicated issue, to ensure they are not overlooked. Lowering the quality of the code will make it harder to maintain and extend the codebase in the future. I'm confident that these issues can be easily fixed, so please don't hesitate to ask me if you need any assistance. Bug / Issue listReferenced attributes not shown when toggle is disabledDetail view: referenced attributes are not shown when "Load referenced attributes" is disabled (see feedback from previous code review here) Text for toggle could be misunderstoodDetail view toolbox: the text for the toggle could be misunderstood: "Show attributes which are referenced from other datasets". I think it is the other way around, something like "Show attribute values that are referenced from this record / dataset / (some better naming?)" Search button on mobileOn mobile, the search button is still visible in detail / edit / raw view, but clicking on it has no useful effect. I understand that at the moment the search is not available in these views, but the button should be hidden in that case. Popover vs Tooltip componentPopover vs Tooltip component (see feedback from previous code review here). I think we should try to stick with Popover component for the reasons outlined in the feedback. Duplicate attributes shown in ToolboxDuplicate attributes shown in Toolbox under "Export datasets" in detail view (see image below) Additional left padding in table view filtersAdditional left padding in table view filters (see image below) Warnings in the consoleWarnings in the console when opening the detail view of a record (see image below), e.g. Inconsistent "Show deprecated fields" togglesIn detail / edit view, the "Show deprecated fields" toggles are not in sync (see image below). Invalid HTMLSelf-closing div is not valid HTML (see DatasetHeaderOverlay.vue) TypeScript issuesType castsDon't do explicit type casts if not strictly necessary. If a given type is Other problematic instances:
Usage of
|
@sseppi @mrabans @MatteoBiasi @a-crea @xleddyl @pkritzinger @Mazzolintis you can view the state of the current PR here: https://0.databrowser.gappc.net/ |
@MatteoBiasi how long will it take to fix the issuee mentioned in the yesterday's comment: #596 (comment) @gappc it seems that there is some SSL problem, the databrowser the link you shared doesn't load the datasets: |
@sseppi we estimate to fix them by Thursday |
@sseppi you wrote:
The error response comes from the ODH testing environment, e.g. https://api.tourism.testingmachine.eu/v1/MetaData?pagesize=1000 returns with a TLS error. The current databrowser test environment seems also not to work, see https://databrowser.opendatahub.testingmachine.eu/dataset-overview. @RudiThoeni any ideas what the problem could be? @ALL as I mentioned, in my opinion the PR can be merged in its current state, there are no blockers or major bugs remaining. I would just appreciate if the list of remaining minor bugs / issues is not lost, so we don't forget about them. Thanks all for your work and time 👍 |
@MatteoBiasi I will merge this PR, for the issues mentioned by @gappc please open another PR |
This PR includes the the following issues: