{"id":22597,"date":"2018-09-11T12:15:17","date_gmt":"2018-09-11T09:15:17","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=22597"},"modified":"2018-09-08T01:52:08","modified_gmt":"2018-09-07T22:52:08","slug":"monolithic-repos-are-evil","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/javascript\/monolithic-repos-are-evil\/","title":{"rendered":"Monolithic Repos Are Evil"},"content":{"rendered":"

We all keep our code in Git <\/del>version control<\/a> repositories. The question is whether we should create a new repository for each new module or try to keep as much as possible in a single so called “monolithic” repo. Market leaders, like Facebook<\/a> and Google<\/a>, advocate the second approach. I believe they are wrong.<\/p>\n

Let’s use the following JavaScript function as an example. It downloads a JSON document from a Zold<\/a> node (using jQuery<\/a>) and places part of its content on the HTML page. Then it colors the data according to its value.<\/p>\n

\/\/ main.js\r\nfunction main() {\r\n  $.getJSON('http:\/\/b1.zold.io\/', function(json) {\r\n    var $body = $('body');\r\n    $body.text(json.nscore);\r\n    var color = 'red';\r\n    if (json.nscore > 500) {\r\n      color = 'green';\r\n    }\r\n    $body.css('color', color);\r\n  });\r\n}<\/pre>\n
Pretty obvious, isn’t it? Just a single main.js<\/code> file which does everything we need. We simply add it to the HTML and it works:<\/p>\n
<html>\r\n  <head>\r\n    <script src=\"https:\/\/code.jquery.com\/jquery-3.3.1.min.js\"\/>\r\n    <script src=\"main.js\"\/>\r\n  <\/head>\r\n  <body onload=\"main();\">loading...<\/body>\r\n<\/html><\/pre>\n
Now, let me refactor it. Let me break it into two pieces. The first piece will load the data and the second one will be a jQuery plugin to colorize HTML content according to the data it contains. This is how the plugin will look:<\/p>\n
\/\/ colorize.js\r\n$.fn.colorize = function() {\r\n  var data = parseFloat(this.text());\r\n  var keys = Object.keys(colors)\r\n    .map(function (k) { return parseInt(k); })\r\n    .sort(function (a,b) { return a - b; })\r\n    .reverse();\r\n  for (i = 0; i < keys.length; ++i) {\r\n    var max = keys[i];\r\n    if (data >= max) {\r\n      this.addClass(colors[max]);\r\n      return;\r\n    }\r\n    this.removeClass(colors[max]);\r\n  }\r\n  return this;\r\n}<\/pre>\n
The main.js<\/code> will look like this:<\/p>\n
\/\/ main.js\r\nfunction main() {\r\n  $.getJSON('http:\/\/b1.zold.io\/', function(json) {\r\n    $('body')\r\n      .text(json.nscore)\r\n      .colorize({ 500: 'green', 0: 'red' });\r\n  });\r\n}<\/pre>\n
Now, instead of a single monolithic piece of code, we have two smaller pieces which have to be loaded together into the target HTML:<\/p>\n
<html>\r\n  <head>\r\n    <script src=\"https:\/\/code.jquery.com\/jquery-3.3.1.min.js\"\/>\r\n    <script src=\"colorize.js\"\/>\r\n    <script src=\"main.js\"\/>\r\n  <\/head>\r\n  <body onload=\"main();\">loading...<\/body>\r\n<\/html><\/pre>\n
Two pieces are better than one? It seems that Google<\/a>, Digital Ocean<\/a> and Mozilla<\/a> don’t think so.<\/p>\n
I disagree.<\/p>\n
To illustrate my point I extracted the JavaScript function into a new standalone jQuery plugin<\/a>. Here is what I did:<\/p>\n