OBPIH-7541 Create UI for new reorder report#5571
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5571 +/- ##
============================================
- Coverage 9.12% 8.50% -0.62%
+ Complexity 1170 1113 -57
============================================
Files 701 707 +6
Lines 45281 45452 +171
Branches 10851 10886 +35
============================================
- Hits 4131 3867 -264
- Misses 40497 41011 +514
+ Partials 653 574 -79 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| columns, | ||
| tableData, | ||
| loading, | ||
| emptyTableMessage, |
There was a problem hiding this comment.
Why did you remove emptyTableMessage here but not also in useProductsTab? If we really want to remove it I think we should also remove it from useProductsTab 🤔
There was a problem hiding this comment.
I will ask differently - why was this file even touched? Were you just testing something for the table and forgot to bring back or?
There was a problem hiding this comment.
uh, I did it by mistake 😢
| react.report.reorder.category.label=Category | ||
| react.report.reorder.tags.label=Tags | ||
| react.report.reorder.loadTable.label=Load table |
There was a problem hiding this comment.
From what I see, we declare the same things a few times for example "Tags" (react.productsList.filters.tags.label, react.cycleCount.filter.tags.label, and now react.report.reorder.tags.label). Maybe we should create a common key for example react.default.filters.tags. Right now, while working on my current ticket, I’m facing the same issue where I have to write the same translations multiple times for different things. What do you think @alannadolny @kchelstowski
There was a problem hiding this comment.
@SebastianLib this is a larger conversation and refactor. I think the current reason for doing it this way is not to have to eventually pull translations for another feature (e.g. if we were to use the productLists.filters.tags, we'd have to inject the whole productList.* list of translations.
| onSubmit={updateFilterParams} | ||
| onSubmit={(values) => { | ||
| updateFilterParams(values); | ||
| onSubmit(values); |
There was a problem hiding this comment.
not a big deal, but wouldn't it actually be cleaner if we had the onSubmit null by default and here say:
if (onSubmit) {
...
}By just looking at this part it feels like it's always triggered (I know it's an empty function), so my suggestion would be to make an explicit if, but I leave it up to you
| columns, | ||
| tableData, | ||
| loading, | ||
| emptyTableMessage, |
There was a problem hiding this comment.
I will ask differently - why was this file even touched? Were you just testing something for the table and forgot to bring back or?
| import 'components/cycleCount/cycleCount.scss'; | ||
|
|
||
| const ReorderReport = () => { | ||
| useTranslation('report'); |
There was a problem hiding this comment.
@SebastianLib this is the reason we wouldn't want to use productList's label, because we'd have to fetch all of them here.
I agree with you in general and we have plans to somehow standardize that, but it's a larger topic.
| @@ -0,0 +1,86 @@ | |||
| import FilterSelectField from 'components/form-elements/FilterSelectField'; | |||
| import { | |||
| getExpiredStockOptions, getFilterProductOptions, | |||
There was a problem hiding this comment.
doesn't eslint shout about those two being in one line?
There was a problem hiding this comment.
No, it doesn't shout, so I often forget about splitting those into separate lines
| showFilterVisibilityToggler={false} | ||
| showSearchField={false} | ||
| allowEmptySubmit | ||
| customSubmitButtonDefaultLabel="Load table" |
There was a problem hiding this comment.
should this be called like that if we don't have the table at the moment? I believe this should be rather Download report?
There was a problem hiding this comment.
Yeah, this is how it was requested in the ticket
src/js/consts/filterOptions.js
Outdated
| @@ -0,0 +1,102 @@ | |||
| import translate from 'utils/Translate'; | |||
|
|
|||
| export const OPTION_ID = { | |||
There was a problem hiding this comment.
I think for clarity it's better to separate the enums here and have ExpirationFilter and InventoryLevelStatus like on backend.
| @@ -0,0 +1,102 @@ | |||
| import translate from 'utils/Translate'; | |||
There was a problem hiding this comment.
actually it's the first time I see such import. What method is triggered then? Isn't it actually a JSX Translate element that is returned? I'm wondering why we use useTranslate in a few places and in few places we import translate like that. I know it's a simple JS file so we can't use useTranslate, but if this works, what you have just done, why would we even need the useTranslate hook 🤔
Not something to fix, just curiosity if you already know the answer
There was a problem hiding this comment.
So the translation is the TranslateWrapper function (or call it a component) that returns . It gets translated because it is in the translation context. The translate returns HTML, and it is successfully mapped to options in the select. So here is the difference between that and the useTranslate, one of them returns HTML, while the second returns a plain, translated text.
| tags: selectedTags, | ||
| } = queryProps; | ||
|
|
||
| // If there are no values for catalogs, tags, glAccounts, categories or product family |
| && !selectedFilterProducts | ||
| && !expiredStock | ||
| && !additionalInventoryLocations) { | ||
| setDefaultFilterValues(defaultValues); |
There was a problem hiding this comment.
shouldn't we return at this point?
| return response.data.data; | ||
| }; | ||
|
|
||
| export const fetchLocations = async ({ activityCodes }) => { |
There was a problem hiding this comment.
how did it end up? Was it finally be supposed to be a debounced fetch or not?
There was a problem hiding this comment.
No, it doesn't need to be debounced
173a778 to
87906fb
Compare
87906fb to
d05fc15
Compare
# Conflicts: # grails-app/i18n/messages.properties
No description provided.