#235 Popups in Geo-Locations section in profile open "Where I live" p…

[noviodelangel]

Setting button type to button makes it non-actionable on enter Fixing e2e tests for this functionality to make it less flaky

IMPORTANT: Checklist before committing / pull-request:

• [x] IMPORTANT: Please read this checklist and checkmark the items, putting [x] at the beginning of the bullet-point
• [x] Think of the reviewers and make their life easier :) while also keeping You reputation good by committing high-quality code and avoiding bad-quality commits
• [x] Self-review before committing, with graphical diff (e.g. IDE like WebStorm), ideally with per-character diff highlight.
• [x] Provide descriptive commit message, pull-request titles and branch names, including issue number in commit message, e.g. #123
• [x] "Boy Scout Rule" - try to leave code in a bit better state than when You found it. Or at least don't leave it in worse state.
• [x] Proper indentation. Two spaces in Angular.
• [x] Use spell-checker built into Your IDE
• [x] Avoid compiler warnings or tslint / codelyzer / IDE warnings
• [x] Run unit tests npm test and TestCafe cd e2e-testcafe ; npm i && npm test
• [x] Check Continuous Integration (CI) build status (takes about 1m30s) after pushing
• [x] Small files / modules / classes / methods / components (Single Responsibility Principle). Even if a given thing seems like it will not be re-used, it should be split off, for the sake of making it easier to analyse it (and maybe it will actually be reused in the future or a new implementation will be developed / experimented-on in the future)
• [x] Don't put random changes in pull-requests, e.g. reformatting entire files, changing quotes to double/single, etc. For the sake of easier reviewing and not polluting git annotate
• [x] Please follow platform / language / library style guides
  • camelCaseVariableNames
  • CamelCaseClassNames
• [x] Avoid duplicate code. Do not copy-paste ~2 or more lines. Instead, extract component / class / method / function and reuse in all places. For the sake of future maintenance.
• [x] Test on mobile resolutions. Manually and via cd e2e-testcafe ; npm i && npm test:all
• [x] Complex structured data should be displayed using HTML, not plaintext (applies e.g. to popups / tooltips as well), for styling it to make it more readable and look better, being able to add icons, images, links, etc.
  • [x] Prefer components over pipes, for things that might need some varying styling inside (even things like numbers-with-separators, currency, dates, time). Can :host { display: inline }.
• [x] Naming:
  • [x] Avoid cryptic/short names like a, x, etc
  • [x] Use names consistent with the name of the type, like user: User, dialogService: DialogService
  • [x] Use existing terminology/naming (look in related code to see what terms/names are used)
  • [x] Avoid using vague terms like data, info, object. Prefer to be more descriptive.
  • [x] Don't give alias names to @Input()-s
• [x] If possible, use existing utility functions, e.g. from Lodash, for example things like sumBy
• [x] Wrapping margin should be at about ~120-140 chars (160 columns an absolute maximum). Don't start new significant stuff beyond column 100 (just continuation of existing stuff). The logic is to see the significant stuff on a laptop screen, while seeing whole lines on big monitor. But since TypeScript is not Java, it is easier to keep lines shorter :).

[noviodelangel]

Related Issue: https://github.com/TopicFriends/TopicFriends/issues/235

[noviodelangel]

PR-236-.zip

Screencasts for mobile and desktop views

[noviodelangel]

pr-236.zip

Screencasts for mobile and desktop with comentary