Skip to content
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

Merged
merged 19 commits into from Sep 28, 2017
Merged

Conversation

ingorichter
Copy link
Contributor

This is a solution for #114

This enhancement provides 3 different options to wrangle tabs

  1. allow duplicates (current behavior)

  2. exact URL match

  3. match host and title

  4. This is the current behavior and it will be the default if the user doesn't change it.

  5. 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

  6. 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

- 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
- added new description for the wrangle options
- fix broken test case
- fix broken test
Copy link
Member

@ssorallen ssorallen left a 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.

super(props);

this.state = { selectedOption: this.props.selectedOption };
this.handleChange = this.handleChange.bind(this);
Copy link
Member

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) => {
   ...
};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed this

@@ -1,7 +1,10 @@
/* @flow */
/* global TW */

import _ from 'underscore';
// import _ from 'underscore';
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

@ssorallen ssorallen Sep 27, 2017

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.

Copy link
Contributor Author

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.

selectedOption: e.target.value,
});

this.props.onChange(e);
Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Member

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',

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed this

@ssorallen
Copy link
Member

Can you also run yarn flow and resolve the Flow errors that are present?

- 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
@ingorichter
Copy link
Contributor Author

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.

@ssorallen
Copy link
Member

@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.

@ingorichter
Copy link
Contributor Author

Sounds good to me.
Thank you for the feedback. Perhaps we should add yarn flow to the travis config. It's easily forgotten, and it'll make reviews shorter by not doing an extra round and fix that issues.

@ssorallen
Copy link
Member

Perhaps we should add yarn flow to the travis config.

Agreed, running Flow during the build step would be great. I can add that to the Gulpfile.

@ssorallen ssorallen merged commit 8cec23f into tabwrangler:master Sep 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants