Skip to content
This repository has been archived by the owner on Aug 21, 2023. It is now read-only.

Feature/multi chart scrubber #104

Merged
merged 4 commits into from Oct 24, 2016
Merged

Feature/multi chart scrubber #104

merged 4 commits into from Oct 24, 2016

Conversation

fungjj92
Copy link
Contributor

@fungjj92 fungjj92 commented Oct 20, 2016

Overview

Multi chart scrubber for yearly indicators!

Demo

screen shot 2016-10-20 at 11 30 24 am

screen shot 2016-10-20 at 11 55 26 am

screen shot 2016-10-20 at 11 36 12 am

### Notes

Multi-scrubber depends upon 2 Observable streams. One listens for any chart #overlay being moused over and relays it to every line graph component. The other listens for mouse positioning and relays that to every line graph component to redraw the scrubber.

Testing Instructions

Toggle multi-chart scrubber in project settings and mouse over charts.

Closes #97

@CloudNiner
Copy link

Won't have a chance to look at this before RRP, feel free to reassign as necessary.

@fungjj92
Copy link
Contributor Author

That's okay, no rush on it.

Copy link

@CloudNiner CloudNiner left a comment

Choose a reason for hiding this comment

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

LGTM, consider var renaming if appropriate.

private multiChartScrubberInfo = new Subject();
private multiChartScrubberHover = new Subject<Boolean>();

multiChartScrubberInfo$ = this.multiChartScrubberInfo.asObservable();

Choose a reason for hiding this comment

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

Is this $ postfix a common convention in the rxjs world? If it isn't, it may be better to just make the public property just be multiChartScrubberInfo or multiChartScrubberObservable and then give the private var the same name with an _ prefix in order to be consistent with existing JS naming conventions.

Copy link
Contributor Author

@fungjj92 fungjj92 Oct 24, 2016

Choose a reason for hiding this comment

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

I saw the $ in a lot of use cases and some Angular documentation, but no explicit mention of it being the convention. In fact, I can't find any convention documentation anywhere.

OTM and Civic Apps use "Stream" as the (bacon.js) observable postfix and find it helpful for readability. This is something they came up with on their own as opposed to universal standards.

"Observable" seems clear to me for now until/unless we decide otherwise

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like it's a pattern from Cycle.js, I've seen it used in a couple places but it seems to stem from them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice find @rmartz. I personally quite like the $ and would adopt it happily if the team was into it. Otherwise, nameObservable or nameStream are clear to me.

@@ -13,8 +13,23 @@ import * as _ from 'lodash';
@Injectable()
export class ChartService {

private multiChartScrubberInfo = new Subject();

Choose a reason for hiding this comment

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

A subject seems pretty correct for this implementation. While I have limited experience as well, Subjects can be frowned upon as they have state, which is no good for the functional programming paradigm, and so see limited use.

I found this, appears to be a great deep dive into when to and when to not use Subjects:
http://davesexton.com/blog/post/To-Use-Subject-Or-Not-To-Use-Subject.aspx

@fungjj92 fungjj92 merged commit 6db09e3 into develop Oct 24, 2016
@fungjj92 fungjj92 deleted the feature/MultiChartScrubber branch October 24, 2016 14:51
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants