Closed ccsmart closed 6 years ago
OK I see the problem ...
the filter memory is part of the url, see the links (when clicked from the filter)
http://localhost:3000/_lang/en/filter/_count/10/_from/1/_to/10/_q/%7B%22years%22%3A[%222016%22]%2C%22langs%22%3A[%22fra%22]%2C%22countries%22%3A[%22bf%22]%7D
http://localhost:3000/_lang/en/filter/_count/10/_from/1/_to/10/_q/%7B%22years%22%3A[%222016%22]%2C%22langs%22%3A[]%2C%22countries%22%3A[%22bf%22]%7D
http://localhost:3000/_lang/en/filter/_count/10/_from/1/_to/10/_q/%7B%22years%22%3A[%222016%22]%2C%22langs%22%3A[]%2C%22countries%22%3A[]%7D
when clicked from the document links, the URL construction is wrong:
http://localhost:3000/_lang/en/filter/_count/10/_from/1/_to/10/_q/%7B%22years%22%3A[%222011%22]%2C%22langs%22%3A[%22eng%22]%7D
http://localhost:3000/_lang/en/filter/_count/10/_from/1/_to/10/_q/%7B%22years%22%3A[%222011%22]%7D
See http://youtu.be/gmSy2LQ8to4?hd=1 at 00:13
Clicking and filtering via the filter still works fine : http://youtu.be/6H5t85GR9ug?hd=1
The expected order of the filter construction in the URL is :
keywords, years, countries, langs
https://dev.gawati.org/_lang/ik/filter/_count/10/_from/1/_to/10/_q/%7B%22keywords%22%3A[%22Council%22]%2C%22years%22%3A[%222014%22]%2C%22countries%22%3A[%22ng%22]%2C%22langs%22%3A[%22eng%22]%7D
@surajpt its not the order that matters, its something else in the logical construction of the url in ExprAbstract .. I noticed some weird code:
https://github.com/gawati/gawati-portal-ui/blob/478565ecdc754c785c0978c2f4ebafe7f91b8df2/src/containers/ExprAbstract.js#L104 e.g. the 3 variables are exactly identical .. why have 3 at all ?
var Yquery = this.props.match === undefined || this.props.match.params.q===undefined ? {} : JSON.parse(decodeURIComponent(this.props.match.params.q));
var Lquery = this.props.match === undefined || this.props.match.params.q===undefined ? {} : JSON.parse(decodeURIComponent(this.props.match.params.q));
var Cquery = this.props.match === undefined || this.props.match.params.q===undefined ? {} : JSON.parse(decodeURIComponent(this.props.match.params.q));
Should probably change setInRoute(Filter2.js) to editInRoute. Need to make a few changes to get it working.
@Arunadevi @surajpt The problem actually seems to be in Filter2.js ; the filter params are captured in state there, while the URL params are out of sync with that. Perhaps we need to remove state from Filter2 and rely solely on the url params query.
@Arunadevi @surajpt have made these changes , just simplifying some of the code related to issue #51 (have not fixed the problem though) , see https://github.com/gawati/gawati-portal-ui/commit/0d8e9e09dfb3fb8efd0fb9b15cc5c5f88194e69d
@Arunadevi @surajpt OK Fixed on https://github.com/gawati/gawati-portal-ui/commit/2ce95e2967b6eabad3298de1273d987fabe4f366
seems fixed
After adding filter components incrementally from document properties, deselecting one in the custom filter tab removes all. As this works different when adding from fitler tab to begin with, this suggests different methods of tracking status. If true, these should probably be unified.