-
Notifications
You must be signed in to change notification settings - Fork 754
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
Group: remove unnecessary complexity for further refactorings #830
Conversation
ebe979f
to
51eebc2
Compare
Made one more fix: if (num > 1 && txt !== '') {
//...
} else {
word = (txt + '').match(/\d+/g);
return word && word.length >= num ? word[num - 1] : txt || '';
} is always performed with If planned functionality (obtain n-th number from a string) is useful, it possibly should be made with another grouper. |
51eebc2
to
fbc58ac
Compare
Hi @prijutme4ty! To be honest, I haven't looked at the grouping code in a while, so I'd have to dig a bit more to figure out why some things were done a particular way.
If you have the motivation, some unit tests would be nice, but since there aren't any in place, I won't force you... the demo looks like it is working fine. I'll have to test it with the pager when I get more free time. In the mean time, go ahead and push these changes to master - I added you as a collaborator. For big stuff like your last pull request on the main plugin, I would appreciate making those changes in a branch so I can look over it. Also, please go ahead and use |
Thank you, @Mottie! I will try not to overuse ability to push changes directly to master. Anyway I want to finalize work on groupers before merging it. I will try to make unit tests too, and sure will let you know when the work is done. |
fbc58ac
to
df2ad3c
Compare
… but whole the text in the cell
…d for visibility to lower indentation level
Oh sorry for not responding. Well, update the project build when you feel like it needs it, or before pushing to master. I don't have any strict requirements. I think I can trust your judgement on when it needs to be done. |
Conflicts: js/widgets/widget-grouping.js
e21d634
to
b5ec059
Compare
Hey @prijutme4ty! I've updated the group widget a few times since this pull request was opened so I'm sure there are a bunch of conflicts. I can incorporate your changes if you feel that the changes are ready. |
Hello, @Mottie. Sorry for a long delay. |
I ended up copying some of the changes you have in the refactoring, but I didn't add the groupers method you included... to me, it seems more complex than the original method. If I wanted to add $.tablesorter.grouping.types.text = function( config, $column, txt ) {
return txt;
}; Then use "group-text" in the header. |
Hi!
I've done some simplifications which will help in further refactoring. I'm going to introduce grouper objects so that all configuration to be done in constructor. It will prevent scattering grouping logic across entire widget codebase. Grouper object should have two methods: groupName and groupId (to be stored in
wo.group_currentGroup
). Also groupers are possible to be cached not to extract parameters each time (as it occurs now).Actually I've done lots of steps in this direction, but I don't want publishing them until you check I didn't removed some unexpected undocumented functionality. I've listed all steps done in the list below.
I hope it will also help me making hierarchical grouping (which is my final purpose, I need it for my work).
Here there are simple changes, some of them just help in code organization, some remove unused options. What was done:
Number grouping logic was too difficult. First it calculated an interval boundary and then it amended it by taking maximum of interval boundary and a different value. For ascending order that number was always less than a boundary, for descending order it was a very strange value... I can't figure out why this value was choosen. It came from the very first version of widget and may be it's just an old mistake which doesn't show itself for positive numbers.
So i just removed this amendment and now it's just an interval boundary. Now the code doesn't rely on group parameter, so it was removed.
If I'm wrong and this logic is necessary, please let me know, I will revert that change.
Language parameter is unused and undocumented, so it was removed. If some grouping logic in future will be language-specific, I think it's better to pass it as an argument to a grouper constructor (I will show it in further commits with grouper object).
Now number group name extractor extracts both boundaries. It changes a bit values to be compared dowstream (at line 111), but it doesn't change final result.
Row is now obtained from a cache --> normalized --> $row.eq(0). (i.e. not-child row). I guess there are no situations when
norm_rows[rowIndex]
is falsy, so I replacedcurrentGroup = norm_rows[rowIndex] ? <extract group name> : currentGroup
withcurrentGroup = <extract group name>
.May be I don't foresee some cases. Also, please let me know if it's true.
Some complex calculations extracted into a separate variables and into a
groupHeaderHTML
function.currentGroups
renamed intocollapsedGroups
. Initial value given inbindEvent
changed from[]
to{}
.ts.grouping
replaced bythis
because it's shorter and more specific.As far as I see, these changes haven't broken anything. Widget works just as it did. When you have time, please, check that the changes listed make sense. I'm not sure they should be merged right now, because though it works good, it's still WIP.
p.s. Is it better to push further commits regarding grouping refactoring in the same pull request (so that once you're possible to merge them altogether) or to create separate pull requests?