8 ms·
We used this for a project before, just be aware that the DOM changes regularly for gmail, and if an API you rely on breaks you will be SOL until someone fixes
by seibelj 10y ago
We used this for a project before, just be aware that the DOM changes regularly for gmail, and if an API you rely on breaks you will be SOL until someone fixes it.
- J_Darnley 10y agoThank god for POP3, IMAP, and SMTP: the superior ways to use Gmail.
- seibelj 10y agoWe were creating a chrome / firefox extensions to manipulate the gmail UI, the project was unrelated to email protocols (but I understand the snark ;-) )
- phaed 10y agoThe snark was uncalled for, so is drawing noses on emoticons.
- nathancahill 10y agoThey are also running into this issue: https://xkcd.com/541/ https://xkcd.com/541/
- colejohnson66 10y agoThe one thing I like about emoji is that it solves this problem. > Linux (or BSD [U+1F642]) would EDIT: Does HN not support emoji? EDIT^2: How it should look: https://pastebin.com/raw/rKmTCdFX https://pastebin.com/raw/rKmTCdFX
- J_Darnley 10y ago> How it should look A square box with 01F 642 in it? I'd rather have a nose on my smilies.
- tomc1985 10y agoSnark is always called for, always appropriate! edit: you downvoters are lame. What a bunch of wimps
- mrb 10y agoMaybe you should explain this in the README. My first thought too was "why are they not using IMAP"?
- deleted 10y ago[deleted]
- phaed 10y agoIt's open-source, if you rely on it, fork it and fix it yourself.
- JoshGlazebrook 10y agoThat still doesn't make it reliable. If it's known the DOM changes regularly and breaks this api library, then why bother in the first place? Sure you can fix it yourself, but why not avoid the hassle and use something standard that doesn't break as much. If it's acceptable that it breaks often then it's fine to use, but if you're expecting reliability, then no.
- alooPotato 10y agosee my comment to your sibling...
- seibelj 10y agoThe issue is that gmail will update at anytime, without warning, so there will always be a period when your service will break. And you need to have unit tests running often to figure out when it breaks, and have a dev on call 24/7 to ensure a speedy fix. This is a universal problem with extensions targeting website DOM's, but worse if you have an SaaS product that has an SLA.
- nathancahill 10y agoWhich Gmail addon did you work on?
- seibelj 10y agoAn MVP for a startup we never got any traction on :)
- alooPotato 10y agoFounder of Streak here (we make the InboxSDK) - this is one area where we take a slightly different approach than Gmail.js. We host our SDK and you remotely load it at runtime. The benefit is that we detect breakages due to gmail and automatically update the SDK. Your users just need to refresh gmail to load your extension and the latest SDK which is compatible with any changes Gmail makes.
- andreasklinger 10y agoAgree. I did a gmail plugin before gmail.js came out. You kind have the same problem if you are the only one using your custom lib and you dont have a huge army of others who could fix it. And it's… so… much… more exhausting
- foota 10y agoIt seems like you might be able to come up with a way to auto-generate these selectors based on known content on the page. ie, find the thing that has this text in it and use that as the selector from now on.
- andreasklinger 10y agoi dont know how it's today back then we even ended up using surprisingly complex structures that actually are close to what you describe but clientside. as in: we didnt rely on classnames but often on positions next to some text. ``` find(SomeTitle).parent.parent.find(p[something]).text ```
- taternuts 10y agoThats exactly what I was wondering about; you can see in the latest merge 11 days ago that a selector had to be updated with random junk to match a recent change (from '.ii.gt' to '.ii.gt div.a3s.aXjCH')