OBPIH-6014 Product Sources list filters#4439
OBPIH-6014 Product Sources list filters#4439kchelstowski merged 17 commits intofeature/product-supplier-list-redesignfrom
Conversation
kchelstowski
requested review from
alannadolny,
awalkowiak,
drodzewicz and
jmiranda
… from the generic api
…the filter params
| ...sortingParams, | ||
| ...filterParams, |
There was a problem hiding this comment.
probably it's based on my preferences, but I prefer spreading parameters at the end of the object (do not treat this as a change request)
There was a problem hiding this comment.
if I had done it this way, it would eventually override the product and the supplier properties.
There was a problem hiding this comment.
For my whole life, I was sure that this thirdObj should return "thirdObj". I was sure that the parameters from spreading were always overridden by those typed "directly" 🤡🤡
| import { useDispatch } from 'react-redux'; | ||
| import { useHistory } from 'react-router-dom'; | ||
|
|
||
| const useCommonFilters = () => { |
There was a problem hiding this comment.
What is the purpose of this hook? I am unsure if this hook reduces the amount of code in other components because you have to destructure the returned object, so it's also a lot of code. Basically, this hook doesn't contain any logic, just other hooks.
There was a problem hiding this comment.
I realized that on all of the list pages, the code that is inside this hook is redundant. Starting from now, we could reuse this hook for the future list pages (and refactor the existing ones) instead of copying and pasting those useStates etc. that are there.
| import PropTypes from 'prop-types'; | ||
|
|
||
| const ListFilterFormWrapper = ({ children }) => ( | ||
| <div className="d-flex flex-column list-page-filters"> |
There was a problem hiding this comment.
I was thinking for a while about those wrappers that you created. In the beginning, I loved the idea, but now I am a little bit confused about whether "common styles" should be created using wrappers. I think each of those list pages, filters, etc. should have the same className, and we should have those styles in something like a "common" or "global" scss file.
There was a problem hiding this comment.
The purpose of the wrappers were to reduce the redundancy of the code for an eventual future refactor. If we ever decided to add/remove/rename a className of those divs, we'd have to do it only in a wrapper, not in every *List.jsx file.
There was a problem hiding this comment.
Another way to achieve the same result would be to store the classNames in a const. I went this way hoping you all would like the idea.
…efault preference types (Multiple, None)
kchelstowski
force-pushed
the
OBPIH-6014
branch
from
cfd0d26 to
23fc264
Compare
| id: ProductSupplierService.PREFERENCE_TYPE_NONE, | ||
| label: g.message(code: 'react.productSupplier.preferenceType.none.label', default: "None") | ||
| ], | ||
| ] |
There was a problem hiding this comment.
I decided to add the default options here, not on the frontend side, to avoid potential problems with translations that we've had for statuses options once (it was due to the fact that the labels had been rendered before the translation plugin or the redux's current locale was injected).
cc @jmiranda
* OBPIH-6014 Add filter fields for product sources list filters * OBPIH-6014 Add util method to clear query params * OBPIH-6014 Add components for product sources list filters * OBPIH-6014 Add methods and services to fetch product and organization from the generic api * OBPIH-6014 Adjust the hook for product supplier list data to include the filter params * OBPIH-6014 Add hooks for product sources list filters logic * OBPIH-6014 Add methods with service calls for fetching the product and organization * OBPIH-6014 Add sorting by the source name for the product sources list * OBPIH-6014 Add translations for product sources list filters * OBPIH-6014 Remove unnecessary spread operator before omitBy method * OBPIH-6014 Add productSupplier reducer to store the preferenceTypes * OBPIH-6014 Enable the preferenceType select for the product sources filters * OBPIH-6014 Add method to fetch the preferenceType options * OBPIH-6014 Fetch preference types and include it in product sources filters logic * OBPIH-6014 Refactor preference type options endpoint to include the default preference types (Multiple, None) * OBPIH-6014 Add default translation for the default preference type options
2 participants
Added TODOs to eventually replace the organization and product fetch by a call to the proper APIs instead of the generic one when you are back and we agree on an approach.
For now I used the generic api even though I hate it and I believe you also do, but in order for the list to work, it seems to be enough for a while.