New Landing How can we help? Themeforest Theme Support Neighborhood Overriding methods in functions.js?

Viewing 12 posts - 1 through 12 (of 12 total)
  • #87704
    airuck
    Member
    Post count: 36

    (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!
    -Aaron

    #87936
    airuck
    Member
    Post count: 36

    Hi 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,
    -Aaron

    #87960
    airuck
    Member
    Post count: 36

    Removing a line of debug output I left in first patch

    #88021
    Mohammad – SUPPORT
    Moderator
    Post count: 27441

    Hi,
    The developer of theme will assist you very soon.
    Thanks

    #88170
    Swift Ideas – Ed
    Keymaster
    Post count: 15264

    Wow, 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

    #88236
    airuck
    Member
    Post count: 36

    Ed,

    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,
    -Aaron

    #88806
    Swift Ideas – Ed
    Keymaster
    Post count: 15264

    Hi 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

    #92017
    airuck
    Member
    Post count: 36

    Ed,

    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,
    -Aaron

    Attachments:
    You must be logged in to view attached files.
    #92066
    Kyle – SUPPORT
    Moderator
    Post count: 35880

    Thanks @airuck we really appreciate it

    – Kyle

    #93421
    Swift Ideas – Ed
    Keymaster
    Post count: 15264

    Hi 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

    #93822
    airuck
    Member
    Post count: 36

    Sure, here it is

    Attachments:
    You must be logged in to view attached files.
    #93889
    Swift Ideas – Ed
    Keymaster
    Post count: 15264

    Thanks, just added this in!

    – Ed

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.