LinkedIn Skills: My Own Experience

Why That Fix Has A Second Half

The same thing, with eight skills and a page size of four

Line by line, in plain JavaScript

// The server has eight skills. The page size is four.
const server = ["A","B","C","D","E","F","G","H"];

// The browser asked for the first four and kept them.
let loaded = ["A","B","C","D"];
let bookmark = 4;              // where the NEXT request starts

// Now B is deleted. On the server, everyone after B moves up:
//   before   A B C D E F G H     E was at spot 4
//   after    A C D E F G H       E is at spot 3

loaded = loaded.filter((s) => s !== "B");
//   loaded is now ["A","C","D"], three instead of four,
//   and nobody touched the bookmark

// The next scroll fires and asks for four, starting at spot 4:
server.slice(bookmark, bookmark + 4);
//   → ["F","G","H"]
//   E is not in there, and it never will be. It sits at spot 3,
//   which the browser believes it has already read.

The fix is one line, and it is the whole lesson

function onDeleted(name) {
  const spot = loaded.indexOf(name);

  // Was the deleted row inside the part we already read?
  if (spot === -1) return;       // No. Our count is unaffected.

  loaded.splice(spot, 1);       // Yes. Drop it from our copy,
  bookmark -= 1;             // and move the bookmark back with it.
}

// bookmark is 3 now, so the next request returns:
//   ["E","F","G","H"]   nothing skipped

A list people can change wants the second one. If the first is already shipped, the deletion path has to keep the arithmetic honest by hand, and that is a thing to decide once, not in every handler that happens to remove a row.

A late response is not a valid response

// issued against spot 4; a delete landed while it was in flight
function onPageResponse(request, response) {
  const entry = cache[request.filter];

  // the bookmark moved while this was on its way, so this page
  // describes a list that no longer exists. writing it back
  // would put the deleted row on screen again.
  if (request.start !== entry.bookmark) return;

  append(entry, response.items);
}

Who Owns What, And What Changes When It Changes

The model, and the one field everything turns on

type Skill = {
  id: string;
  name: string;
  category: string;
  endorsements: number;
  priority: number;      // the user's rank. nothing else writes it
};

type SkillsUIState = {
  selectedCategory: string;   // never reconciled by a mutation
  editingSkillId: string | null;
};

// the filter is part of the identity, or two views share one slot
const key = ["skills", { category: "Frontend" }];

The mutation lifecycle, in six steps

Optimistic update vs refetch after success

The rank a new record gets

// Puts every new skill first, and quietly renumbers nothing,
// which is why it looks harmless until someone has an order.
const rank = Math.min(...ranks) - 1;

// Puts it last, and leaves every rank the user set alone.
const rank = Math.max(...ranks) + 1;