![\"Circular](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2018\/06\/ES6-v2-illustration.jpg\")
<\/figure><\/div>\n\n\nCircular dependencies<\/h2>\n\n\n\n
If you are not familiar with the term, let me briefly explain what that is and why would you prefer to avoid that in your code.<\/p>\n\n\n\n
According to Wikipedia<\/a>, In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly.<\/em><\/p>\n\n\n\n They are not always evil, but you might want to treat them with special care. They cause tight coupling of the mutually dependent modules. These kinds of modules are harder to understand and reuse as doing so might cause a ripple effect where a local change to one module has global effects. It might indicate lack of a larger context or proper architecture. A good architecture imposes uni-directional flow between modules and entire layers. Top-level modules depend on lower-level modules whose entry points depend on their own internals in turn. In larger systems, though, problems sometimes come up, especially during refactoring.<\/p>\n\n\n\n On the other hand, circular dependencies are sometimes needed, i.e. in tree structures where parents refer to children and vice-versa. In functional programming it\u2019s even encouraged to have recursive definitions to some extent. Nonetheless I would strongly discourage you from intentionally introducing circular dependencies in JavaScript.<\/p>\n\n\n\n In ES6 modules can have a single default export as well as many more granular named ones. Each module can be thought of as a single file. One of the key design goals of ES6 modules was support for circular dependencies. There were a few reasons for that<\/a>. The main reason is not to break the module system while refactoring and let software engineers decide if it\u2019s needed. Webpack supports that nicely. It\u2019s worth noting that using The synchronous cycle of operations on imported values and\/or function calls appear to be problematic. There are two symptoms I\u2019ve run into:<\/p>\n\n\n\n Imported value is undefined when it belongs to a cycle – it happens for both expressions and function definitions. Bear in mind that cycles can be of any size. The smallest cycle consists of two modules. Here are some simplified examples to make it easier to understand:.<\/p>\n\n\n RangeError: exceeding call stack – it happens when imports form a cycle of immediate synchronous function calls.<\/p>\n\n\n\n Function calls don\u2019t cause the problem when cycle is asynchronous meaning that directly referenced functions are not called immediately.<\/p>\n\n\n Two cases would be:<\/p>\n\n\n\n Cycle of function calls when one continues chain through a DOM event listener being async, i.e. waiting for user click.<\/p>\n\n\n\n Referring one class from another as long as the dependency is not necessary for immediate evaluation of class prototype – otherwise it fails as shown previously.<\/p>\n\n\n\n Let\u2019s find out where the circular dependencies are. For the analysis entire modules (files) are treated as indivisible units. Dependencies in a project can be represented as a directed graph where the beginning of an edge is the importing module (file where ES6 Module statements can be read and statically analyzed with analyze-es6-modules package<\/a>.<\/p>\n\n\n\n Let\u2019s start by adding the package to the project as a development dependency.<\/p>\n\n\n\n The next step includes necessary configuration which in our case is as follows:<\/p>\n\n\n\n You might need to adjust the config as:<\/p>\n\n\n\n The next step is to build an intermediary representation in which each import statement gets represented as an ordered pair. The set is used as it\u2019s a container holding only unique items.<\/p>\n\n\n\n Having collected all the unique ordered pairs, they can be thought of as edges of a directed graph. Hence all that is needed is to group edges by source node and the graph represented as a hash map will be ready.<\/p>\n\n\n\n At this point graph represents potentially all the module statements in the project. Most of them are not needed as they are not participating to any cycle. Hence can be removed from the graph as they are irrelevant to our analysis. Such edges share common characteristic \u2014 they are terminal on at least one end. When a module is not imported anywhere, it is a terminal node at the beginning of an edge. A terminal end node is a module that does not import anything.<\/p>\n\n\n\n The process of stripping terminal nodes can be repeated as long as the graph gets smaller.<\/p>\n\n\n\n At this point, the minimal graph has been identified, but it would be helpful to visualize it as it might be difficult to understand the cycles from a plain object representation. Simple way to do so is to represent the graph using dot language<\/a> and render with graphviz<\/a>.<\/p>\n\n\n\n Finally, the Printed text can be copied to an online renderer<\/a>. In our case the graph we got looked as below.<\/p>\n\n\n\n<\/p>ES6 Circular dependencies<\/h3>\n\n\n\n
const<\/code> over function<\/code> while defining functions prevents function hoisting within a single module and ensures the absence of circular dependencies within a single module.<\/p>\n\n\n\nWhat causes the problem?<\/h3>\n\n\n\n
It might appear that the import is undefined, but can also cause unexpected behavior due to the way undefined<\/code> is handled in JS, i.e. there might be NaN<\/code> instead of a number.
In our case it happened in unit tests first as the dependency tree is smaller and entry point is different than in the browser.<\/p>\n\n\n\n![\"synchronous](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2018\/06\/scheme-1-360x158.jpg\")
<\/figure><\/div>\n\n\n
Pic. 1. Synchronous cycle between A and B<\/em><\/p>\n\n\n\n\/\/ A.js\nimport B from '.\/B';\n\nexport default 3 + B;\n\n\/\/ B.js\nimport A from '.\/A';\n\nexport default 4 + A;\n\n\/\/ index.js\nimport A from '.\/A';\n\nconsole.log(A); \/\/ NaN (adding number to undefined)\n<\/pre>\n\n\n\n
\/\/ A.js\nimport B from '.\/B';\n\nexport default class A extends B {};\n\n\/\/ B.js\nimport A from '.\/A';\n\nexport default class B extends A {};\n\n\/\/ index.js\nimport A from '.\/A'; \/\/ TypeError: Super expression must either be null or a function, not undefined\n<\/pre>\n\n\n\n\/\/ A.js\nimport B from '.\/B';\n\nexport default () => 3 + B();\n\n\/\/ B.js\nimport A from '.\/A';\n\nexport default () => 4 + A();\n\n\/\/ index.js\nimport A from '.\/A';\n\nA(); \/\/ RangeError: Maximum call stack size exceeded\n<\/pre>\n\n\n\n
What doesn\u2019t cause the problem?<\/h3>\n\n\n\n
![\"partially](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2018\/06\/scheme-2-360x158.jpg\")
<\/figure><\/div>\n\n\n
Pic. 2. Partially asynchronous cycle between A and B<\/em><\/p>\n\n\n\n\/\/ A.js\nimport B from '.\/B';\n\nexport default () => {\n console.log('A called');\n document.addEventListener('click', B, false);\n};\n\n\/\/ B.js\nimport A from '.\/A';\n\nexport default () => {\n console.log('B called');\n A();\n};\n\n\/\/ index.js\nimport A from '.\/A';\n\nA(); \/\/ right away : A called, after click : B called, A called\n<\/pre>\n\n\n\n\/\/ A.js\nimport B from '.\/B';\n\nexport default class A {\n static getB() {\n return new B();\n }\n};\n\n\/\/ B.js\nimport A from '.\/A';\n\nexport default class B {\n constructor() {\n this.a = new A();\n }\n};\n\n\/\/ index.js\nimport A from '.\/A';\n\nconsole.log(A.getB().a); \/\/ instance of A\n<\/pre>\n\n\n\nDependency analysis<\/h2>\n\n\n\n
import<\/code> is used) and an end of it is the exporting module (file with export<\/code>). According to WolframAlpha<\/a>, A cyclic graph is a graph containing at least one graph cycle. A graph that is not cyclic is said to be acyclic (…) Cyclic graphs are not trees.<\/em> Dependency graph should be acyclic. Hence the term dependency tree<\/em>. Our goal is to identify cycles in the graph.<\/p>\n\n\n\nExtracting information about imports from code<\/h3>\n\n\n\n
yarn add analyze-es6-modules -D\n<\/pre>\n\n\n\n
const analyzeModules = require('analyze-es6-modules');\n\nconst configuration = {\n cwd: 'app\/assets\/javascripts',\n sources: ['**\/*.js'],\n babel: {\n plugins: [\n require('babel-plugin-syntax-jsx'),\n require('babel-plugin-syntax-flow'),\n require('babel-plugin-syntax-object-rest-spread'),\n ],\n },\n};\n\nconst resolvedHandler = ({ modules }) => {\n \/\/ do something with extracted modules\n};\n\nconst rejectedHandler = () => {\n console.log('rejected!');\n};\n\nanalyzeModules(configuration).then(resolvedHandler, rejectedHandler);\n<\/pre>\n\n\n\ncwd<\/code> is path to a directory holding all of JS sources (without node_modules<\/code>)sources<\/code> is a list of globbing patterns pointing to source filesbabel.plugins<\/code> is a list of babel plugins necessary to parse the files as non-standard syntax might be used. Safe option is to list all the packages that start with babel-plugin-syntax<\/code>. The list can be obtained from yarn.lock<\/code>.<\/p>\n\n\n\negrep '^babel-plugin-syntax' yarn.lock\n<\/pre>\n\n\n\n
const collectDependencies = (modules) => {\n const dependencySet = new Set();\n const separator = ',';\n\n modules.forEach(({ path, imports }) => {\n const importingPath = path;\n\n imports.forEach(({ exportingModule }) => {\n const exportingPath = exportingModule.resolved;\n const dependency = [importingPath, exportingPath].join(separator);\n\n dependencySet.add(dependency);\n });\n });\n\n return Array.from(dependencySet.values()).map(it => it.split(separator));\n};\n<\/pre>\n\n\n\nBuilding directed graph<\/h3>\n\n\n\n
const buildDirectedGraphFromEdges = (edges) => {\n return edges.reduce((graph, [sourceNode, targetNode]) => {\n graph[sourceNode] = graph[sourceNode] || new Set();\n graph[sourceNode].add(targetNode);\n\n return graph;\n }, {});\n};\n<\/pre>\n\n\n\nMinimizing graph to contain only cycles<\/h3>\n\n\n\n
const without = (firstSet, secondSet) => (\n new Set(Array.from(firstSet).filter(it => !secondSet.has(it)))\n);\n\nconst mergeSets = (sets) => {\n const sumSet = new Set();\n sets.forEach((set) => {\n Array.from(set.values()).forEach((value) => {\n sumSet.add(value);\n });\n });\n return sumSet;\n};\n\nconst stripTerminalNodes = (graph) => {\n const allSources = new Set(Object.keys(graph));\n const allTargets = mergeSets(Object.values(graph));\n\n const terminalSources = without(allSources, allTargets);\n const terminalTargets = without(allTargets, allSources);\n\n const newGraph = Object.entries(graph).reduce((smallerGraph, [source, targets]) => {\n if (!terminalSources.has(source)) {\n const nonTerminalTargets = without(targets, terminalTargets);\n\n if (nonTerminalTargets.size > 0) {\n smallerGraph[source] = nonTerminalTargets;\n }\n }\n\n return smallerGraph;\n }, {});\n\n return newGraph;\n};\n<\/pre>\n\n\n\nconst calculateGraphSize = (graph) => mergeSets(Object.values(graph)).size;\n\nconst miminizeGraph = (graph) => {\n const smallerGraph = stripTerminalNodes(graph);\n\n if (calculateGraphSize(smallerGraph) < calculateGraphSize(graph)) {\n return miminizeGraph(smallerGraph);\n } else {\n return smallerGraph;\n }\n};\n<\/pre>\n\n\n\nGraph visualization with DOT<\/h3>\n\n\n\n
const convertDirectedGraphToDot = (graph) => {\n const stringBuilder = [];\n\n stringBuilder.push('digraph G {');\n\n Object.entries(graph).forEach(([source, targetSet]) => {\n const targets = Array.from(targetSet);\n stringBuilder.push('\"' + source + '\" -> { \"' + targets.join('\" \"') + '\" }');\n });\n\n stringBuilder.push('}');\n\n return stringBuilder.join(\"\\n\");\n};\n<\/pre>\n\n\n\nresolvedHandler<\/code> is completed and looks as follows:<\/p>\n\n\n\nconst resolvedHandler = ({ modules }) => {\n const dependencies = collectDependencies(modules);\n const graph = buildDirectedGraphFromEdges(dependencies);\n const minimalGraph = miminizeGraph(graph);\n\n console.log(convertDirectedGraphToDot(minimalGraph));\n};\n<\/pre>\n\n\n\n