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
avoid duplicates #158
avoid duplicates #158
Conversation
- added tests for Settings - add test for wrangleTabs - replace underscore with lodash because of undefined error when testing tabmanager
added some tests and fixed the failing once
change pattern for tests folder to avoid 2 consecutive runs added new filter to find tab position by hostname and title added tests added new component for tab wrangle option
…nto ingo/avoid-duplicates
…wrangled and added to the wrangled tab list
- fixed the test description
…nto ingo/avoid-duplicates
- added new description for the wrangle options
- fix broken test case
- fix broken test
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.
Thanks for the PR. Can you check the Lodash dependency and whether this works with a fresh node_modules directory from a yarn install
? If you need a single function from Lodash you can include a small portion of Lodash.
app/js/TabWrangleOption.js
Outdated
super(props); | ||
|
||
this.state = { selectedOption: this.props.selectedOption }; | ||
this.handleChange = this.handleChange.bind(this); |
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.
Prefer property initializers instead of bind
in the constructor:
handleChange = (e) => {
...
};
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.
Fixed this
app/js/tabmanager.js
Outdated
@@ -1,7 +1,10 @@ | |||
/* @flow */ | |||
/* global TW */ | |||
|
|||
import _ from 'underscore'; | |||
// import _ from 'underscore'; |
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 doesn't seem correct. Were you testing replacing Underscore with Lodash? Lodash is not listed as a dependency.
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.
Ah, I nearly forgot about that. I was using lodash instead of underscore, because lodash caused an initialization error when running the tests. I couldn't find a solution to it, so I switched to lodash.
And although lodash isn't mentioned in the dependencies it's hoisted through some other dependencies. :-/
The question is if there is no solution to the initialization error with underscore, if we should make lodash a proper dependency and get rid of underscore. What do you think about that?
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.
Lodash is a second-level dependency only of another devDependency (babel uses it, for example). It's not used in released code, however. Using Lodash increases the .zip release file by 30KB.
I'm fine replacing Underscore with Lodash completely, but let's not ship both of them in the same .zip.
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.
Agree, we should only have either one of them only. I'm going to have another look at the underscore init issue. If I can't find a simple solution, I'm going to swap underscore out for lodash.
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 issue seems related to the testing problem: jashkenas/underscore#2152
I'm not sure it's worth spending much time on this. If dropping in Lodash works, I'm cool with that. Feel free to go full Lodash and skip any more debugging. If you do, please use yarn add
/ yarn remove
to update the lock file appropriately and replace import _ from 'underscore';
everywhere with import _ from 'lodash';
. TabWrangler's use of Underscore is limited, so problems from swapping should be limited.
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, that looks exactly what I was seeing. I've swapped underscore with lodash and updated the lock file.
app/js/TabWrangleOption.js
Outdated
selectedOption: e.target.value, | ||
}); | ||
|
||
this.props.onChange(e); |
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 passing the new value up the hierarchy, and it's being passed in via props. Why have state
in this component at all?
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 keep the state to reflect which radio button is pressed. If there is a better way to achieve the same, I'm happy to learn about it.
@@ -85,7 +85,7 @@ const Settings = { | |||
* @see Settings.set |
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.
Can you add an a value in defaults
at the top of this file for the new wrangleOption
setting?
wrangleOption: 'WITH_DUPES',
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.
fixed this
Can you also run |
- replace underscore with lodash due to issues during test run init - add default for wrangle option in settings.js - fix all flow issues with new code
All flow errors are gone now, and I've addressed the review comments. I'm going to bed now. It's too late, and I hope that I didn't forget anything. |
@ingorichter Thanks again for all of your work. I'll test this out locally and get it merged. If there's anything minor, I'll fix it in master. |
Sounds good to me. |
Agreed, running Flow during the build step would be great. I can add that to the Gulpfile. |
This is a solution for #114
This enhancement provides 3 different options to wrangle tabs
allow duplicates (current behavior)
exact URL match
match host and title
This is the current behavior and it will be the default if the user doesn't change it.
Avoid a duplicate wrangled tab if there is already a wrangled tab in the list with the same exact URL. If there is already a wrangled tab, then we push it up to the top of the list and update the timestamp
Avoid a duplicate wrangled tab if there is already a wrangled tab in the list with the same host and the same title. If there is already a wrangled tab, then we push it up to the top of the list and update the timestamp