In the last post, we walked through the process of setting up a jQuery slider on a page. To keep that post concise, I passed over some details that I want to flesh out here.
The first is a look into what the browser “sees” when we are using RequireJS. In the first blog post of this series I showed the page source of a Magento 1 site and a Magento 2 site. In the Magento 2 site you saw there were only 3 files being loaded onto the page:
It turns out that all these files are accessible to you through the network panel.
These are the individual scripts that make up the combined mass that is loaded onto the page. From here you get a plethora of valuable information about what happening on your page. Like…
So you might have noticed that I said 135 and not the 136 that are pictured. Well, that extra script is ours. You can search for that script and see it’s loaded.
From there you can then look at the content of the file. This is helpful because…….
pub folder. Even though we are editing the files in the theme, what the browser sees is the file are is exists in
pub. So it’s a common problem to edit the theme file, reload the page and then……..nothing changes. Looking at the file in the Network tab will tell you exactly what the browser sees. This is extremely important for development as it rules out why your edits may or may not be showing on the page.
When we get deeper into more complex scripts, this information will be essential to create complex functionality. It’s also helpful as when you are setting up a file as a mixin or override that your configurations are correct and Magento actually “sees” the file. And lastly, it allows you to set breakpoints in a script to debug its content in the browser.
In a small system, such as a simple WordPress site or a custom Laravel site, this isn’t too much a problem. But think about what this would look like if you were building a platform that will have thousands of developers all making custom changes to the application. You need to have that system work out these issues with every custom site build, with a limitless number of unknown files. Magento’s solution was to not leave this up to the end developer.
Looking in the network tab, you will see the exact order of all your files. We have talked about the “jQuery is not defined” in a past post, and this is where you can debug that. If your file depends on
modal.js (as some future projects we will work on will), and you find that your custom file is loaded first, that would be reason #1 why your script isn’t working. You will notice that
jquery is defined at the very top of the load order, and that way down at the bottom we have our script.
This system serves two main functions. The first being the reduction of page weight. While JS files are small in size in most cases, in a page speed-obsessed world, every little bit helps. When a page can consist of any number of elements (given the flexible nature of Magento and varying needs of merchants) the process of adding an Add To Cart button onto a page doesn’t necessitate anymore code then what that element needs.
What this means for Magento 2 is we have more freedom to move elements around on the page, as well as the site, knowing that the dependencies will be self-contained. This frees up Magento 2 to work towards being a “fully modular” framework.
This was a shorter look into the tools for debugging your work. I would encourage you to play around in the Network tab and get to know it well, the information there will become a part of your daily life as a front end developer.
The next post I will go deeper into is the RequireJS configuration file itself. Why it’s there, where it lives and what kind of superpowers it has hidden.