-
-
Notifications
You must be signed in to change notification settings - Fork 392
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
OBPIH-4923 Fix URL redirects with filters in params #3538
OBPIH-4923 Fix URL redirects with filters in params #3538
Conversation
} | ||
return true; | ||
}); | ||
return !!foundURL; |
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 needed to refactor this method because it match URLs with path that had search parameters in different order.
The problem that I noticed was with INBOUND/OUTBOUND stock movement
In example in config for menuUrls
we have an object where key is the name of the section and value is the array of urls that the section contains.
For Inbound section we have a url for inbound list of /openboxes/stockMovements/lis?direction=INBOUND
.
In the old method it would select it as active it the current URL was exactly the same as specified in the array, so for example such a URL /openboxes/stockMovements/lis?status=PENDING&direction=INBOUND
. would not be matched.
In my implementation of this active section checked I check if section has search params we make sure that current URL has all required params and if it does we return it as matched URL.
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.
yeah, checking active section was supposed to work for those 95% of cases back then not to spend too much time on it back then as it was not a priority, but the refactor must've happened some day. Good job
@@ -60,8 +61,12 @@ const StockMovementOutboundList = (props) => { | |||
const queryProps = queryString.parse(props.history.location.search); | |||
// IF VALUE IS IN A SEARCH QUERY SET DEFAULT VALUES | |||
if (queryProps.requisitionStatusCode) { | |||
defaultValues.requisitionStatusCode = props.requisitionStatuses | |||
.filter(({ value }) => queryProps.requisitionStatusCode.includes(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 is a refactor that I had to implement in many places of the new List Table pages.
The problem was the used include(...)
method.
Unfortunately I did not consider this before but this method does not return a exact match but as it implies it returns true if item is included in a value.
basicaly if we have a list ['PARTIALLY_RECEIVED', 'PENDING'].includes('RECEIVED')
it would return true
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.
here I agree that includes
is not the same as find
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 jumped to conclusions too fast, .include(...)
works perfectly fine for this case.
The problem was in the props all along (that when a single prop was received where an array is expected it searched the single prop string instead of array of a single element)
@@ -57,7 +57,7 @@ const FilterForm = ({ | |||
} | |||
const clearedFilterList = Object.keys(defaultValues) | |||
.reduce((acc, key) => { | |||
if (ignoreClearFilters.includes(key)) { | |||
if (ignoreClearFilters.find(filter => filter === key)) { |
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.
doesn't includes
work in the same way here like find
? Both of them would return true
in this if
, wouldn't they?
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 it does.
I jump to conclusions too fast
} | ||
return true; | ||
}); | ||
return !!foundURL; |
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.
yeah, checking active section was supposed to work for those 95% of cases back then not to spend too much time on it back then as it was not a priority, but the refactor must've happened some day. Good job
: [queryProps.catalogId]; | ||
defaultValues.catalogId = catalogList | ||
.filter(({ id }) => catalogIdList.includes(id)) | ||
const catalogIdList = getList(queryProps.catalogId).map(it => ({ id: it })); |
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.
isn't it a bit "overthought"? queryProps.catalogId
should be an Array, so what is that getList
function responsible here for? Wouldn't simple queryProps.catalogId ?? []
work here?
I actually think that this map is useless. Check below
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 is not entirely true that queryProps.catalogId
is always an array.
The problem with query params is that in a URL such as /openboxes/products?catalogId=1
it does not return an array but a single value and URL /openboxes/products?catalogId=1&catalogId=2
does return an array.
So the goal of this utils method getList
is to awlays return an array no matter how many values are in the param.
I've been inspired to do this by a similar case that we have on backend
def statuses = params?.list("receiptStatusCode")
where params.list(...)
does exactly that.
defaultValues.catalogId = catalogList | ||
.filter(({ id }) => catalogIdList.includes(id)) | ||
const catalogIdList = getList(queryProps.catalogId).map(it => ({ id: it })); | ||
defaultValues.catalogId = _.intersectionBy(catalogList, catalogIdList, 'id') | ||
.map(({ id, label }) => ({ | ||
id, label, name: label, value: id, | ||
})); |
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.
and this .map
should be useless, as
catalogList.filter(catalog => catalogIdList.some(id => id === catalog.id))
this would return filtered catalogList
which already has id, name, 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 map is not useless because endpoint for catalog list return an array of [ { id: '...', label: '...' } ]
same for tags and categories
defaultValues.catalogId = catalogList | ||
.filter(({ id }) => catalogIdList.includes(id)) | ||
const catalogIdList = getList(queryProps.catalogId).map(it => ({ id: it })); | ||
defaultValues.catalogId = _.intersectionBy(catalogList, catalogIdList, 'id') |
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.
catalogList.filter(catalog => catalogIdList.some(id => id === catalog.id))
@@ -60,8 +61,12 @@ const StockMovementOutboundList = (props) => { | |||
const queryProps = queryString.parse(props.history.location.search); | |||
// IF VALUE IS IN A SEARCH QUERY SET DEFAULT VALUES | |||
if (queryProps.requisitionStatusCode) { | |||
defaultValues.requisitionStatusCode = props.requisitionStatuses | |||
.filter(({ value }) => queryProps.requisitionStatusCode.includes(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.
here I agree that includes
is not the same as find
dd09e02
to
f8eff8c
Compare
No description provided.