Рефакторит toc-text-crop.js

[Inventoris]

Привет!

Предлагаю чуть-чуть протюнить прекрасную функцию clipContent. Два главных апгрейда:

1. Функция изначально работает с длиной строк. Причём основную длину занимают пробелы. На мой взгляд, это не очень надежно, потому что если количество пробелов изменится, то и длина предложения тоже изменится, а значит оно будет обрезаться в другом месте.

Решение:

Считать сразу слова, а не символы. Выбрал максимум в 10 слов.

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

Решение:

Убрать лишний цикл. Сократил файл на 7 строк.

[solarrust]

Круто! Спасибо за оптимизацию! А что будет, если фраза будет что-то вроде «Фильдеперсовый Константинопольский шпалоукладчик звукоизвлекает сложносочинённые турбопропизоляционные ноктюрны»? Кажется, в этом случае в боковом меню будет слишком много текста и он даже может вывалиться за пределы контейнера. Смысл работы с символами был именно в том, чтобы контролировать длину подзаголовка без оглядки на длину слов.

[Inventoris]

Получится как-то так:

Но если серьезно, интернет говорит, что средняя длина слова в русском языке до 8-9 букв (деловая и научная литература). Я ради интереса вбил все вопросы из этого пиара и посчитал среднюю длину слова:

Я это всё к тому, что такие длинные слова в языке это что-то необычное, не уверен, что их можно принимать во внимание, т.к. могут ли они вообще встретиться? Вижу такие варианты:

1. Оставить всё как есть;
2. Добавить какую-то проверку к моему варианту, что если человек вбил слова со средней длинной в 14 букв, то немедленно прикрепить ему значок «словесный ловелас», а заодно укоротить предложение на несколько слов. Но не уверен, что тогда имеет смысл текущее сокращение кода;
3. Закрыть этот пиар.

[Inventoris]

Если важно считать именно символы, может, такой вариант имеет место быть?

То есть мы делаем массив и в цикле удаляем слова, пока длина не придёт в норму.

Плюс по сравнению с текущим вариантом в том, что мы используем очищенные от лишних пробелов данные, ну и если вдруг появятся турбопропизоляционные ноктюрны, то они не займут всё место. И на одну проверку с if меньше.

Минус в том, что второго цикла избежать не удаётся.

[solarrust]

Привет!
Интересная задачка, конечно =)

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

А давай ещё напишем тест на всё это? У нас новый тренд на 100% покрытие платформы тестами. Надо с чего-то начинать.
Тут может помочь советом @HellSquirrel .

[Inventoris]

Тест сделаю с удовольствием)

[Inventoris]

Добавил тест, но возникла небольшая проблема.

Чтобы проверить, как функция работает с DOM, добавил jsdom.
Чтобы jsdom работал, пришлось добавить полифилы и окружение
Чтобы окружение на TS заработало, пришлось добавить ts-jest , настроить конфиг jest и добавить jest.setup.ts

После этого всё работает, но смущает, норм ли такая история в рамках Доки вообще?) Не намудрил ли я лишнего?

Обсуждение, почему для jsdom нужно столько манипуляций: inrupt/solid-client-authn-js#1676

[Inventoris]

Кажется, так должно быть лучше.

[HellSquirrel]

Что касается правильного алгоритма... Может мы просто обрежем регуляркой максимум сколько-нибудь символов и потом то что получилось обрежем еще до первого пробела?

[HellSquirrel]

Я думаю добавить jsdom хорошая идея. Но раз уж мы его добавляем, давай делать это везде.
Давай перенесем это в jest.setup.js ?

[Inventoris]

Да, печальная картина.

Моя ветка безнадежно отстала от темпов современного мира, но скромная попытка ее обновить привела к неожиданному приклеиванию свежих комитов и дублированию моих.

Похоже, единственный путь для странника — начать всё по новой. Пересоздам заново?