Алексей Уколов

Для реализации этой задачи хорошо подходит хранение в виде Nested Set. Хранение в виде Adjacency List подразумевает рекурсию и полную выборку.

Но самое простое решение в данном случае - просто закешировать отсортированную выборку, не меняя хранение, и резать для пагинации уже её.

Самое нормальное решение — через reduce, он для этого и существует. Но там технически есть второй массив.

arr.reduce((arr, n, i) => {
  if (n === 1) {
    arr.push(i);
  }

  return arr;
}, []);

Если использовать цепочку map + filter, там тоже, технически, используется промежуточный массив.

В чем смысл вашей задачи? Или это теоретическое упражнение?

https://ru.wikipedia.org/wiki/Конечный_автомат
iteye.ru/255/konechnyj-avtomat-dlya-parsinga-javascript

taligarsiel.com/Projects/howbrowserswork1.htm#Pars...

Эти ошибки, по сути, логические.
Значит, чтобы их не допускать, нужно следить за логикой и смыслом. Главные инструменты, которые могут в этом помочь - декомпозиция на небольшие фрагменты и осмысленное именование переменных и функций. Немудрено ошибиться, если у вас, например, три одинаковых вложенных цикла с переменными i, j и k.

2) В виде 2 столбцов (1 для ID пользователя и 1 для ID вида фрукта), и множества строк. Каждая строка будет означать наличие фрукта определённого вида.

Этот вариант гибче.
Первый вариант позволит очень эффективно разом выбирать данные обо всех фруктах пользователя, но при добавлении нового типа фруктов нужно будет править таблицу. А разницы в скорости работы этих вариантов вы, скорее всего, не заметите.
Поэтому, второй вариант предпочтительнее.

P.S. Оказывается, я невнимательно прочитал второй вариант. Конечно, его нужно заменить на то, что предлагает 27cm.

Похоже на правду.

Вообще, регулярные выражения не подходят для парсинга естественного языка.
Например, совершенно валидный с точки зрения языка текст

Иван, недавно переехавший в город N. спросил: «Как твои дела?» - и протянул однокласснице букет полевых цветов. Она смутилась и покраснела, но букет приняла. Смеркалось...

вы не разберете на предложения никакой регуляркой (и это я еще из Толстого пример не взял).
Поэтому вам сначала нужно составить формальный набор правил и ограничений, которому должен подчиняться ваш текст и только тогда мы сможем вам помочь составить под этот набор регулярное выражение.

Может быть можно как то элегантнее решить данную задачу?

Разумеется, можно. Достаточно понять, что вам нужно не строки таблицы сортировать, а данные. И уже данные потом рендерить.

Данные должны контролировать DOM, а не наоборот. Такой подход позволит не только существенно ускорить работу приложения (избавляемся от ненужных операций с DOM-элементами), но и сделает код более понятным и расширяемым.

Для этого можно использовать любой mvvm-фреймворк или написать все самому, если такая таблица одна, функционал ограничивается только сортировкой и по каким-то причинам не хочется использовать готовые инструменты.

Посмотрите, например, как просто, а главное понятно, ваша задача решается при помощи Backbone. Приложение разделено на слои и разбито на части, каждый слой и каждая часть занимаются своим делом. Само собой, это quick'n'dirty демо, там могут быть ошибки, так что не стоит использовать этот код в продакшене :)

Вы желаете странного, но учитывая, что на URL есть спецификация, то можно сказать что да, универсальный алгоритм разбора URL существует.