Meteor-Community-Packages / Meteor-Community-Packages/meteor-tabular
``count`` (bInfo: true) does NOT always show correct value
- Dominant language
- JavaScript
- Stars
- 360
- Forks
- 132
- PR merge metrics
- No merged PRs in 30d
Description
Hi guys,
I just ran into a problem with tabular SHOWING THE WRONG row-count when having `bInfo: true` in settings. P.e. the table itself shows 2 rows, BUT the info says "Showing 1 to 7 of 7 entries".
In my usecase I am reactively updating the table`s selector by the value entered in an input-filter-field. The problem occurs, when I first quickly enter a search-string into the input-field.
**Detailed Example:**
Lets say I have a text-field-input, which I listen to via an event. Within the event-listener I build a mongo-selector which is then passed to tabular, p.e `input .filter-input': function() { //.. build selector and set it reactively }`. When then entering some quick keys within the ui (p.e. "abcdefg"), it then happens (especially in the first run) that tabular uses the FIRST selector build (p.e. "_.a._") instead of the last selector ( "_.abcdefg._"). STRANGELY it uses this first selector for the row-rount, BUT the table itself shows the correct rows. P.e. the table shows 2 rows (for the correct selector "_.abcdefg._"), but the ROW-COUNT shows something like "Showing 1 to 7 of 7 entries" (because it is using the WRONG first selector "_.a._") for the count
This is really frustrating, especially when running acceptance tests against the ui and checking if the correct number of rows are being displayed.
Having a quick look at the code it might have to do with those lines
https://github.com/aldeed/meteor-tabular/blob/master/server/tabular.js#L169-L173
Anyone else having this issue? Have you found a fix?
Contributor guide
Research direction
Start at server/tabular.js lines 169-173 and reproduce the issue by rapidly changing the selector through successive input values. Compare the selector used for the row count with the selector used for the displayed rows, and consider the issue resolved when both consistently reflect the latest selector.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100