Меня, бывает, спрашивают о том, как что-то реализовать, когда элементов очень много.<\/p>\n
Например:<\/p>\n
\nНа странице отображены 100 000 товаров и у каждого есть кнопки действий. Как указать обработчик событий для этих кнопок так, чтобы не множить функции? Постраничного листания нет, подгрузки при прокрутке тоже.<\/p>\n<\/blockquote>\n
или<\/p>\n
\nНа странице отображаются 5 000 товаров с партиями, остатками, необходимо изменять эти данные. Что бы вы стали делать, если бы страница стала тормозить? Как бы вы искали источник проблемы?<\/p>\n<\/blockquote>\n
Да никак бы я не искал источник проблемы. Потому, что источник уже найден — это вывод на экран тысяч экземпляров данных.<\/p>\n
В этом нет никакой необходимости. Никакой человек не может управлять данными, когда их тысячи. Нашему мозгу уже и 30 штук — довольно много. Правильное решение: сделать так, чтобы на фронтенде не отображались, не хранились, и не обрабатывались тысячи элементов. Тогда и не нужно будет решать эти надуманные задачи.<\/p>\n", "date_published": "2020-04-01T09:02:31+03:00", "date_modified": "2020-04-02T07:07:14+03:00", "_date_published_rfc2822": "Wed, 01 Apr 2020 09:02:31 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "83", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "1", "url": "https:\/\/www.blog.sergeykopylov.ru\/all\/pochemu-kastomiziruemy-interfeys-eto-ploho\/", "title": "Сколько нужно настроек в вашем продукте?", "content_html": "
Простой ответ: чем меньше, тем лучше.<\/p>\n
Есть давнее противостояние между Виндоус и МакОС. В Виндоус настроек больше и часто это считается свободой, а в МакОС — меньше, зато там дизайн лучше. То же самое с Андроидом и АйОС. И это неспроста.<\/p>\n
Дизайн лучше не когда он красивее, а когда лучше решает задачу. А это значит что дизайнер в эту задачу вникает вместо пользователя и с учётом своих знаний о проектировании, удобстве, распространённых ошибках, придумывает лучший способ решения и проверяет, вправду ли он хорош. Когда дизайнер работать не хочет, не хочет вникать в задачу, он придумывает настройки, чтобы эту задачу решил за него пользователь, и подаёт это под соусом «настраиваемого интерфейса».<\/p>\n
Когда времени на решение задачи мало, мало опыта или тяжело узнать, как на самом деле будет использоваться интерфейс, можно оставить какие-то настройки, но долг останется. А значит, нужно будет проследить за пользователем, узнать как он пользуется программой и оставить такой вариант, который пользователь выбирает, проанализировав, почему он так делает.<\/p>\n
Например, в системах управления данными всегда есть таблицы: список клиентов, документов, отчётов, счетов. В этих сущностях всегда много полей, десятки и сотни. Часто заказчик прямо требует возможности фильтровать по каждому из полей, и возможности выбирать, какие столбцы будут отображены вручную. Подобное решение понятно заказчику, потому, что контроль переходит к нему, но ужасно для неопытных пользователей (попробуй настрой, как тебе нужно, и пойми, как тебе нужно), трудоёмко (очень трудоёмко!) со стороны реализации, и является решением в общем виде, поэтому мало отличается от предоставления доступа к БД напрямую.<\/p>\n", "date_published": "2020-02-23T18:52:22+03:00", "date_modified": "2020-02-23T18:52:19+03:00", "_date_published_rfc2822": "Sun, 23 Feb 2020 18:52:22 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "1", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } } ], "_e2_version": 3559, "_e2_ua_string": "E2 (v3559; Aegea)" }