• Конструкция async/await в JavaScript: сильные стороны, подводные камни и особенности использования
    +2

    Там лямбда не асинхронная: id => await authorModel.fetch(id)

  • Code review: вы делаете это неправильно
    0
    Пример «Abort, Retry, Ignore?» — знакомо ?:)

    Опять же незачем это писать в каждой вьюшке. Всё это должно переиспользоваться по умолчанию.

  • Популярные антипаттерны: паджинация
    0

    В идеальном-то мире все думают наперёд, договариваются заранее, не косячат и не перекладывают друг на друга ответственность :-)


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


    Собственно, комментарии к этой статье весьма показательны. Думаю никто не пошёл к бизнесу уточнить "а устраивают ли вас вот эти вот особенности, предложенного нами ранее решения? Может нам всё переделать пока не поздно?". Это ж надо признать свою возможную неправоту, что сильно бьёт по самолюбию.


    Вместо этого, понеслось:


    1. Слили рейтинг статьи до рекордных значений.
    2. Слили автору карму, чтоб не мутил воду.
    3. Обозвали автора троллем, шизофреником и вообще дилетантом.
    4. Обвинили автора в NIH синдроме за то, что он рассказал про давно известное, но не столь популярное решение.
    5. Предложили несколько костылей, которые лишь частично решают некоторые из поставленных проблем в некоторых частных случаях.
    6. Усмотрели в предложенном решении кучу несуществующих недостатков.
    7. Отделались общими фразами про "для любого решения можно подобрать такие условия, где оно будет единственно возможным или совершенно не возможным".

    Представьте, что сейчас 1968 год, все пользуются goto, а тут Дейкстра пишет свою небезызвестную статью. Так и вижу комментарии:


    • Просто не прыгай через goto в циклы и никаких проблем.
    • Структурное программирование — это просто синтаксический сахар для goto.
    • Я каждый день с утра до вечера пилю конечные автоматы, ваше структурное программирование сделает мой код ещё менее читаемым.
    • Надо спрашивать у бизнеса до разработки должны ли мы использовать goto.

    Однако, спустя 50 лет, использование goto без крайней необходимости будет считается плохой практикой. Хотя он всё так же будет присутствовать в языках наших потомков:


  • Code review: вы делаете это неправильно
    0
    Он дизайнер, он так видит. И даже без неконсистенции очень хочется тот индикатор, который дизайнер нарисовал, а не какой-то системный дефолтный.

    Так и воткните его по дефолту, незачем его в каждой вьюшке копипастить.


    разные варианты продолжения работы показать

    Можно пример?

  • Конструкция async/await в JavaScript: сильные стороны, подводные камни и особенности использования
    +1
    Неправильный подход, вызовы будут выполнены последовательно
    const authors = _.map(
    authorIds,
    id => await authorModel.fetch(id));

    Этот код даже не запустится, ибо синтаксически нельзя использовать await в синхронных функциях. И вообще, что за _.map в 2k18?

  • Code review: вы делаете это неправильно
    0
    Откуда она знает надо показать надпись loading..., загрузка, прогресс-бар или спиннер?

    А зачем вам неконсистентность в представлении индикаторов ожидания?


    Уж молчу про обработку ошибок хотя бы по HTTP-статус коду.

    Этим занимается http-адаптер. Зачем вьюшке знать про http-коды?

  • Популярные антипаттерны: паджинация
    –1
    Пейджинг — это прием, который (как и многие другие) применим только в определенной ситуации.

    И эта ситуация — иммутабельная коллекция. По снепшоту тоже можно безопасно применять этот приём. Собственно создание снепшота — это и есть способ свести любую ситуацию к той, где можно применить пейджинг. Или не применять, если снепшот получается небольшой.

  • Популярные антипаттерны: паджинация
    0

    А вы пробовали объяснить бизнесу эти особенности? Я вот пробовал. Ответ был коротким:


    Меня не волнует где и почему вы накосячили. Исправляйте за свой счёт.
  • Популярные антипаттерны: паджинация
    –1

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

  • Популярные антипаттерны: паджинация
    0

    Разумеется, в этом редком кейсе, когда нам повезло и выборка никогда не меняется мы можем позволить себе не делать снепшоты. Это исключение из правила, а не аргумент в пользу отказа от него.

  • Популярные антипаттерны: паджинация
    0

    А вы принципиально не читаете мои ответы на те комментарии, ссылки на которые приводите? Что ж, я повторю:


    Метод не будет работать если пользователю важны последние записи.

    Когда пользователь перемещается между страницами его явно интересуют не последние записи, а "дай мне следующие 20 элементов". Самому пользователю ваша паджинация даром не нужна. Она — лишь техническая деталь, позволяющая показать пользователю большой список за разумное время. И пользователя интересует именно этот список, а не какая-то страница из него.


    При удалении записей которые есть в снепшоте вы получите НЛО или дырки.

    Я не вижу проблемы в том, что мы честно пишем, что "на момент запроса тут было сообщение, но к тому моменту как вы до него добрались оно уже было удалено, поэтому мы не можем показать вам его содержимое". И это гораздо лучше, чем "мы можем случайно не показать вам какие-то сообщение, а некоторые показать по нескольку раз, но мы вам об этом не сообщим" и неприятных скачков виртуального скролла из-за изменения состава выдачи.


    Снепшот, это по сути кэширование, со всеми вытекающими последствиями.

    Ошибка того же порядка, что и "человек произошёл от шимпанзе". У человека и шимпанзе общий предок, но частным случаем друг друга никто из них не является. Так вот, "снепшот" и "кеш" — это частные случаи "производных данных". Снепшот создаётся клиентом целенаправленно, чтобы с ним потом работать независимо от изменений в исходных данных. Вы можете создать сколько угодно снепшотов для одного и того же поискового запроса. Кеш же работает прозрачно между клиентом и исходными данными, не создавая отдельной сущности с которой можно оперировать. В то время как снепшот является иммутабельным со всеми вытекающими. С кешом у вас есть вечная проблема по его инвалидации. Пока он не инвалидировался вы получаете устаревшие данные. А как только инвалидировался — вы получаете изменение выборки со всеми описанными в статье проблемами. Так что нет, по сути это два совершенно различных механизма.


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


    Вы ограничиваете результат до 1000 записей, но это не всегда корректно.

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


    А ограничение на число элементов есть всегда. Я уже приводил в пример Гугл с его паджинатором. Да что там далеко ходить: https://habr.com/all/page101/

  • Популярные антипаттерны: паджинация
    0
    Если у нас всё же SPA, то разумно в урле хранить параметры фильтрации. Таким образом перезагрузка страницы приведёт к повторному запросу снепшота.

    Если же мы говорим про многостраничный сайт, то, очевидно, в результате поиска будет редирект на урл с идентификатором снепшота и номером страницы. Тут сколько ни перезагружай страницу — ничего не поменяется.
  • Популярные антипаттерны: паджинация
    0
    Расскажете по подробней про клиентов, которых устраивает что некоторые записи из выдачи они могут не получить, а некоторые получить по нескольку раз?
  • Популярные антипаттерны: паджинация
    0
    Если вы говорите о серверном хранении снепшота и постраничной навигации по нему, то очевидно навигация по одному из них не будет создавать новых.
  • Code review: вы делаете это неправильно
    0
    Да не надо ничего указывать. «Обёртка» сама вставит по необходимости. Там же типовой код.
  • Популярные антипаттерны: паджинация
    –2
    Извините, а снапшот раз в 10 секунд будет обновляться или как? Откуда я буду знать, что на данный момент смотрю на актуальные данные?

    Он создаётся каждый раз, когда вы инициируете новый поиск. В частности, при обновлении страницы.

  • Популярные антипаттерны: паджинация
    0
    зачем штамповать Снапшоты, если есть Кэширование?

    Отличительная особенность "кэша" в том, что он может быть в любой момент очищен, не ломая приложение. Кеш увеличивает производительность, но не несёт никакой бизнес-ценности. Если кеш у вас потухнет между 5 и 6 страницей, вы получите все описанные в статье проблемы. Если же вы сделаете большое время жизни кеша, то получите другую проблему — пользователь обновляет страницу в надежде получить актуальный список, а вы ему показываете устаревшие данные.

  • Популярные антипаттерны: паджинация
    –1
    оно не решает остальные поставленные вами проблемы

    Какие такие проблемы оно не решает?

  • Code review: вы делаете это неправильно
    0
    Да что в таком коде непонятного может быть?

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


    А запрос делать надо по любому, если взаимодействие с сервером требуется.

    Из компонента никаких запросов делать не надо — он сам сделается моделью по необходимости.


    Я обычно не делаю флаг загрузки, а проверяю состояние промиса.

    И проверять руками ничего не надо.

  • Вольный опус про найм, собеседования и трэш на рынке IT-кадров
    +2
    Справедливости ради, далеко не всякий, кто может хорошо программировать, сможет и хорошо проектировать. Это совершенно разные задачи, с совершенно разными приоритетами и требуемыми навыками. Так что рост программиста в архитекторы или менеджеры — это на самом деле не рост, а смена деятельности.

    Но если есть желание, то разумно действовать так: взять какую-нибудь боль и предложить архитектурное её решение. Если получится его продвинуть, то в резюме можно будет добавить галочку про улучшение архитектуры. Дальше уже в той же или в иной компании можно претендовать на позицию с большей ответственностью. Разумеется при этом нужно иметь ещё и неплохой кругозор в этой и в смежных областях.
  • Code review: вы делаете это неправильно
    0
    Так эвэйты, промисы или колбэки вместе с установкой флагов в коде присутствуют.

    Нет.


    То есть «криптокод» — это не сам код, а механизм реакций на изменения состояния.

    О чём я, собственно, и говорил — незнание идиом делает даже предельно простой код непонятным. Но это не проблема кода, это обычный пробел в знаниях, который надо заполнять.


    Куда проще-то?

    Без всего вот этого вот:


    установили флаг загрузки и начали запрос, по окончанию запроса записали данные и сбросили этот флаг. А в функции рендинга проверяем флаг — если установлен пишем «loading...»
  • Вольный опус про найм, собеседования и трэш на рынке IT-кадров
    +3
    Зачем же вы по 5 лет-то засиживаетесь на одном месте? Пока молодой и опыт набирается быстро — рост должен идти куда быстрее.
  • Code review: вы делаете это неправильно
    0
    Вот смотрит человек в код компонента, видит лишь пяток подобных геттеров, и недоумевает как же это всё работает без асик-эвэйтов, установки флага загрузки данных, навешивания обработчиков событий и прочих привычных вещей. «Да это криптокод какой-то!» — реальная цитата.
  • Code review: вы делаете это неправильно
    –2

    Ну как откуда. Заменяем this.article.author.name на "Alice" и вот уже никаких запросов, индикаторов загрузки, сообщений об ошибках и прочих "магических" вещах.

  • Популярные антипаттерны: паджинация
    0
    На сервере? Ресурсов-то хватит, удерживать снепшоты для всех клиентов?

    Придётся найти.


    как для клиента это будет отличаться от обычного пейджинга?

    Выдачу снепшота вы можете делать как пейджингом, так и стримингом. Даже если делаете пейджингом, то у вас будет два типа запросов:


    1. Сформируй снепшот по параметрам
    2. Дай такую-то страницу такого-то снепшота.
  • Популярные антипаттерны: паджинация
    –1
    ваше предположение "можно отдать всего не больше 1000 элементов" некорректно

    1000 — разумное ограничение для пользователя. Для разных запросов и клиентов вы вольны задавать любые ограничения.


    Что делать будем?

    Формировать снепшот и стримить данные из него любым удобным способом, ибо снепшот иммутабелен.

  • Общая картина модульного тестирования
    +1
    Ну типа того, да.
  • Популярные антипаттерны: паджинация
    0
    Нет.
  • Популярные антипаттерны: паджинация
    0

    Где же она по вашему возникает?

  • Популярные антипаттерны: паджинация
    0

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

  • Популярные антипаттерны: паджинация
    0
    По-вашему я должен решать все?

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


    Оба, предложенных мной решения, не костыли, а именно решения

    Если решаемая проблема остаётся, то это не решение.


    Если не рассматривать «сферическую паджинацию в ваккуме», то создание снепшотов умеет далеко не каждая БД, а для тех, кто умеет, это довольно дорогая операция.

    Снепшот — это просто список идентификаторов. В статье предлагается его сразу выгружать клиенту. Никакая поддержка со стороны СУБД тут не нужна.


    Даже постраничная паджинация имеет проблемы с производительностью по сравнению с относительной паджинацией.

    Об этом написано в статье.


    Зпрос для относительной паджинации почти вчегда будет быстрее запроса постраничной.

    Она применима только при сортировке по уникальному иммутабельному полю. Обычно это только id строки.

  • Популярные антипаттерны: паджинация
    0
    Сообщение не содержало слов «паджинация», а потом пользователь его отредактировал и оно стало содержать. Чем вам тут поможет since?
  • Популярные антипаттерны: паджинация
    0

    Сидеть на пятой странице и постоянно её обновлять? Очень сомнительно. Если разработчики не позаботились о создании нормальной ленты новостей (к сожалению, это массовая болезнь многих сайтов), то пользователю приходится сидеть исключительно на первой странице и постоянно дёргать её обновление.

  • Популярные антипаттерны: паджинация
    0
    единственный скриншот — пример пагинации гугла…

    Там не только Гугл, присмотритесь.


    фиксировать дату начала постраничной навигации конкретного пользователя, и игнорировать появление новых записей (статей)

    Вы таким образом лишь частично решили (отсекаются только новые сообщения, но не изменения старых) одну из проблем паджинации (изменение выборки в процессе листания) в довольно частном случае (сортировка по дате создания).


    где новые материалы появляются по несколько штук в каждую секунду…

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

  • Популярные антипаттерны: паджинация
    0

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

  • Популярные антипаттерны: паджинация
    0
    Есть предложение, что вы не можете решить те проблемы с тормозами в mol

    Я смотрю высокая скорость работы $mol вам спать спокойно не даёт?


    Некоторые, к примеру, сразу берут скролл и приблизительно проматывают длинное полотно, если вы понимаете о чем я.

    Ага, а потом наигранно удивляются, чего это браузер не может отрендерить всё это полотно мгновенно.


    Лег вечерком, поржал с 20 страничек старых мемчиков, выключил телефон, лег спать, а на следующую продолжил с той же страницы.

    Только за ночь напостили ещё контента, поэтому с 20 по 30 страницу идут одни бояны. Поэтому ленты новостей — это совершенно другая опера. Правильно реализуется двумя ручками:


    1. Дай топ свежих новостей.
    2. Пометь такие-то новости как прочитанные.

    Но об этом уже в другой статье.


    Нет, совсем не разумным)

    Обоснуйте. Даже если на один элемент пользователь потратит секунду, то на 1000 элементов ему потребуется пол часа, что запредельно много.


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

    Попробуйте в Гугле дойти до 100 страницы.

  • Популярные антипаттерны: паджинация
    0
    Есть два других решения проблемы того что данные перескакивают со страницы на страницу

    Я описал несколько проблем паджинации, почему вы пытаетесь решать только одну?


    Пользователь смотрит не с первой, а с наибольшей по номеру страницы.

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


    Если у данных есть уникальный монотонно возрастающий ключ (а id, как правило, такой и есть), то можно передавать не номер страницы, а последний просмотренный id

    Тот же костыль, но ещё и сортировка исключительно по id.

  • Популярные антипаттерны: паджинация
    +2
    Вы всегда читаете статьи вверх ногами и не дочитав до начала бросаетесь писать гневные комментарии?
  • Популярные антипаттерны: паджинация
    0
    Данная статья просветительская, а не инновационная. Данный подход «изобретён» не мной. Но, к сожалению, используется он куда реже чем следовало бы.
  • Общая картина модульного тестирования
    0
    И про то и про то в принципе.