How to remove decimals in Slider Min and Max values

I was able to remove the decimals by modifying bef_sliders.js and in the format setting when creating the slider, apply the parseInt function to the 'to' and 'from' values.

noUiSlider.create(slider, {
              range: {
                'min': parseFloat(sliderOptions.min),
                'max': parseFloat(sliderOptions.max)
              },
              step: parseFloat(sliderOptions.step),
              animate: !!sliderOptions.animate,
              animationDuration: parseInt(sliderOptions.animate),
              orientation: sliderOptions.orientation,
              start: [defaultMin, defaultMax],
              format: {
                // 'to' the formatted value. Receives a number.
                to: function (value) {
                  //return Math.trunc(Number(value));
                  return parseInt(value);
                },
                // 'from' the formatted value.
                from: function (value) {
                 // return Math.trunc(Number(value));
                 return parseInt(value);

It would be nice if this was a setting in the Exposed Filter Settings section of the view.

Can you test 7.0.x

Can you check if issue on 7.0.x branch?

If experiencing on 7.0.x branch please reopen.

still facing similar decimal issue even after upgrading BEF to release 7.0 on Drupal 10

Still not able to replicate.

The issue occurs when making a range widget: in bef_sliders.js this is the case where $inputs.length = 2. In that case the float values are not truncated.

yes, exactly, can be reproduced when the range is in use.
Please find a patch attached

and here's the patch for 6.0.x

Fixes should be in MRs and let’s add some test coverage

I started a MR, don't have time to work on tests right now. Note: if you're adding this patch to a site, you should apply 🐛 Remove VERSION from libraries.yml Active as well. Otherwise, the JS changes won't be visible in the browser until your browser caches are cleared.

smustgrave → closed merge request !129

Fine to commit this as is as I found another issue that will require test coverage.