Задать вопрос
Контакты

Достижения

Все достижения (57)

Наибольший вклад в теги

Все теги (190)

Лучшие ответы пользователя

Все ответы (1791)
  • Создание SPA на wordpress?

    Kozack
    @Kozack Куратор тега JavaScript
    Thinking about a11y
    WordPress — система управления контентом. То есть, ключевая функция — это работа с БД, это предоставление интерфейса (читай админки) через который вы можете просто управлять контентом на сайте.

    SPA — архитектура для построения интерфейса. То есть это алгоритм по которому ваш контент как-то отображается.

    Совместить их достаточно просто. В общем и целом у вас должно быть две отдельные программы (на одном сервере, или на разных не столь важно)
    1. WordPress который будет управлять всем что связано с контентом. Создавать новые записи, рубрики, связывать их и тд.
    2. SPA, который просто будет принимать инфу от WordPress и как-то её отображать.


    Оба приложения могут работать абсолютно независимо. Вы можете сделать два разных SPA (например для десктопа и для мобильных) которые будут работать с одной и той же базон полученной от WP. И даже разработкой этих независимых систем могут заниматься разные люди.

    Вот статья на эту тему
    https://medium.com/@moustachedesign/creating-a-web...
    Ответ написан
    Комментировать
  • Что считается лучшей практикой для динамически созданных объектов?

    Kozack
    @Kozack Куратор тега JavaScript
    Thinking about a11y
    1) что считается лучшей практикой? Прописывать стили в объекте в скрипте (как в коде этого примера), или же всё таки назначать объекту класс (опять же через setAttribute()) и уже в файле style.css прописывать заранее эти стили?


    Проставляя стили по одному вы увеличиваете количество перерисовок. Не стоит так делать. Если нужно за один раз изменить несколько свойств то лучше использовать style.cssText. Но там есть свои особенности.

    Установка класса, выглядит более выгодной в этом плане. Но тут существует другая проблема: Если все ваши стили собираются в один большой бандл, Это означает, что эти вспомогательные классы и их свойства будут загружаться на клиент даже на тех страницах где они не используются.

    Кроме того, при изменении классов у родителя, браузер тратит больше ресурсов на анализ дочерних узлов, чем если бы у родителя изменились только стили. Так что выбирайте подход конкретно для своего случая.

    И как написали ранее, для управления классами есть специальный api

    2) Есть ли положительные моменты у того или иного способа , если к примеру использовать пример выше для создания формы, или к примеру создать форму в html заранее, просто с visibility: hidden, ну и собственно чтобы она появлялся по клику?


    Тут вы должны опираться на шаблон поведения пользователя на вашем сайте. Форма обязательна? Какова вероятность что пользователю она понадобится? Если форма не загрузится или не отобразится, сможет ли пользователь достичь своей цели на сайте?

    Проанализируйте эти вопросы. Изучите поведение пользователей. Определите приоритет этой формы. Чем он выше — тем раньше нужно её инициализировать:
    • Если пользователь 100% будет заполнять форму и не заполнив её он не сможет продолжить работу с сайтом, тогда форму стоит загрузить и инициализировать как можно раньше. Чтобы она была полностью готова когда она понадобится пользователю.
    • Если необходимость в форме мала, а не заполнив её сайт продолжит выполнять свою основную функцию — тогда загружать стили и скрипты, которые инициализируют форму можно только в момент когда форма понадобилась и не раньше.


    UPD.
    И на последок. Сперва нужно проставить все атрибуты, стили и тп, а уже в самом конце вставлять элемент в DOM. Иначе браузер будет выполнять перерисовку и перекомпоновку на каждый чих. Вместо того, чтобы сделать это один раз при вставке элемента.
    Ответ написан
  • Кому реально нужны правила по использованию cookie на сайте?

    Kozack
    @Kozack
    Thinking about a11y
    Большинство сайтов используют cookie, так сказать косвенно. Вот на пример, вы ведёте свой личный блог. В нем нет никаких форм, комментариев, ничего. Пользователи просто зашли, почитали и ушли. Ваш сайт не использует cookie. Но стоит вам поставить аналитику — и уже аналитика будет добавлять для каждого посетителя cookie.

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

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

    UPD
    Недавно законы в этом отношении несколько ужесточились. Большие мешающие просмотру плашки с вопросом "А можно мы будем использовать cookie?" это на самом деле не такая серёзная проблема. Куда серёзнее:
    1. Сайт не предлагает вам вариант НЕ разрешать слежение за собой. Он просто информирует. "Ты уже тут, и я уже всё о тебе знаю"
    2. Сайт предлагает вариант "Не следить" но лишь формально. Не зависимо от вашего выбора, cookie всё равно будут собираться и обрабатываться.
    3. При выборе варианта "Не следить" вас попросу не пускают на сайт. Потому что дешевле заблокировать вам просмотр, чем переделать сайт таким образом, чтобы он корректно работал без cookie.
    Ответ написан
    8 комментариев

Лучшие вопросы пользователя

Все вопросы (272)