A graph is just a set of vertices and the edges that connect them, but before you can run any algorithm on one, you have to decide how to store it in memory. The adjacency list is the representation you will use most often in this course: for every vertex, you keep a list (or array, or set) of the vertices it connects to. In JavaScript this usually looks like an object or a Map whose keys are vertex labels and whose values are arrays of neighbors.
The reason this representation matters is efficiency. An adjacency matrix stores a cell for every possible pair of vertices, which costs O(V^2) space no matter how few edges exist; an adjacency list costs roughly O(V + E), which is a huge win for sparse graphs such as road networks, social graphs, or dependency graphs. The trade-off is that checking "is there an edge from u to v?" requires scanning u's list instead of a single constant-time lookup, so neither representation is universally better.
As you watch, pay attention to three things. First, how the structure changes between directed and undirected graphs: in an undirected graph each edge appears twice, once in each endpoint's list. Second, how the authors count space and time, and which operations favor the list versus the matrix. Third, the mechanics of actually building the structure in code, so you can translate the Java or pseudocode you see into the JavaScript Graph class you will write later in this module.
A focused lecture segment that defines the adjacency-list representation of a graph G = (V, E) as an array of lists indexed by vertex, with each list holding that vertex's neighbors. Based on its framing, it should walk through how edges are recorded for a sample graph and discuss the storage requirements of the structure.
It gives the precise, textbook-style definition you need for "What Is an Adjacency List?" and "Space Complexity of the Adjacency List," from a course-lecture channel whose terminology matches standard data structures texts.
This follow-up lecture revisits the competing ways to represent a graph and compares them operation by operation, noting for example that an adjacency matrix affords direct access for an edge-existence check while an adjacency list does not. Expect discussion of which representation is faster for iterating over a vertex's neighbors versus testing a single edge, and how sparse and dense graphs change the answer.
It directly serves the "Adjacency List vs. Adjacency Matrix" and "When to Choose an Adjacency List" subtopics by framing the decision as a set of explicit trade-offs rather than a single right answer.
An implementation-oriented walkthrough that builds an adjacency list for an undirected graph in Java, showing how vertices are stored and how each edge is inserted into the lists of both endpoints. The video is part of a larger DSA series and uses animated slides alongside the code.
Seeing an undirected graph built edge by edge makes the directed-versus-undirected distinction concrete, and the code structure maps cleanly onto the JavaScript Graph class you are asked to write, even though the syntax is Java.
Together these videos build the representation knowledge the module depends on. The first establishes the adjacency list definition and its O(V + E) storage, and the second sets it against the adjacency matrix with explicit operation-by-operation trade-offs, which is exactly the comparison required by MO2. The third shows an undirected graph being constructed edge by edge, reinforcing the directed/undirected distinction in MO1 and giving you an implementation template to adapt for the JavaScript Graph class in MO4. Because BFS and DFS (MO3 and MO5) are normally run over an adjacency list, the fluency you gain here is a prerequisite for tracing and coding those traversals later in the module.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.