1. Изоляция, как ее понимают стандарт и PostgreSQL (эта статья);
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Паттерн HOC (Higher Order Component) очень популярен у React-разработчиков. А вот Vue-разработчики его как-то обходят стороной. Очень зря. Попробуем разобраться в этом.

Перед вами вольный перевод статьи "10 Tips & Tricks to make you a better VueJS Developer" с сайта Dev.to. Автор расскажет нам об интересных и полезных вариантах применения привычных нам средств VueJS.

Введение

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

… или знакомство с плагинами Vue JS на примере интегрированной шины событий

Пара слов о…

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

Во Vuex есть одна популярная практика — не использовать mapState и mapMutations. Вообще. Вместо это мы сразу же при создании нового значения в store делаем для него геттер, а для каждой мутации – экшен.

Что-то наподобие:

export default new Vuex.Store({
  state: {
    // 1
    count: 0
  },
  getters: {
    // 1
    count: (state) => state.count
  },
  mutations: {
    // 2
    increment(state) {
      state.count++;
    }
  },
  actions: {
    // 2
    increment({ commit }) {
      commit('increment');
    }
  }
});

Холивара не избежать. Это уже доказала вот эта статья. Опять в интернете кто-то не прав, и я должен доказать почему. И я докажу.

1. Структурирование хранилища
2. Разделение хранилища на модули
3. Автоматический импорт модулей хранилища
4. Сброс состояния модуля
5. Глобальный сброс состояния модуля

Время идет, технологии растут, а разработка тяжела на перемены. Все больше и больше ресурсов зависят от API (но нет единых стандартов и решений). До сих пор популярен REST... Что бы сделать запрос на такой сервер, необходимо задать header (auth token), указать тип запроса, адрес, задать get параметры, указать параметры в теле и тип этого тела (json/multipart). Благо есть axios и fetch и они от части решают проблему с отправкой запросов. Время идет дальше и количество запросов - которые нужно отправлять растет, а код начинает превращаться в свалку копипасты. Иногда делают мини конструкторы или обертки. Большая же часть живет по старинке.

Эта часть кода начинает жить в хранилищах (Store). В дальнейшем я буду приводить примеры на основе Vuex (Vue Store), но в целом думаю это актуально и для React и Angular. Мы разгрузим Store и перенесем все запросы в Request Manager.

Когда нужно сделать код в проекте гибким и удобным, на помощь приходит разделение архитектуры на несколько слоев. Рассмотрим подробнее этот подход и альтернативы, а также поделимся рекомендациями, которые могут быть полезны как начинающим, так и опытным разработчикам Vue.js, React.js, Angular. 

В старые времена, когда JQuery только появился, а о фреймворках для серверных языков лишь читали в редких новостях, веб-приложения реализовывали целиком на серверных языках. Зачастую для этого использовали модель MVC (Model-View-Controller): контроллер (controller) принимал запросы, отвечал за бизнес-логику и модели (model) и передавал данные в представление (view), которое рисовало HTML. 

Объектно-ориентированное программирование (ООП) на тот момент только начинало формироваться, поэтому разработчики зачастую интуитивно решали, где и какой код надо писать. Таким образом, в мире разработки зародилось такое понятие, как «Божественные объекты», которые первоначально отвечали практически за всю работу отдельных частей системы. Например, если в системе была сущность «Пользователь», то разработчику следовало создать класс User и в нем писать всю логику, так или иначе связанную с пользователями. Без разбиения на какие-то ещё файлы. И если приложение было большим, то такой класс мог содержать тысячи строк кода.

Vuex — это официальная библиотека для управления состоянием приложений, разработанная специально для фреймворка Vue.js.

Vuex реализует паттерн управления состоянием, который служит централизованным хранилищем данных для всех компонентов приложения.

По мере роста приложения такое хранилище разрастается и данные приложения оказываются помещены в один большой объект.

Для решения этой проблемы во Vuex разделяют хранилище на модули. Каждый такой модуль может содержать собственное состояние, мутации, действия, геттеры и встроенные подмодули.

Работая над проектом CloudBlue Connect и создавая очередной модуль, мы поймали себя на мысли, что пишем один и тот же шаблонный код снова и снова, меняя лишь эндпоинт:

1. Репозиторий, в которой содержится логика взаимодействия с бекендом;
2. Модуль для Vuex, который работает с репозиторием;
3. Юнит-тесты для репозиториев и модулей.

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

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

Для этого мы создали фабрику типовых модулей Vuex, сократившую практически до нуля написание нового кода для взаимодействия с бекендом и хранилищем (стором).

В прошлой статье я рассказывал про основы JWT. Если на пальцах, то это просто ключ, с помощью которого мы открываем дверь к приватным ресурсам. А что, если этот ключ украдут (точнее, сделают дубликат). Тогда кто-то еще сможет входить на сервер под вашим именем, причём мы об этом можем даже не узнать. Такого сценария мы не хотим допустить. Но что делать?

Представляю вам мой довольно вольный перевод статьи 5 Easy Steps to Understanding JSON Web Tokens (JWT). В этой статье будет рассказано о том, что из себя представляют JSON Web Tokens (JWT) и с чем их едят. То есть какую роль они играют в проверке подлинности пользователя и обеспечении безопасности данных приложения.

В статье "Contemporary Front-end Architectures" рассмотрены архитектуры фронт-энда с точки зрения потоков данных в исторической ретроспективе.

Материал состоит из трех частей

1. Теория и история
2. Реализация

3. Перспективы

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».