Этот блог работает на WordPress. Точнее его часть — админка. А фронтенд на nuxtjs. Когда-то я много работал с WordPress. Был даже модератором русскоязычного сообщества, делал темы и сайт на заказ. И вот что хочу сказать: панель управления WordPress была и остается одной из лучших. Знаете слоган у Эппл “это просто работает”. Так вот то же самое можно сказать про админку вордпресса. Кликаешь пару кнопок и всё, можно писать.
Но за такое удобство приходится платить. Размер базы растет как на дрожжах. Версионность и черновики штука хорошая, но некоторые вещи сохраняются избыточное количество раз. В каталоге с изображениями через некоторое время начинается хаос, через полгода-год туда вообще лучше не смотреть — непонятно используются ли загруженные картинки или уже нет. Плагины и темы тоже стоят отдельной дискуссии. За столько лет развития WordPress написано огромное количество плагинов. Часть из них уже давно стали платными и перешли на систему месячных подписок. В результате обновления от разработчиков приходят чуть ли не каждую неделю и следить за всем стало очень сложно. WordPress стал очень сложным продуктом.
Но сложными стали многие системы. Помню как лет десять назад раскладывал в директориях css и js и прогонял gulp-task, чтобы мои псевдокомпонентики склеивались в банды. Потом появился вебпак, react/vue и компоненты стали настоящими, не псевдо. Потом структура приложений и сервисов усложнялась и вот уже появляются различные архитектурные слои. Нельзя просто взять и, простите, наговнякать. Надо все разложить по полочкам, настроить вебпак, отрастить бороду. Усложнился и javascript. Вот менеджеры состояний, вот веб-сокеты, local first подход. В какой-то момент проектирование архитектуры пет-проектов стало такой, что пока все подготовишь, уже запал кончился. А список пакетов из npm, которые еще надо установить — нет. Не то, чтобы это прям плохо, это естественное развитие и взросление системы. Просто стало сложно следить и управлять всем этим.
Но я тут начал книжку про Ruby on Rails читать. И для закрепления знаний, конечно писать код. И знаете что? В мире есть место где можно говнякать. Что 10 лет назад, что сейчас. Хочешь свалить все стили в assets/stylesheets? Пожалуйста. Хочешь вмонстрить кусок скрипта прямо во вьюху? Не возбраняется. Тем более, что это местами очень даже удобно. И вот я раньше сильно плевался от подобного подхода. Но сейчас… Не то чтобы я стал сторонником, но если кусок скрипта нужен только на этой странице, то может быть проще вздохнуть и добавить его туда.
И вот пет-проект на рельсах, где можно немного отступить от привычных норм выглядит каким-то глотком свободы. Уверен, что развивая проект, со временем он тоже станет сложным и его придется делать архитектурно красивым и структурированным. Но вот сейчас, кажется, я до конца понимаю как вышло так, что Ruby on Rails стал таким популярным, почему каждый год все ждут когда же он помрёт. А DHH раз за разом выпускает новую версию и RoR всё ещё популярен.
Мне кажется потому, что это то самое место, где все ещё можно г… Гибко решать свои задачи. Ну вы поняли 😀
Решил разобраться в VIM. Вообще я часто пользуюсь им, для быстрого редактирования файлов. Этакая разовая работа. Но полноценно переключиться на работу с VIM у меня не получается. По умолчанию использую VS Code + VIM плагин. Получается неплохой симбиоз: удобные хоткеи VS Code + удобная навигация внутри файла. Но одно дело удалять строчки и прыгать туда-сюда по файлы, а другое дело полноценно работать с большим проектом.
Обычно многие статьи заканчиваются командами h, j, k, l. А дальше читайте официальную документацию, там всё подробно описано. А выйти-то как? А как отступ добавить?
Так вот, отступ в режиме NORMAL задаётся через двойное нажатие >. И тут вот какая проблема: статьи-то на самом деле хорошие, просто команд и сценариев так много, что всего не перечислишь. А еще есть куча разнообразных форков со своими доработками. Например, я пользовался LunarVim. В целом, было неплохо, но некоторые вещи долгое время не исправлялись. И вот однажды я полез искать как же поправить один баг и с удивлением обнаружил, что проект не развивается.
Решил попробовать Astronvim. Проект оказался поинтереснее: быстрее, более структурированнее. И как-то так увлекся настройкой (что-то добавил, что-то переназначил), что в итоге сделал свой форк.
В какой-то момент, устав читать документацию и статьи, я купил себе книжку Practical VIM. Сначала читал демо, потом еще раз читал демо. Понял, что очень понравилось. Простой английский, легкое повествование. Текст читается прекрасно. К слову, у меня есть ещё одна книга про VIM “Изучаем vi и VIM”. Так вот в этой книге я продвинулся всего на четыре главы. В общем, “Practical VIM” понравилась больше.
И вот к примеру пара цитат из книги:
The combination of operators with motions forms a kind of grammar. The first rule is simple: an action is composed from an operator followed by a motion. Learning new motions and operators is like learning the vocabulary of Vim. If we follow the simple grammar rules, we can express more ideas as our vocabulary grows. Neil, Drew. Practical Vim (pp. 24-25). Pragmatic Bookshelf. Kindle Edition.
и
when an operator command is invoked in duplicate, it acts upon the current line. So dd deletes the current line, while >> indents it. Neil, Drew. Practical Vim (p. 25). Pragmatic Bookshelf. Kindle Edition.
Ещё книга содержит много отсылок к документации. При желании можно пойти и узнать больше деталей. В общем, книга классная, рекомендую.
Что касается VIM и ежедневного его использования, могу сказать, что в процессе чтения книги снова появился живой интерес к использованию. Некоторые вещи уже не выглядят болью. Еще один важный момент — готовый настроенный конфиг. Возможно, когда-нибудь я попробую всё настроить с нуля. Но вот прямо сейчас хочется использовать то, что работает из коробки. Поэтому решения вроде AstroNvim хорошо подходят.
Пробовал несколько раз Helix Editor, но там слишком много хотекеев переделано по-своему. Ребята хотели сделать понятнее, а получилось запутанее. Потому что сложно переучиться на другие команды и хотекеи.
Вывода у статьи не будет. Скорее это просто чекпоинт на тему “вот узучаю VIM”.
Немного про разработку. Работал тут с Playwright. До этого писал тесты на Cypress. И после двух лет на Cypress кажется, что вдохнул свежего воздуха. При параллельном выполнении тестов Playwriter прогоняет их быстрее. А еще он запускает отдельный процесс для управления браузером, вместо выполнения тестов непосредственно в браузере.
В результате, переписал тесты к блогу на Playwriter и настроил Github Action.
Из интересного: для запуска тестов Nuxt + Playwriter нужно в playwright.config.js указать reuseExistingServer: true.
Сегодня узнал о способе отладки через git bisect. Работает это путем поиска по истории репозитория.
Допустим зарелизили в прод стопицот фич и что-то сломалось. Неделю назад работало, а теперь нет. Берем коммит недельной давности, когда точно все работало и переключаемся в него: git checkout <тот самый коммит>. Ставим метку git bisect start.
Проверяем, все ли работает и если да ставим метку: git bisect good. Далее git кидает нас на следующий коммит. Если все работает ставим good, если нет: git bisect bad. И так продолжаем искать с середины диапазона сужая поиск пока не останется один коммит.
Найдя коммит, где все сломалось, уже можно понять проблему. Для завершения поиска: git bisect reset. Эта штука сегодня сильно помогла мне найти проблему, так что я решил записать все, пока не забыл 🙂
У меня VS Code выглядит довольно аскетично. Простая белая тема, минимум настроек. Иногда переключаюсь на темную тему, но рано или поздно возвращаюсь к белой.
Примечание: Это статья — конспект моей лекции. В ней описываются ключевые понятия.
Обновление: В примерах ниже обновились url, в результате запросы по http не работают. Поэтому я внес небольшие корректировки и при получении url картинок заменяю http на https. Работающий код можно посмотреть тут https://codepen.io/denisfl/pen/xxeQzpp.
Чтобы взаимодействовать с сервером (запрашивать или отправлять данные), нам нужны методы. Каждый запрос, который мы отправляем на сервер, включает в себя endpoint и тип отправляемого запроса. Endpoint — это, своего рода, шлюз между клиентом и сервером. В зависимости от валидности запроса сервер отправляет ответ. Если запрос успешен, сервер возвращает данные, например, в формате JSON. В случае ошибки, сервер возвращает сообщение об ошибки. Ответы сервера обычно сопровождаются кодами состояния (status codes), которые помогают понять, что сервер пытается сказать при получении запроса.
Например: 200–299 — успешный запрос, 400–499 — ошибка клиента, 500–599 — ошибка сервера. Вот тут можно посмотреть полный список кодов: HTTP response status codes.
Методы для отправки HTTP-запросов
GET. С помощью него клиент запрашивает у сервера содержимое ресурса.
HEAD. Это метод для получения заголовков ресурса. Обычно применяется для получения метаданных и проверки менялся ли ресурс с момента последнего посещения и существует ли он.
POST. Через этот метод клиент может передать данные в теле сообщения. Это могут быть какие-то данные с заполненной формы. POST является неидемпотентным методом, то есть при его отправке результат может отличаться. Кроме того, ответы на него не будут кэшироваться.
OPTIONS. С помощью него можно запросить список методов, которые он или его ресурс поддерживает. Также OPTIONS можно использовать для того, чтобы «пропинговать» сервер — протестировать его работоспособность.
PUT. Метод создаёт новый ресурс или заменяет существующий данными, которые указаны в теле запроса.
PATCH. Работает таким же образом, как и PUT, только по отношению к части ресурса.
DELETE. Клиент сообщает о том, что хотел бы удалить некий ресурс.
TRACE. С помощью него можно проверить, изменяют ли промежуточные узлы в сети запрос клиента.
CONNECT. Запускает туннель между клиентом и сервером.
Как запросить данные
XMLHttpRequest. Это довольно старый метод, тем не менее он все еще используется.
Axios. Это клиент созданный на Промисах, был создан для удобства работы с HTTP-запросами.
axios.get('https://api.example.com/data')
.then(response=>console.log(response.data))
.catch(error=>console.error('Ошибка:',error));
Fetch API. Это функция JavaScript, которую можно использовать для отправки запроса на любой URL-адрес веб-API и получения ответа.
fetch('https://api.example.com/data')
.then(response=>response.json())
.then(data=>console.log(data))
.catch(error=>console.error('Ошибка:',error));
Fetch и Axios очень похожи по функциональности. Axios создавался в тот момент, когда Fetch API не поддерживалось в разных браузерах и нужно было обеспечить совместимость с Internet Explorer. Сейчас можно использовать и то и другое, в зависимости от того, с чем комфортнее работать.
Запросили, получили, показали
Обычно если мы что-то запросили с сервера через GET, мы хотим это показать. В самом простом случае, мы вставляем полученные данные в DOM. Тут мы не говорим о современных решениях для работы с Virtual DOM.
В JavaScript функции являются объектами, и они могут иметь доступ к своему лексическому окружению, включая переменные и другие функции, определенные в том же контексте. В нашем случае, функция fetchData – это асинхронная функция, которая создает свое собственное лексическое окружение, когда она вызывается. Это лексическое окружение включает в себя все переменные и функции, определенные внутри нее, а также доступ к внешнему контексту, где она была объявлена.
Внутри функции fetchData мы обращаемся к внешним переменным, таким как loadingMessage и container. Эти переменные были определены в том же контексте, где и функция fetchData, и, следовательно, они доступны ей как внешние переменные.
Функция fetchData использует доступ к DOM-элементам loadingMessage и container, чтобы изменять их содержимое и стили. Это возможно благодаря замыканию, которое сохраняет ссылку на лексическое окружение, в котором была определена функция fetchData.
Внутри цикла forEach создается замыкание для каждой итерации. Это происходит потому, что каждый раз, когда вызывается метод appendChild() или устанавливается свойство innerHTML, создается новая функция, которая сохраняет ссылку на лексическое окружение функции fetchData.
Таким образом, замыкания в JavaScript позволяют функциям сохранять доступ к внешним переменным и контексту, в котором они были определены, даже когда эти функции вызываются в других контекстах или в асинхронном коде.
В примере нижу функция fetchData и все переменные, которые она использует, организованы внутри объекта fetchDataObject. Все внутренние переменные функции, такие как loadingMessage и container, теперь доступны через ключевое слово this. Таким образом, объект fetchDataObject является замыканием, которое сохраняет доступ к своему лексическому окружению, включая переменные и методы.
_self.loadingMessage.textContent='Ошибка загрузки данных';// Используем _self для доступа к свойству loadingMessage
}
}
};
fetchDataObject.fetchData();
// Вызываем метод fetchData объекта fetchDataObject для загрузки данных
fetchDataObject.fetchData();
В примере с объектом fetchDataObject, мы используем this внутри объекта для доступа к его свойствам (this.loadingMessage, this.container) и методам. Здесь this указывает на сам объект fetchDataObject, поэтому мы можем обращаться к его свойствам и методам через this.
В то же время, в асинхронной функции fetchData, когда мы создаем переменные loadingMessage и container, мы получаем доступ к этим переменным, используя this, потому что в момент выполнения асинхронной функции контекст может измениться и this может потерять своё значение. Таким образом, мы сохраняем доступ к нужным нам переменным, используя их как свойства объекта this.
А теперь перепишем объект fetchDataObject, используя стрелочные функции.
Теперь функция fetchData не создает собственный контекст this, а вместо этого использует контекст объекта fetchDataObject. Мы также использовали деструктуризацию объекта внутри функции для получения доступа к свойствам loadingMessage и container.
