Add selection CSS classes to tick labels

[duggi]

Pull request for #751

--

Adds class label-in-selection if tick labels are in the selection range.
Adds class label-is-selection if tick label is selected, min or max.

--

figure 1. example, selection tick labels are in darker font

[seiyria]

please make sure your code passes our linter

[duggi]

resubmitted with compliant style

[rovolution]

anyway we can add some unit tests for this? something as simple as ensuring the tick label elements that get rendered have the expected class tag?

[duggi]

will give it a go. using this in production now so had to create a fork and our own bower package. obvi not ideal so will get this done!

[rovolution]

@duggi any chance to add the tests? i would love to merge this in!

[rovolution]

@duggi any follow up on this?

[duggi]

@rovolution hey sorry for long absence, been busy on other things. could not get the tests authored/working (not my real area of expertise), so put it on hold.

i can ask someone else on my team, or maybe you can give me some quick pointers? i've been working in test/specs/TickMarksSpec.js:

	it("Should show the correct tick labels as 'in-selection', according to the `selection` property", function() {
		var options = {
			ticks: [100, 200, 300, 400, 500],
			value: 250,
			selection: 'after'
		},
		$el = $("#testSlider1");

		testSlider = $el.slider(options);
		expect($el.find('.label-is-selection').length).toBe(1);

		testSlider.slider('destroy');

		options.selection = 'before';
		testSlider = $el.slider(options);
		expect($el.siblings('div.slider').find('.label-is-selection').length).toBe(1);
	});

[rovolution]

@duggi so based on this example snippet, these would quality as 2 different test cases...one to check if the classes are applied if the selection value is 'after', and one to check if the classes are applied if the selection value is 'before'. Therefore, each of these would be in their own it block.

You would want to have tests for checking if .label-is-selection is applied in the proper cases and if .label-in-selection is applied in the proper cases.

Any common setup (like options) should be moved into a beforeEach function, which will execute before each test is run to ensure the common state is reset properly. Likewise, any common teardown setups should be moved into an afterEach block. See the Jasmine docs for further details

You should be working in the /test/specs/TickLabelSpec.js file, since this is more tick label related. You should nest these under a new describe block so that you can add setup/teardown blocks that only run before your new tests for each use-case.

Your assertion's look fine to me, so I definitely think you are on the right track. Here is what I think it would roughly look like.

/* /test/specs/TickLabelSpec.js */

describe("'.label-is-selection' tests", function() {
 var options;
  var testSlider

 // setup that is executed before each test case in this 'describe' function
 beforeEach(function() {
    var options = {
       ticks: [100, 200, 300, 400, 500],
       value: 250,
       selection: 'after'
    };
  });

 // teardown that is executed after each test case in this 'describe' function
 afterEach(function() {
   testSlider.slider('destroy');
 });

 // test cases
 it("Should show the correct tick labels as 'in-selection' if selection is 'after'", function() {
     // Create a new slider
     var testSlider = $("#testSlider1").slider(options);

    // Assert
   expect($el.find('.label-is-selection').length).toBe(1);
 });

 it("Should show the correct tick labels as 'in-selection' if selection is 'before'", function() {
     // TODO
 });
});

describe("'.label-in-selection' tests", function() {
   // TODO
});

[rovolution]

@duggi have you had a chance to look at this? Thanks!

[duggi]

thanks for the detailed example, i'll give it a shot soon. been busy as we're launching a new product line, featuring bootstrap-slider!

this is a priority, since we don't want our app dependent on my fork; just gotta clear out some time to put in some work

[rovolution]

@duggi thats awesome! if its possible, we would love to see a screenshot or GIF of the slider in your new product! Its always exciting to see how the project is being used :)

[duggi]

screenshot in my initial comment ... repasted at bottom.

you can also see it live here, click on "Free Consultation" for any advisor. Note this impl is single value only, not range. also uses different styles.

(please don't actually submit a request)

--

[jespirit]

It's been over a year, so I thought if I could come in and add some tests.

I added unit tests for the label-is-selection and label-in-selection classes.

I may have to do a little refactoring to comply with codeclimate and actually check if the correct tick labels have the correct classes.

[jespirit]

How do I deal with the codeclimate.yml file errors?

Do I need to merge in the master branch or rebase onto the master branch to incorporate any new changes since this pull request?

[rovolution]

@jespirit dont worry about the code-climate check. in fact, i will probably go ahead and remove it since if feel it does not really add any value to our project

[seiyria]

@rovolution I got it uninstalled. It shouldn't appear any more!

[rovolution]

@seiyria cool i deleted the config from our repo so it should stop showing up now. @jespirit try rebasing this branch against the latest master to remove the codeclimate check

[jespirit]

I rebased onto master and added more logic to the unit tests.