Digital experiences for all disciplines
New Landing › How can we help? › Themeforest Theme Support › Neighborhood › Overriding methods in functions.js?
New Landing › How can we help? › Themeforest Theme Support › Neighborhood › Overriding methods in functions.js?
- This topic has 11 replies, 4 voices, and was last updated 10 years by Swift Ideas – Ed.
-
Posted in: Neighborhood
-
July 3, 2014 at 7:47 am #87704
(This is probably a question best for Ed.)
I’m wondering what best practice is so override methods within functions.js for a child theme. It looks like a very well-structured file, separated into e.g. page and woocommerce namespaces. If I wanted to override, say, the woocommerce.productZoom method, is there recommended syntax for this?
If not, can these functions be exported globally (e.g. window.Something), or made not private, so that individual methods can be overridden? I can’t currently do:
woocommerce.productZoom = function(zoomObject) {my zoom settings...};
This is because all methods are wrapped in an anonymous function(function(){ ...page, superSearch, header, nav, woocommerce, etc... })(jQuery);
Just commenting out the first and last lines above allows me to do, from the console:
woocommerce.productZoom = function() {console.log('zoom!')};
And this works fine and solves the issue for any child theme developer, or anyone wanting to customize the javascript: they just include their own js and override any named method they choose.As it stands now, I’m de-queueing and adding a child theme copy of functions.js with my changes. This isn’t very sustainable, since I’m only changing a few small things, and there’s a lot of stuff in that file. It just looks like this code was written intelligently, with the ability to override it in mind.
Can this anonymous function wrapper be removed, named, or made global with window.something? Then these methods would be customizable by any child theme developer without any further trouble on your end.
Thanks for your time!
-AaronJuly 4, 2014 at 1:42 am #87936Hi Ed,
I realized the original proposal wasn’t ideal, since name collisions can happen if you remove the anonymous function container, which I assume is why you did it. Attached is a simple patch that changes very little, and addresses this concern with a namespace for all swift framework functions in functions.js.
It’s pretty straightforward, and I checked each method call after the regex replace and corrected a few. I tested that all of the init methods ran without error, so this is a drop-in replacement that should cause no issues. I have this version running now on my dev site, and am now able to override any method, similar to the example in the original post:
SF.woocommerce.productZoom = function(zoomObject) {console.log('zoom!')};
The patch adds an SF namespace to all method objects within functions.js. None of the code has to changed except the declarations. I don’t think this approach has any downside, as your code is safe from namespace collision, but your users can override any one of these methods with their own javascript.
The patch is against the latest 1.80. I hope you will consider including this in the next release, it will be hugely helpful to anyone trying to customize javascript, and takes advantage of the already-well-thought-out method names and organization of your swift framework javascript functions.
Cheers,
-AaronJuly 4, 2014 at 6:48 am #87960Removing a line of debug output I left in first patch
July 4, 2014 at 10:22 am #88021Hi,
The developer of theme will assist you very soon.
ThanksJuly 4, 2014 at 3:33 pm #88170Wow, thank you very much @airuck !
Not quite sure how I hadn’t ever thought of this before, but I’ll definitely check it out, test it thoroughly, and add it in for the next update!
Thanks again, really appreciate it.
– Ed
July 5, 2014 at 5:34 am #88236Ed,
Sure, I’m happy to help. That version didn’t include a hook for flexSlider, which I’ve added since.
Given this namespacing, I was also thinking it would be useful (and painless) to add some callbacks in logical places into these functions. For example, let’s say a client wants to perform something whenever the image slide changes (like updating text somewhere, or a pinterest button link, or something).
If the methods are defined atop each object, they can serve as user documentation.
SF.flexSlider = { // User callback placeholders. // After product image slide changes. SF.flexSlider.productSlideChange() = function(productSlider) {...}; productSlideChange: jQuery.noop, init: function() {
It’s already defined as an empty function so we can just call it where the product slider is being instantiated:
before: function(productSlider) { if (hasProductZoom) { jQuery('.zoomContainer').remove(); } SF.flexSlider.productSlideChange(productSlider); },
Then a user can put something like this in their own javascript file:
SF.flexSlider.productSlideChange = function(productSlider) { console.log('after product slide change'); };
Here’s that code working: https://hookandloom.com/2014dev/product/ashley-rug-blue-white/
I bet there would be a use for several of these type of placeholder hooks, but it’s the kind of thing that could be added quickly as necessary. I’m sure you can think of a few callbacks based on user requests, but the example above would be something I’d use right away. If nothing else, it’s an option for later on to make your theme as extensible as possible.If you have a public git repo or some better way you’d like patches or pull requests, let me know. I’m happy to send along a patch that adds flexSlider to the SF namespace, and adds this placeholder method.
If you want to chat about the idea of extensibility, or have thoughts on a similar approach, feel free to email me any time. I’m happy to talk about such nerdy things for a few minutes if I can be of any help. Improvements like this help both the users and the theme authors / maintainers, so I appreciate you listening and responding, too.
cheers,
-AaronJuly 8, 2014 at 12:48 am #88806Hi Aaron,
Thanks a lot for the example, got this on my list to work on implementation as soon as possible.
Appreciate you taking the time, happy to hear any other ideas you may have that would help you out.
– Ed
July 17, 2014 at 8:37 am #92017Ed,
Here’s the patch with the above changes mentioned (flexSlider included in the SF namespace, and the productSlideChange function placeholder as shown in the code example of my previous post). The patch is against neighborhood 1.80.
cheers,
-AaronAttachments:
You must be logged in to view attached files.July 17, 2014 at 9:40 am #92066Thanks @airuck we really appreciate it
– Kyle
July 21, 2014 at 9:03 pm #93421Hi Aaron,
Could you possibly send me the final changed file you have? Will be quicker for me as I can just do a merge?
Thanks,
– Ed
July 22, 2014 at 6:28 pm #93822Sure, here it is
Attachments:
You must be logged in to view attached files.July 23, 2014 at 12:55 am #93889Thanks, just added this in!
– Ed
-
Posted in: Neighborhood
You must be logged in to reply to this topic.