Sitecore Javascript

How we use Javascript patterns to develop better Sitecore projects

Why you need seamless development processes

At Kagool, we use Sitecore Javascript patterns to make sure our code is consistent. Addy Osmani, a Web Engineer at Google, said, 'Design patterns are reusable solutions to commonly occurring problems in software design.'

Sitecore Javascript patterns are well known and tested ways of solving common problems. This approach makes picking up new projects easier from one Sitecore developer to another. Things are written in a defined way. So development can be seamless.

Here are the main Sitecore Javascript patterns that make development easier and help create maintainable code:

Revealing module pattern

The revealing module pattern is a pattern we use consistently on every project. It uses a self-invoking function to create a self-container scope. For example, when other modules or plugins assign a value to the commonly used $. You can work the revealing module pattern in safely without spoiling the global scope.

Sitecore 8 in particular uses a framework called prototype which declares $. This can cause issues during development. To combat this, we use the revealing module pattern alongside jQuery noConflict. And that works on anything outside of our modular pattern modules.

The way that we split up our Sitecore components means a lot less coupling. One module won’t break another unless they are interacting directly. The revealing module pattern can help to keep errors in one area of an application. So any issues with code are kept in this scope.

The syntax is very simple:

            (function($){

                        ...

            }(jQuery);

 

Mediator pattern

This isn’t the most commonly used Sitecore Javascript pattern. But it’s a useful tool to keep in your back pocket. Especially when you’re creating complex functionality and modules that affect each other.

The mediator pattern acts as a middleman between modules that may affect each other. Even though they are completely separate. It resolves events and pushes new ones, encouraging each module to react as they should.

For example, you could have an undefined amount of panels come over the top of the page content. They all need to work individually. But it’s also important that only one panel at a time overlays the content.

Here’s how we used a mediator pattern to solve this issue:

            app.examplePanel = (function ($) {

                var init = function () {

                    ...

                    // tell the mediator about itself

                };

                var open = function () {

                    ...

                };

                ...

                return {

                    init: init,

                    open: open,

                    close: close

                };

            })(jQuery);


            app.panelMediator = (function ($) {

                var panels = {}; 

                var openPanel = function (panel) {

                    panels[panel].open();

                }

                var hidePanels = function (triggerPanel) {

                    $.each(panels, function (panelName, panel) {

                        if (triggerPanel !== panelName) {

                            panel.hide();

                        }

                    });

                };


                var init = function () {

                    $(document).on('openPanel', function (e) {

                        // when a panel is opened

                        // hide all other panels

                        hidePanels(e.panel);

                    });

                };

 

                return {

                    init: init,

                    panels: panels

                };

            })(jQuery);

  

Singleton pattern

The singleton pattern is very useful to make sure the same method isn’t run more than once. Especially for tasks like fetching large amounts of data. For most pages you shouldn’t need to re-fetch data after the page loads. This pattern saves the user valuable time by helping to avoid re-fetching data.

Here’s an example of a simple singleton pattern:

    var instance; 

    function getItems() {

        var object = $.ajax(...)

        return object;

    }

    return {

        items: function () {

            if (!instance) {

                instance = getItems();

            }

            return instance;

        }

    };

 

Using Sitecore Javascript for a better build

These Sitecore Javascript patterns help us solve some common problems that can happen during Sitecore development. But, more than that, they help us have a more proactive approach.

Using these patterns, we can create a standard and tested way or writing code. Which makes debugging and reading easier. It also means the quality of every build is consistent and the code’s more sustainable.

We’ve got a unique, focused approach to building with Sitecore. We’re always finding ways to make our Sitecore projects simpler and save costs.

If you want to know more about our Sitecore build method, drop us a line. If you’re new to Sitecore, we’d be happy to give you a free Sitecore demo or talk to you about Sitecore pricing.