Fix "Hide" option

[emilgoldsmith]

Lots of unintended behaviour going on, I can list thoroughly if you want, but I'm currently working on fixing it, so the easiest way to show you is through a PR if I figure out what's going on exactly.

[martynchamberlin]

Ok! Also a screencast using something like http://quickcast.io/ is always helpful when describing a bug.

[emilgoldsmith]

Clarification:

As can be seen, specific bugs I found are: Hide Friends is also removing New Game instead of friends, I located this to be, to be frank, horrendously wrong CSS selectors throughout the config file which I'll fix and submit a PR for.

Opening the hide option toggles some kind of reset, so even though in this case new game should be shown, pressing hide makes it show again until you toggle the button twice. I have found the bug to be a problem in the componentDidUpdate somehow, adding shouldComponentUpdate as in #71 has already fixed this issue (in my local fork). So I'll also add a bit more to that and submit a PR at some point, I'll also see if I can get a bit deeper of an understanding of the bug more than just adding shouldComponentUpdate as there may be a deeper underlying issue

[emilgoldsmith]

I just started looking at it a bit again, I'm assuming the CSS selectors used to work once though there's for example one that is .social-share-present with a comment saying this should be applicable to the /home site, which at least as a non-paying member is not even a class on the site (I used Chrome dev tools to do a query).

I'm assuming some of the problems could be with differences between members like for example adds that I have while paying members might not have them. But we definitely need to cover all edge cases where I guess cases are paying members, free members, and even non-logged in though it's very unlikely that someone would use the plugin without having a user.

I can definitely do better than has been done now, also because the specificity of things are completely off sometimes (having super specific ones and then super general selectors which all get "or'ed" so the general ones will delete things on other sites like for example #sidebar > section:nth-of-child(2) will hit something unintended on basically any site).
Yeah I'm not writing way too structure right now, but I can definitely do better, but my overall message is, the easiest thing would definitely if from you guys (Chess.com)'s side you put ID's on all the elements you want to hit here, then CSS selectors would become a piece of cake.

[emilgoldsmith]

So yeah I've been doing some more CSS selector queries on chess.com and with for example the hide friends button I believe it's currently impossible to use pure CSS selectors to accurately select only Friends in a general way that works for all the pages.

So the easiest is definitely if you could add ID's from the Chess.com side of things. I could also make it work by adding an extra level to Config and further down the "tree" where you could make selector "cases" with regex for matching URLs. So that if it's /home we use this selector, otherwise use another one etc.

What are your thoughts @martynchamberlin ? Do you think adding ID's is plausible or should this project be completely separate?

If we added ID's and Chess.com consistently added these ID's on any new pages it would also be super future proof and a nice non-hardcoded solution which would be great.

[martynchamberlin]

Ok! Makes sense. Let me make a note to add proper IDs to these elements!

[emilgoldsmith]

That's great @martynchamberlin, that would make for some really nice code. Just imagine for example Chess.com makes a new page, or moves around some elements, and because of good ID's, the extension just keeps on working seamlessly :).

[emilgoldsmith]

Just added on hold until ID's are pushed to Chess.com production

[martynchamberlin]

@emilgoldsmith What aspect of the extension do we need to add IDs for? I'm wanting to put together a list of things that need IDs. Is it just the "Hide" section we're talking about?

[emilgoldsmith]

Hey @martynchamberlin. Awesome that you're taking initiative to get that done. Well I guess it would be awesome for everything really. Text, backgrounds and hide. It was just Hide that I on my initial play with the app noticed some quite gross bugs with.

But I'm assuming Chess.com would at some point love to have this extension be a production-ready marketable extension, and if you had consistent IDs on every element that is being targeted by the extension that would make everything super clean, bug-free and future proof.

Yeah so from my perspective I'd love to see all the selectors in Config.js be a single selector with either an ID or maybe a Class for things like backgrounds, but not all these "pseudo-cases" which are super bug-prone and end up either not targetting everything they should, or targetting something unintended, or breaking when Chess.com changes a bit of structure on the site or depending on whether you have ads etc (paying member or not).

So if I were you I'd go through the html of Chess.com and become very clear in the design decision of what exactly is it I want each extension button to target, and then make the CSS selectors for that super clean and simple.

[martynchamberlin]

Given that we're on the cusp of making a major change to the home page, I'm going to put this on hold until that's merged. Should be this week though!