bxslider-4
bxslider-4 copied to clipboard
stevenwanderski
Public methods for settings interaction
So far the settings variable was only available inside of the object passed as first argument to the asynchronous onSliderLoad callback. This PR adds public methods to instantly access and manipulate the settings from outside.
Would you mind rebasing this off the new current 4.2.4 master? If so I would like to add this.
Interacting with settings while initialized brings some caveats. I already tackled the one for disabling attached touch events. But there is still some with which one would have to reload the slider after settings interaction.
In this context I also thought about overwriting options with slider.settings in el.reloadSlider() - this would prevent current settings to dissolve. Look at jquery.bxslider.js#L1566
What do you think?
You are right, this becomes a little more complicated when you change something like mode.. I can think of two solutions:
- Easy Solution - Internally call
reloadSlider()when settings are changed. - Not as Easy Solution - Enhance
redrawSlider()to take into account when some of the setup options have changed and adjust accordingly, calling this internally when settings change.
Thoughts?
I haven't really checked the magnitude of possible side effects. Certainly the setter should act on some changes with either a reload or a redraw. A full realoadSlider() obviously causes a lot of DOM manipulation which could be prevented in several places. Implementing the first suggestion for the moment should be a quick one fits all solution from where we could move forward.
For advanced usage I'd suggest setSettings() to accept an optional boolean argument for manual reload prevention. For example settings.speed shoots into my mind where I would like bxSlider not to fully reload.
I think that there is a lot potential for code cleanup and simplification which would have a bigger impact than overdoing this specific feature. This said, some sort of mapping to an object holding initialized interaction safety information could also be a viable solution in the future. ;-)
I think that setSettings should only set settings and not call reloadSlider or redrawSlider. Developers can always do it themselves. I also don't think there should be a boolean argument.
@szarouski That's a statement - would be fine with me. Unfortunately this could lead to inconsistent behaviour especially with less experienced users - causing another flood of issues regarding this.
I'm already seeing issues like "setSettings doesn't work"
@ppowalowski I think we should encourage developers to use api properly. For less experienced developers there is always a reloadSlider method.
I agree that this doesn't need to be overworked because I am planning to start bxSlider5 as a complete overhaul shortly anyways, but I'm not entirely keen on issues being flooded because of a misunderstanding of the methods usage.
What if we have a param for reload but default it to false, that way a clean call can be made, but you can pass true if you want it to also reload?
Would do the job.
bx5 also sounds great. Are there specific plans already?
A more modular design with a pluggable architecture. Data Attributes. Revamped Captions. Custom Transitions. Responsive Breakpoints.
This is the short list, but I am open to more suggestions and more hands on the development. I plan on doing one or two more point releases before I freeze work to start work. Let me know if you have bandwidth to participate.
@Tidal-Wave, events instead of callbacks will be an awesome feature too. Not sure that I'll have time to help with it though...
Yes I agree, that was actually on the list too, was just thinking off the top of my head.
I appreciate any assistance that can be given, from developing to testing. Thanks!
@Tidal-Wave @szarouski Where to best move bx5 discussion?
If we created an appealing consent on the agenda I would contribute to that mindblowing unicorn slider widget :+1: