В дочернем компоненте мы при нажатии на кнопку будем посылать сообщение в родительский компонент:

Теперь при клике на кнопку мы создадим специальный ивент, который вызовет коллбэк handleMessage из родительского компонента и передаст ему все данные, которые нам нужны 🙌

> К слову мы могли назвать ивент как хотим. Важно, чтобы первый аргумент в dispatch() и слово после on: совпадали.

Кастомные ивенты не всплывают, но если нам нужно, чтобы они всплывали, то у каждого дочернего компонента в иерархии нужно указывать `on:message`. Это довольно редкий кейс, однако подробнее можно узнать тут.

Биндинги существуют для того чтобы облегчать двухстороннее связывание 🥂

Двухстороннее связывание — техника, которую в основном применяют к инпутам. Она связывает value и событие oninput, таким образом чтобы пользовательский ввод все время обновлял value.

В Svelte это выглядит следующим образом:

{ inputValue }

Однако, все данные действия можно сделать намного проще с помощью инпутов:

{ inputValue }

Хуки — это методы, которые цепляются за жизненный цикл компонента🪝

В Svelte существует следующие хуки:

Обычно хук onMount используют для того, чтобы подтянуть какие-то данные со сторонних сервисов с помощью fetch и использовать их внутри компонента.

Если использовать SvelteKit (для рендеринга на стороне сервера) и расположить fetch внутри onMount, то данные будут запрашиваться на стороне клиента, а если просто внутри <script>, то запрос отправится еще на сервере.

Все фреймворки для создания веб-приложений работают следующим образом:

1. Сбор операций которые нужно выполнить пачкой

2. Подбор времени для выполнения

3. Оптимизация собраного стека

4. Выполнение этих операций (тик)

В Svelte тоже есть тики. Например, если мы используем специальный метод tick внутри хука beforeUpdate, то после выполнения мы уже будем находиться на ивенте afterUpdate:

Как уже понятно — мы можем объявлять состояния внутри компонентов. Однако бывают ситуации, когда нам нужно использовать глобальные состояния, при обновлении которых компоненты также будут обновляться (перерендериваться). Для этого сторы и придумали.

Самый простой стор, который можно придумать — счетчик, однако в сторы можно запихнуть и сложных структуры данных, тут стор используется для примера.

Допустим что у нас есть два разных компонента:

Мы можем объявлять счетчики вне компонентов в отдельных файлах JS/TS:

В данном компоненте мы будем управлять счетчиком:

В данном компоненте мы будем отрисовывать счетчик:

Счетчик: { count }

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

Чтобы не делать этого мы можем просто использовать стор добавив к его названию $ — $counter.

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

Если вам было интересно читать данную статью, то можете заглянуть ко мне телеграм, там собрано много всего интересного для веб-разработчиков.

Еще обязательно увидимся в следующих гайдах и туториалах ❤

TypeScript — язык программирования, представленный Microsoft в 2012 году и позиционируемый как средство разработки веб-приложений, расширяющее возможности JavaScript

TypeScript стал очень популярным проектом. Если ранее на нем писал преимущественно веб-приложения, то сейчас пишут даже логику для сайтов. Данный гайд затронет все основные темы TypeScript, статья достаточно большая, чтобы пройти её за одно чтение, так что советую сразу же добавить её в закладки, если захотите дочитать позже😊

Давайте поговорим о том, почему TypeScript вообще появился и почему так быстро стал популярен?🤔

Рассмотрим преимущества TypeScript:

Компиляция. TypeScript компилируется и проверяет ошибки. Это позволяет избежать некоторых ошибок ещё до проверки работоспособности самого решения! Если вы написали что-то не так, то TS сразу даст вам знать😊

Хорошая документация. TypeScript хорошо задокументирован. Чтобы вы не пытались найти, вы наверняка найдете это в официальной документации.

Полноценное ООП. Разработчики TypeScript смогли сделать то, что давно не могли сделать в JavaScript: сделать полноценное ООП с типами, интерфейсами, перечислениями и многим другим

Давайте плавно перейдем к обучению😊 Мы начнем с самого начала и закончим достаточно сложными темами, а по пути рассмотрим аспкеты данного ЯП, которые могут быть интересны многим😳

Спойлер: В статье очень много картинок. Если пользуетесь мобильным интернетом, то не тратьте лишний трафик и добавьте в \"Прочитать позже\"😉

Настоятельная рекомендация

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

Основным \"строительным материалом\" в TypeScript является тип. К слову TypeScript потому так и называется, потому что у него есть типы. Они созданы для того, чтобы заранее указать тип переменной и строго соблюдать его. В TypeScript есть встроенные типы, в основном мы будем пользоваться тремя: string, number, boolean. Мы будем разбирать все основы достаточно динамично, как минимум потому что в документации данные основы описаны более чем понятно. Те, кто уже знаком с JavaScript поймут код, так как он похож как две капли воды, единственное что может показаться необычным — то, что мы везде цепляем двоеточие с типом, но вскоре чувство инородности такой записи уйдет😊

Типы в TypeScript объявляются следующим синтаксисом

Мы можем присвоить любой тип, который есть в JavaScript:

Типы в TypeScript работают как и в любом строготипизированном языке. Если вы указали тип у переменной и присвоили ей несоответствующий тип, то компилятор выдаст ошибку и будет ругаться🤬

Как мы видим запись типов достаточно легкая. Такой подход позволяет явно указать тип переменной и строготипизировать её. Однако, TypeScript сам умеет определять типы. Если мы объявим переменную и сразу присвоим ей значение, то TypeScript все поймет и запись с двоеточием можно будет опустить:

Интересным фактом является то, что TypeScript, а точнее автодополнение, которое работает на tsserver (специальный сервер, который является LSP и будет давать вам подсказки по улучшению кода и автозавершению) будет ориентироваться именно на тип данных (кто бы мог подумать🗿). Именно поэтому например при попытке написать 123.toLowerCase(); вы не увидите никакой подсказки, а сам TypeScript подскажет вам, что вы что-то попутали👹 перепутали тип данных.

Вопрос: Но что если в моей переменной может быть значение одного из двух и более типов? Например, я присвою строку или число, но пока что не могу сказать что именно. Что делать?!

Ответ: На такой кейс придумано объединение типов😊

Типы можно объединять, сам процесс так и называется объединение. Записывается он так:

Такой подход позволяет присвоить значение, которое валидно для первого или второго перечисленного типа. Перечислений в свою очередь может быть сколь угодно много, главное чтобы вы ставили знак объединения множеств (|).

На данный код внизу компилятор не выдаст ошибку:

Минусом объединения является то, что TypeScript не даст нам использовать методы, которые например есть только у number, или только у string. Сам компилятор не будет знать что находится внутри переменной и будет жаловаться, что мы делаем что-то не то (пытаемся вызвать метод, которого нет у типа number | string).

Вопрос: Но как типизировать переменную, которая например содержит дату? Что нам с ней делать?!

Ответ: Для таких случаев в TypeScript уже существуют встроенные типы из JavaScript.

Мы можем объявить дату вот так:

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

Как это работает? Просто инициализируйте переменную, при инициализации TypeScript сам подберет нужный тип. Учтите, что при инициализации типа — тип в будущем просто так нельзя будет поменять (без спец. ключевых знаков и слов).

Тот же код, что и вверху. TypeScript сам найдет тип Date и присвоит его переменной🤩 Таким образом нам вообще ничего не нужно запоминать если типы заранее объявлены, то всю работу TypeScript сделает за нас😊

Отлично! Мы уже разобрали типы, объединение типов, встроенные типы и неявное объявление типов! Все самое интересное впереди😎

Вопрос: Мы научились типизировать переменные, но как типизировать функцию?

Ответ: Типизация функции построена точно также, как и типизация переменных. Мы просто указываем типы через двоеточие😊

Функции типизируются достаточно легко. Давайте подумаем, что такое функция?

Функция — блок кода, который принимает входные значения и отдает выходные значения. Часто она может ничего не принимать и что-то отдавать или наоборот принимать аргументы и ничего не отдавать вызывая коллбэки внутри себя.

В целом все что нам нужно понять, это то, что у функции почти всегда есть параметры и выходное значение😌

Соответственно, исходя из определения, над которым мы с вами только что подумали — нам нужно типизировать входные и данные и данные которые нам функция отдает (выходные).

Синтаксис достаточно легкий:

Давайте рассмотрим пример, где функция принимает два аргумента и отдает нам их сумму:

Как мы видим параметрами являются числа (два слагаемых) и выходным значением функции является сумма (тоже число).

Давайте немного разнообразим наш пример. Теперь функция будет принимать имя и количество его повторений и отдавать строку с повторяющимся именем:

Как мы видим, тут первый параметр - строка, второй - число и отдается строка. Все достаточно просто😊

Синтаксис для стрелочных функций нисколько не меняется. Просто теперь мы добавляем типы, вот и все😊

В TypeScript также есть два особенных типа, которые используются с функциями — void и never. Разберем их по очереди.

void — пустотный тип. Это тип, который используется для выходного значения функции, когда она ничего не возвращает.

Хороший вопрос: Зачем же нам указывать тип функции, если она ничего не возвращает?

Не менее хороший ответ😅: Все функции в JavaScript что-то возвращают ожидаете вы этого или нет..

Что я имею ввиду? Давайте выполним код в консоли:

Можно открыть консоль в DevTools, а можно зайти на https://jsconsole.com и попробовать поэксперементировать там. Не имеет значение, ведь JS ясное дело везде отработает одинаково👻

Звучит как бред бешеного, но давайте сравним выходное значение данной функции с undefined:

Собственно, это все что нам нужно было доказать.. Любая функция возвращает undefined, если у неё в return не передается никакого значения😳

Именно поэтому, когда мы ничего не возращаем в нашем методе, нам необходимо указать void, для того чтобы единственным возможным выходным значением было undefined😊

Теперь поговори о never. never - тип, который вообще ничего не отдает🗿🗿🗿

Если в void можно поместить undefined (можно даже вот так:)

То, тип never вообще не разрешает помещать в себя значения. Это полезно, когда метод один раз запустится и не завершится до окончания выполнения программы или если метод прерывает обычный флоу (кидает ошибку):

После того как мы поговорили о void и never, которые в основном предназначены для функций — неплохо бы поговорить о any, unknown, object, которые предназначены в основном для переменных😊

any — любой тип. То чего боится каждый TypeScript-разработчик.

Когда TypeScript разрабатывали, то перед разработчиками была определенная диллема: с одной стороны язык строготипизированый, с другой стороны другим разработчикам все ещё может понадобиться динамическая типизация для определенных целей. Ровно в этот момент и пришлось ввести any.

Переменная с типом any — это переменная, у которой включена динамическая типизация и для которой практически не действуют все преимущества TypeScript (ибо с такими переменными про проверку типов можно забыть), именно поэтому данного типа нужно избегать😉

Объявить переменную с any крайне легко. Достаточно просто объявить переменную и ничего в ней не инициализировать, при этом явно не указав тип:

Это конечно круто, но жутко небезопасно🥶 У такой переменной могут быть любые свойства и методы, что уж там, в этой переменной может твориться вообще черт знает что, может это вообще функциональное выражение внутри переменной, а может подключаемый модуль, кто знает?👺 Именно поэтому придумали более безопасный тип — unknown

unknown — неизвестный тип переменной, у которой нет свойств и методов (только из общего прототипа), однако её можно сравнивать логическими операторами. Когда дело касается чего-то неизвестного, что нужно только проверить только на существовование, то нужно использовать unknown:

object — ещё один интересный тип данных. Он предназначен для того чтобы дать не примитивный тип переменной.

Примитивными типами являются:

Все остальные типы являются нетривиальными и соответствуют типу object (не путайте с Object!!!):

Function — последний \"особенный\" тип, который представляет объект с методами bind, call, apply.

К слову, любая структура данных или функция в JavaScript является объектом.

В JavaScript функции являются объектами первого класса, то есть: они являются объектами и с ними можно взаимодействовать и передавать их точно так же как любой другой объект. Если быть точным, функции — это объекты Function.

Вопрос: Чем же отличается object и Function?

Ответ: Function отличается от object тем, что у объекта функции есть методы call, bind, apply😊

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

Допустим, что у нас есть вот такая простенькая верстка:

Наша цель примитивная до чертиков - считать инпут с id=\"fname\", как нам это сделать? Возьмем элемент по getElementById:

И.. У нас будет ошибка😔 Все потому что getElementById всегда возвращает нам тип HTMLElement, у которого в свою очередь нет свойства value🤨

К слову: getElementById, querySelector, querySelectorAll — всегда возвращают элемент из DOM-дерева с типом HTMLElement, потому что он является родителем всех других элементов

Для того чтобы компилятор не жаловался на инпут, нужно поменять тип у элемента на HTMLInputElement, но как это сделать? Для того чтобы поменять тип у переменной есть два типа записи:

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

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

Вопрос: Если у меня есть массив данных, как мне его записать с помощью типа?

Ответ: Для этого есть два варианта записи😊

Первый вариант записи является синтаксическим сахаром для второй. Вторая запись в свою очередь является дженериком😊 Ниже будет секция посвященная дженерикам👀

Мы можем явно не указывать типы данных, и тогда TypeScript сам найдет тип массива и присвоит его переменной:

Вопрос: Что же такое дженерики?🤔🗿Что делать, если я передаю аргумент с определенным типом и у меня должен быть выход с точно таким же типом

Ответ: Для таких случаев существуют обобщенные типы, это и есть дженерики😳

Давайте рассмотрим код, который берет аргумент одного типа и возвращает аргумент такого же типа:

В данном примере T и является нашим \"любым типом\". Главная прелесть дженериков в том, что мы отдаем значение с таким же типом, с каким были входные данные (хотя и не обязательно. Суть в том, что мы просто опирируем одинаковыми типами). И нам совсем не важно какого там типа входные данные.

Давайте напишем маленькую функцию. Она берет переменную с любым типом и отдает массив с таким же типом:

Вот мы и научились пользоваться дженериками🥳 Ничего сложного, достаточно просто запомнить, что они нужны, когда мы производим действия над сущностями с одинаковым типом😊

Также, стоит упомянуть про кортежи. Кортежи, это массивы фиксированной длины, которые можно использовать для разных целей:

Кортежи используются достаточно редко, однако они существуют как структура данных в JavaScript, их удобно типизировать в кастомных типах, которые мы рассмотрим в следующем разделе😊

Ещё мы должны рассмотреть перечисления🤔 Перечисления это структура которая используется (как не странно🗿) для перечисления свойств:

Можно представлять перечисления как массив, в котором пара \"ключ : свойство\" перевернуты — \"свойство: ключ\". По умолчанию все перечисления начинаются с нуля. Если бы мы в примере выше вывели DIRECTION.down, то выход был бы 1, DIRECTION.left — 2 и так далее. Все эти индексы можно задать и явно:

Однако, для перечислений также можно задавать и строки. Вот например перечисление с позициями:

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

Последняя тема, которую стоит обсудить в данном разделе многомерные массивы. Какой тип у данного массива?

Тип у данного объекта следующий:

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

Как мы видим создавать новые типы достаточно легко! Типы обычно создаются когда одни те же примитивы используются очень часто или когда нужно определенным типом обозначить определенную переменную.

Проведем интересный эксперимент🔬 Давайте объявим переменную и сразу же её инициализируем с объектом:

Если мы посмотрим на тип данной переменной в редакторе, то увидим следующее:

Интересно🤔 Давайте объявим тип с данными параметрами и попробуем задать его нашей переменной:

Это сработало!😊 Таким образом мы можем строго типизировать объекты😊

Кстати, если мы строго типизировали объект, то мы уже не сможем мутировать его😳 Мы не сможем добавлять в него новые свойства или методы, так как TypeScript вычислил тип во время иницилизации объекта🤔

Вопрос: А что если нам нужно добавить необязательный ключ к строго типизированному объекту?

Ответ: На этот вопрос есть решение — опциональные параметры.

Вопрос: А что если у меня есть специфический объект, где должны быть только строчные ключи и значения?

Ответ: Для этого можно использовать сигнатуру ключа.

Записывается сигнатура ключа следующим образом:

Приведем пример:

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

Интерфейсы — одна из ключевых фич в TypeScript, они позволяют круто типизировать классы, функции, объекты и все что только можно😊 Интерфейсы созданы для того чтобы давать разработчику удобный инструмент для типизации всего кода💫

По синтаксису они немного отличаются от типов:

Вопрос: Они отличаются от типов синтаксисом, а смыслом отличаются?

Ответ: Практически нет. Ранее типы использовались для одних кейсов, а интерфейсы — для других кейсов. Ныне это два очень похожих решения по типизизации структур данных, однако различия все же есть😊

Возможности, которые есть у интерфейсов, но нет у типов:

И всего-то?! 😅 Давайте рассмотрим сначала две данные фичи, а потом сравним как они реализованы у типов🤔

Если мы объявим два интерфейса с одинаковыми именами, то TypeScript автоматически \"сплюснет\" их в один:

Как мы видим два интерфейса с одинаковым именем стали одним целым. И теперь при использовании данного интерфейса TypeScript требует чтобы у объекта были свойства и из первого интерфейса и из второго одноименного😊 Удобно это или нет — решать вам. Я считаю что так легко можно запутаться, именно поэтому люди и придумали расширение😌

Расширением интерфейса называется процесс, когда один интерфейс поглощает все свойства родителя и добавляет свои:

Само расширение происходит следующим образом:

Вопрос: Это круто, что интерфейсы могут расширяться, но можно же расширить типы, верно?

Ответ: Можно, но никто так не делает, ибо это плохая практика😔

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

Вот пример расширения типа:

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

Вообще пересечение у типов работает немного странновато: так как два типа по сути являются подмножествами типа object, то пересечение у них полное (тоже самое что и object & object), а значит все свойства просто соединяются🤯

Проще всего объяснить пересечение и объединение на примере: Представьте, что у нас в двух комнатах есть собаки и кошки. Кошки мяукают, собаки гавкают. Если мы объединим их, то будут кошки или собаки. Так как мы теперь не знаем кто мяукает, а кто гавкает, то мы можем использовать только общие методы и свойства, например: ходить().

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

Кроме того некоторые правила у типов можно обойти с помощью объединения. Разработчик может ошибиться в операции, поставить по привычке | (оператор объединения), и тогда и вовсе второй объект станет валидным. Нам будет достаточно соответствия хотя бы с одним из типов (достаточно свойств из Person или Programmer):

При объединении и пересечении запомните простое правило:

Подумайте над небольшой задачкой, что получится, если пересечь object & Date, а если пересечь Number & String (именно конструкторы), будет ли у них что-то общее, если нет, то почему, ведь общие методы же есть (call, apply, bind)?🤔

Запись с типами кажется сложнее, требуется разглядывать код и разбираться в операторах сложения и умножения для множеств (и/или).

Совет: Старайтесь использовать интерфейсы, если дело касается объектов и сложных структур данных. Используейте типы для создания алиасов (вторых названий) для примитивных типов или для типизации функций.

Типизация функций, кстати у объектов выглядит не очень, а вот у типов вполне себе лаконично:

Запись типизации для функции в интерфейсе выглядит очень инородно🥶

Классы в JavaScript являются синтаксическим сахаром для создания объекта, об этом даже написано в документации MDN😳

TypeScript предоставляет нам все те же классы, однако с некоторыми улучшениями, а именно:

Пройдемся по порядку😊

Ранее в JavaScript мы объявляли свойства следующим образом:

В TypeScript это делается точно таким же способом, ничего нового, однако новизна начинается как только мы добавляем конструктор и поля только для чтения😊

Единственный аспект, который стоит учесть: в TypeScript все поля нужно указывать заранее, перед тем как использовать их в конструкторе. После того как мы рассмотрим следующую задачку на JS, мы сразу же сможем посмотреть реализацию на TS😊

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

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

TypeScript позволяет сделать следующее:

Таким образом благодаря ключевому слову readonly мы смогли сделать так, чтобы AGE нельзя было изменять вообще нигде. Если мы попытаемся изменить его внутри класса, то TypeScript тут же начнет ругаться.

Круто!😎 Мы познакомились с первым ключевым словом - readonly, а также узнали что поля в TypeScript надо указывать перед тем как инициализировать их в конструкторе. readonly, к слову ведет себя абсолютно идентично const. Мы можем мутировать объект (например массив), который инициазирован с readonly, однако, мы не можем заменить сам объект полностью (перетереть его).

Теперь давайте ещё больше усложним задачу: у нас будет два метода и одно свойство, которое мы применяем только внутри метода нашего класса:

Первые два будут публичные (методы, которые можно вызывать вне класса), а вот третий мы сделаем защищенным (protected). Вообще в TypeScript есть три модификатора:

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

Всего в TypeScript 3 модификатора доступа:

На счёт дочерних классов - не стоит беспокоиться. Мы разберем это понятие чуть позже, а пока забудьте, это не столь важно🤗

Реализовать это на JavaScript вполне возможно:

На TypeScript это реализовать ещё проще:

Синтаксис с private — намного приятнее, не правда ли?

Допустим, что у нас есть следующая задача: перегрузить конструктор, чтобы он принимал или одно значение (имя), или два значения (имя и возраст)

Давайте попробуем это сделать на JavaScript:

Кажется у нас неприятности.. Наш конструктор начинает расти... Кроме того я добавил гарды для входных значений (ну, а вдруг что?!). Можно было бы отделаться JSDoc вместо гардов, но это не самый лучший способ.. В будущем нам возможно нужно будет сделать определение имени через сеттеры, а не пихать все в конструктор, но по заданию мы должны сделать перегрузку. Так как JavaScript её не поддерживает, то приходится выкручиваться🙄

Теперь попробуем сделать то же самое на TypeScript:

Как мы видим, в начале мы объявили два конструктора без реализации. Это для того чтобы при перезгрузке TypeScript выводил правильные подсказки. Последний (третий) конструктор описывает уже саму реализацию. Проверяем мы только на наличие самого параметра😊

Замечательно, мы уже дошли до имплементации интерфейсов! Вы заметили как вырос наш класс? Уже немного сложно по нему ориентироваться и изменять что-то в нем, тем более в будущем мы создадим классы профессий, а они тоже будут изменяться🥶

Следить за всем этим адом из типов становится понемногу неприятно, поэтому давайте-ка быстро напишем интерфейс:

Я немного подчистил комменты и создал интерфейс, однако, тут невооруженным глазом заметно, что чего-то не хватает👁

Не хватает тут конструктора и приватных полей. Но почему?!

Чтобы объявить конструкторы вне класса и присвоить стартовые значения переменных, были созданы абстрактные классы. Абстрактные классы это своего рода прородители для классов. Весь синтаксис заключается в том, чтобы написать abstract рядом с классом, и в самом классе не реализовывать никакого функционала:

Вопрос: А чего мы добились таким разделением?

Ответ: Теперь каждый класс, который наследуется от APerson обязан инициализировать методы sayHello и sayGoodbye, мы также избавились от инициализации name, которая была в дочернем классе. Огромным плюсом также является то, что теперь все классы, которые наследуются от нашего абстрактного класса будут иметь схожую структуру. Хорошей практикой является объявлять все публичные методы именно в абстрактном классе😊

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

Стоит также упомянуть, что мы можем наследоваться и от обычного класса (расширяя его функционал), однако в обычном классе нам придётся переобъявлять методы, а тут мы просто инициализируем абстрактные методы, которые до этого не были реализованы😊

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

Мы просто добавили модификатор доступа внутрь аргументов конструктора. Таким образом конструктор может создавать поля автометически, больше ничего указывать не нужно😊

Теперь про дженерики😊 Дженерики как мы уже знаем созданы для того чтобы обощать тип, тут происходит то же самое:

Модули в TypeScript экспортируются с помощью нескольких способов:

Модули в CommonJS импортируются и экспортируются с помощью require и module.exports. CommonJS создан для Node.js и не поддерживается в браузере без специальных библиотек

Синтаксис достаточно простой:

Такие модули в основном используются для Node.js, а также Webpack. Они очень удобны для разделения модулей между файлами. Вам ничего не мешает экспортировать пару модулей в объекте.

Более того синтаксис в CommonJS один из самых простых в использовании, Node.js вообще использует его по умолчанию😊 CommonJS позволяет импортировать модули прямо внутри условий (что недоступно в некоторых системах загрузки модулей)

Можно экспортировать модули ещё более удобно без использования module.exports:

ES6 модули позволяют экспортировать и импортировать модули немного по-другому:

Также, ES6-модули позволяют экспортировать дефолтные модули - модули, которые будут отдавать по дефолту, если мы не укажем что именно экспортируем:

Данные модули можно использовать в браузере. Для этого достаточно импортировать все модули в ваш главный файлик (пусть будет main.js), а затем написать следующее в HTML-файле:

Ясное дело, что мы будем использовать не только свои модули в нашем приложении. Часто нам приходится работать с модулями из NPM. Но, что будет, если мы их импортируем?

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

Программа скомпилировалась, круто😎 Теперь давайте попробуем поработать с самим кодом:

Наш модуль импортировался, но у него тип any!!! Поддержка сторонних модулей в TypeScript что невозможна?! Никак нет😊 Нам нужно просто скачать расширение для нашего плагина, которое тоже начинается на @types. В данном случае @types/ws. Установили и... Опять та же беда(((

Однако, если мы используем немного другую запись (ES6-модули), то все заработает:

Вот и все мы рассмотрели основные аспекты данного ЯП. В будущем будет ещё одна статья, но уже поменьше😅 про конфигурацию проектов и файлы декларации, где мы уже будем смотреть на примере проекта как правильно и красиво настроить файлы с типами в TypeScript😊

Если вам было интересно читать данную статью, то вы можете перейти на мой канал в телеге, там много всего интересного!😳 Приятно было рассказать об этом прекрасном ЯП, в будущем ещё не раз увидимся😊

webpack — это сборщик модулей JavaScript с открытым исходным кодом. Он создан в первую очередь для JavaScript, но может преобразовывать внешние ресурсы, такие как HTML, CSS и изображения, если включены соответствующие загрузчики. webpack принимает модули с зависимостями и генерирует статические ресурсы, представляющие эти модули.

В данной статье полностью разберем как работать с данной утилитой для сборки всего на свете в один файл: пройдемся по концептам и закончим реальным использованием с TypeScript и модулями из node_modules, чтобы заставить код работать в браузере😊

Какую проблему решает Webpack

Webpack решает проблему вечного подключения библиотек и фреймворков к HTML. В каком порядке их подключать, как решать конфликты, как сразу же оптимизировать картинки, как включать css в JavaScript, подобно тому, как это делается в React? Всеми этими вопросами занимается Webpack👍

Webpack — статический сборщик модулей. Это значит что после компиляции у вас будет один файлик в котором все зависимости будут в правильном порядке, а все ассеты и стили будут зашиты в один файл.У самого WebPack есть несколько основных терминов:

Сам конфигурационный файл всегда один — webpack.config.js. В нем мы указываем экспортируемый объект, которй и является конфигурацией для Webpack:

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

Бывают случаи, когда вам требуется несколько конфигурационных файлов (для продакшена и разработки), тогда нам следует создать следующие файлы:

Названия файлов могут быть любые, это не стандарт, однако, внегласно принято называть их именно так😊

В package.json нужно просто указать команды для сборки, чтобы Webpack знал какую конфигурацию ему таскать:

А куда делся webpack.config.js?!

Мы его в данном случае просто не используем Если мы просто запустим Webpack безо всяких флагов, то он будет искать именно webpack.config.js, однако если мы дали точное имя конфигурации, то он не будет ничего искать и просто сжует👄 данную конфигурацию и будет работать по ней👀

Сам Webpack строит граф (дерево, в случае если входной файл - один) зависимостей. Он проходится по всем импортам внутри ваших файлов, строит граф, а затем начинает импортировать все прямо в финальный файл.

Входная точка 🔴 - файл, с которого Webpack начнет построение этого графа. Это файл, который нам нужно включить первым и от которого будут идти все импорты.

Обычно данный файл является ./src/index.js, однако данную входную точку конечно же можно поменять:

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

Не секрет, что Webpack отдает нам один файл (спойлер: можно настроить так, чтобы отдавал несколько, но не суть сейчас). Именно этим \"одним файлом\" и является точка выхода 📤

По умолчанию этот файл находится в ./dist/main.js, однако вы можете также поменять это с помощью конфигурации:

Хороший вопрос: почему бы нам просто не указать имя точки выхода и на этом все. Зачем этот path, зачем разделять имя файла от пути?

Не менее хороший ответ😁: Webpack может упаковывать все что угодно, даже картинки формата png. Сами картинки он как не странно в код не запихнет, однако он перенесет их. Для переноса ему нужен точный путь к директории, где будет точка выхода, чтобы построить правильный путь. Имя файла и путь мы разделяем именно поэтому.

Из коробки Webpack понимает только JavaScript и JSON, что будет если мы попытаемся запихнуть внутрь cjs, ejs, html, typescript? Ничего, Webpack отдаст нам ошибку. Для таких вещей придумали лоадеры😊

Лоадеры 📂 — специальные модули, которые созданы для того, чтобы считывать и обрабатывать файлы. Для лоадеров в свою очередь придумали правила.

Правила 📏 — это в свою очередь просто объекты в конфигурации, которые указывают на файлы, которые нужно обработать и указывают лоадер

Все лоадеры указываются в конфигурации следующим образом:

Как можно увидеть есть свойство module, которое содержит в себе правила, массив rules в свою очередь уже содержит сами правила: в него включаются правила в виде объекта, где test - путь в виде Regex, use - сам лоадер, который должен быть использован.

Стоит уточнить, что перед тем как использовать лоадеры — их надо найти и скачать с помощью NPM😳

Существует очень много лоадеров, от CSS и Sass до png и svg, рассмотрим их чуть позже в практическом примере😊

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

Плагины🔌 — внешние модули для Webpack, которые позволяют управлять и обрабатывать файлы, которые не импортируются в JavaScript

Рассмотрим легенький пример, где мы будем импортировать index.html, это позволит не держать его в директории dist (то есть саму директорию можно будет удалять и ничего не потеряем), а также вставлять внутрь переменные окружения и пути к файлам.

Вот как это будет выглядеть в конфигурации (для упрощения часть кода с входной и выходной точкой - пропущена):

Как мы можем увидеть тут мы используем плагин html-webpack-plugin для того чтобы обрабывать HTML. В данном случае он просто перенесет файл из ./src в ./dist 😊

У Webpack есть три режима (на самом деле два, но один из трёх является отсутсвием любого режима). По умолчанию без конфигурации у Webpack нет режима — none. Если мы напишем конфигурацию, то Webpack настоятельно посоветует (с вот таким лицом: 😠) добавить режим.

Делается это проще простого:

Всего у Webpack (по-настоящему) существуют два режима:

Замечательно, вот мы и прорвались с основ к более продвинутому использованию🤩 Покрыть одной статьей асболютно все кейсы использования просто напросто невозможно, тут дело ограничивается только вашим воображением и условиями, при которых вам потребуется Webpack, однако пройтись по основным все же стоит😊

И по новой..♻ Снова пройдемся по всем концептам, только уже с более продвинутыми конфигурациями😳 Допустим, что у вас есть несколько файлов, которые сами по себе являются входными точками. Часто для сайтов например указывают следующие файлы:

Что будем делать в таком случае? Не придётся же мерджить два файла?!😱

Мы можем разделять файлы на две и более входных точки. Мы можем компилировать их в отдельные точки выхода, а также в один.С помощью данной конфигурации можно указать входные файлы:

Мы также можем передать в entry не объект с названиями файлов, а массив:

Это хорошо, но как нам понять куда будут собираться данные исходники?🤔

В webpack.config.js указываем следующее:

[name] — в данном случае имя входного файла Данная строка является шаблонной (не в привычном понимании JavaScript), ибо внутри квадратных скобок мы указываем шаблон наименования. Все шаблоны можно посмотреть вот тут

Одним из полезных свойств является [contenthash]. Он используется в основном для продакшена, чтобы каждый раз при компиляции создавался новый хэш (хэш создается по контенту в файле, так что если файл изменился, то хэш будет новый💫). Данное свойство активно используется для обхода кэширования файлов в браузерах. Дело в том, что браузер не будет грузить все ваши файлы с одним и тем же названием каждый раз, как вы переходите на сайт, ибо это очень долго и влияет на время загрузки, даже если файлы поменялись. Проблема решается \"в лоб\", если так можно сказать😅 — мы просто меняем название файла, если он сам изменился.

А вдруг хочется один выходной файл, что делать тогда?!

Ответ на этот вопрос очень легкий😅 Просто включите файлы, которые вам нужны в одном бандле в main.js. Тот же vendors.js можно включить внутрь main.js и все😳

Точки выхода мы пропустим, так как я думаю мы уже обсудили их выше достаточно😊

Лоадеры в свою очередь могут таскать больше чем просто файлики .txt, естественно. Они используются для той же компиляции TypeScript:

Важно: Помните, что перед тем как использовать лоадер - его нужно установить🚧

А что если с файлом определенного типа нужно провести не одну операцию?🤔

Допустим у нас есть задачка: мы хотим процессить CSS-файлы с помощью SASS, а также включать их в JavaScript. Реализация у данной идеи будет следующая:

Как мы видим, мы можем указывать несколько лоадеров для одного типа файла, помещая все лоадеры в массив. Все лоадеры будут выполняться последовательно.

Для плагинов последовательности и сам процессинг работает точно также😊

То, о чем мы ещё не поговорили - цели😳

JavaScript ныне работает как на клиентской стороне, так и на стороне сервера.

Мы можем создавать множественные цели, чтобы решать такие проблемы:

Однако опыт показывает что так делать не всегда удобно, а иногда и вовсе нежелательно🤔 Держать все конфигурации в одном файле - нехорошая идея, лучше создать две директории и два независимых webpack.config.js.

А что же на счёт target? Данное свойство указывает цель для чего мы создаем бандл, это может быть:

Мы можем кэшировать неизменные части нашего приложения, для того чтобы Webpack быстрее собирал наше приложение😌

По умолчанию файлы кэшируются в памяти в mode: development и не кэшируются вовсе, если mode: production🤔

Для того чтобы Webpack кэшировал все не в оперативной памяти, а в постоянной — достаточно просто указать следующее свойство:

Webpack будет кэшировать билд в node_modules/.cache/webpack и автоматом пропускать то, что не изменилось!😱

Директорию для кэша можно изменить с помощью cacheDirectory:

Для того чтобы отключить кэш вовсе достаточно просто добавить cache: false, интересным замечанием будет то, что cache: true — то же самое, что и cache: {type: 'memory'} 😉

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

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

Если случилось так, что вы работаете с pnpm, который берёт модули из ссылок (то есть он не создает все время node_modules, а скачивает модули только один раз), то вам понадобится следующее свойство:

Webpack ещё и умеет запускать свой http-сервер, для того чтобы у вас была live-reload (перезагрузка при рекомпиляции)🌈

Для того чтобы заставить🔫 Webpack использовать devServer, достаточно просто указать следующие свойства в конфигурации:

Мы также можем настроить Webpack так, чтобы он показывал нам ошибки, если вдруг что-то пошло не так, прогресс-бар при компиляции:

У самого сервера есть безграничные возможности: от поддержки Hot Module Replacement до поддержки WS-сервера и HTTPS соединения, все их можно посмотреть здесь😊

Как и обещал разберем пример😊

Постановка задачи: Написать конфигурацию для TypeScript с подтягиванием файлов [.ts, .tsx, .js], картами для исходников.

Задачу поставили, выполняем😇

На этом можем завершать статью🥳 Мы научились пользоваться Webpack'ом, а также рассмотрели некоторые аспекты, которые позволят нам использовать его ещё эффективнее. Если вам понравилась статья, то вы можете перейти в мой канал, там ещё много всего интересного😉 Ещё увидимся!

Сегодня поговорим о том как работает WS, напишем простенький клиент на JS, обсудим как дебажить данный протокол ну и просто обсудим несколько интересных фактов. Погнали😈

Для начала стоит начать с того что такое HTTP?

HTTP - Протокол для передачи гипертесктовых данных (Hyper Text Transfer Protocol), который используется повсеместно. HTTP используется в клиент-серверной архитектуре, там всю работу можно показать с помощью одной диаграммы:

Существует большое количество сайтов, с помощью которых вы можете посмотреть как работает HTTP, давайте возьмем забавный сайт с REST API по мультивселенной Рик и Морти — https://rickandmortyapi.com/documentation.

Вы можете отправить запрос с помощью Postman или обычного cURL, я буду использовать второй😊 Давайте возьмем информацию о персонаже (Рике) и посмотрим что нам пришлёт сервер, для этого используем данную ссылку: https://rickandmortyapi.com/api/character/1

После данной команды мы получим следующий ответ. Как мы видим мы просто отправили запрос на получение информации с сервера (GET), сервер отдал нам информацию и после этого мы разрываем соединение. После того как мы получим ответ мы ничего не знаем о сервере👀

AJAX - асинхронные запросы с помощью JavaScript (Asynchonous JavaScript and XML). AJAX преследует все те же цели, что и HTTP, только делает это уже асинхронно. Если ранее нужно было для каждого запроса прописывать свой URL и перезагружать страницу, то теперь можно просто использовать AJAX и он сам будет отправлять нужные URL серверу и получать данные.

Самым простым примером AJAX является следующая реализация:

Вот что мы получим в итоге:

Мы можем выполнить множество таких запросов (серьзено, хоть 1000, если сервер позволит), как мы можем увидить мы ничего не перезагружаем (нам даже перезагружать нечего😅, мы делаем все на бэк-энде Node.js)

Как мы можем увидеть, мы все ещё не держим связь с сервером. Мы отправили запрос, получили ответ и все😳 Что дальше происходит с сервером нам неизвестно.

WebSocket - протокол для общения между клиентом и сервером, предоставляющий двухсторонне общение сверх протокола TCP.

Мы подключаем WS один раз, а затем сервер может отдавать нам ответы тогда, когда посчитает нужным:

Первое что мы делаем — отправляем обычный TCP-запрос на сервер, мы говорим, что хотим подключиться к серверу и ждём от него ответа. Такой процесс называется “рукопожатие” (Handshake), он используется повсеместно, например когда вы подключаетесь к роутеру ваш телефон отправляем запрос роутеру с ключами, роутер отвечает ОК и вы успешно подключаетесь.

Затем происходит обмен данными: допустим один из множества клиентов отправил HTTP-запрос серверу и нужно отдать ответ не только одному клиенту, а целой сети! Сервер в таком случае отдаст обычный ответ отправителю запроса, а всем другим пришлёт пакеты по WebSocket-соединению с полезными данными.

Разберем более подробно на примере. Вы — клиент, отправляете запрос серверу на подключение. Запрос и ответ будут выглядеть примерно так👁:

Как мы видим сервер ответил не кодом 200 (успешное завершение запроса), а 101 — переключение протоколов. Это происходит потому, что мы отправили HTTP запрос, а хотим получить не только HTTP-ответ, а ещё и другие ответы по WS, сервер как бы предупреждает клиент, что будет присылать ответы множество раз🔙

Ответ на данный вопрос достаточно легкий — сервер и клиент играют в пинг-понг😁🏓😳

Сервер периодически присылает ответ по WS с просьбой о действии - послать запрос на сервер. Если клиент отвечает до истечения тайм-аута — он подключен, если нет, то происходит разрыв соединения до следующего рукопожатия👋

Полезно знать, что все ответы от сервера по WS игнорируются клиентом и сервером, до того как случится рукопожатие🤝

На самом деле мы не только получаем ответы от сервера, а ещё и можем в двухстороннем порядке отправлять через WS запросы!😳

Чтобы лучше понять, давайте рассмотрим лёгенький и полностью задокументированный код на JavaScript:

После того как мы открыли соединение по WS мы сразу же можем отправить сообщение серверу:

Сервер получит данный запрос и возможно захочет ответить, но мы не сможем прочитать ответ! Почему? Да просто потому что у нас нет слушателя на событие получения сообщения от сервера😊 Сделаем же его:

Для закрытия соединения мы должны отправить запрос серверу, а он по истечению таймаута тоже должен отправить ответ на подтверждение закрытия. В JavaScript это делается одним методом😌

Отлаживать WS-соединение совсем несложно😊 Рассмотрим пример отладки WS на Google Chrome🌎, перейдем на данный сайт: https://websocketstest.com/

Откроем DevTools, выберем вкладку Networks и перейдем в таб WS:

Как мы видим ответ от сервера действительно 101 Switching Protocols, однако как нам увидеть данные, которые приходят по WS, вкладки Reponse же нет🤔

Вкладки Response нет, зато появилась новая - Messages. Открываем её и видим там примерно следующее:

Красной стрелкой вниз показаны пакеты, которые пришли нам (пусть вас не вводит в заблуждение красная стрелка, это не упавшие, а пришедшие пакеты), отправленные пакеты в свою очередь будут показаны зелёной стрелкой, которая стремится вверх⬆

Вот и все😊 Если вам было интересно читать статью и вы хотите больше такого контента, то можете перейти в телеграм-канал и подписаться, там много интересного материала✨ Был рад поделиться информацией, увидимся ещё не раз☺

zsh — одна из современных командных оболочек UNIX, использующаяся непосредственно как интерактивная оболочка, либо как скриптовый интерпретатор. Zsh является расширенным аналогом, а также имеет обратную совместимость с bourne shell, имея большое количество улучшений.

Иметь красивый и удобный шелл для человека, который ведет разработку в терминале или просто пользуется им 90% рабочего времени — дело хорошее, ещё лучше если этот шелл хорошо настроен, не подлагивает в больших репозиториях git и предоставляет удобные алиасы, этим сегодня и займемся😊

В результате всех взаимодействий у нас выйдет такой шелл:

Можно конечно копировать все репозитории ручками, однако, если вы перейдете с одной системы на другую, то вам придётся хранить список репозиториев, которые нужно подкинуть себе😳 Это крайне неудобно, да и на дворе 22-й год, поэтому давайте разберемся в том, какие менеджеры плагинов есть у zsh:

Поговорим о каждом из них чуть подробнее:

antigen - Стандарт де-факто среди менеджеров плагинов для zsh. С помощью него удобно устанавливать файлы, т.к. достаточно просто указать команды в .zshrc, сам пакетный менеджер подхватит все команды и выполнит их. У данного пакетного менеджера есть поддержка установки плагинов из репозитория Oh My Zsh, что делает использование самого шелла ещё более удобным, т.к. для Oh My Zsh написали очень много прекрасных плагинов.

antibody - Предоставляет те же функции, что и antigen, однако является быстрее и делает упор на производительность⚡ Единственный минус у данного менеджера плагинов - то, что он перешёл в maintaince mode, это означает что для него больше не выходят фичи, только фиксятся критические баги.

zgen - Легковесный и простой менеджер плагинов для zsh. Он генерирует отдельный файлик со списком плагинов, проверяет обновления автоматически и практически не влияет на startup time (время запуска шелла в первый раз). Данный менеджер плагинов также поддерживает установку плагино из репозитория Oh My Zsh😊

zinit - Данный менеджер плагинов является очень гибким в настройке. Это единстенный менеджер плагинов, у которого есть Turbo-режим (как написано в самом репозитории). Также сам менеджер плагинов является расширяемым. Для него написаны расширения (annexes), которые добавляют новые команды и функционал.

zplug - Один из очень медленных менеджеров плагинов, который по иронии является самым удобным😅 Обладает функцией параллельной установки/обновления, поддерживает ленивую загрузку плагинов, есть возможность написать пост и пре-хуки для плагинов, не создает лишние файлы при установке плагинов, есть механизм кэша, для того чтобы уменьшать и без того большую задержку startup time’а.

zpm - Разработчик указывает что это один из быстрейших менеджеров для плагинов в zsh (внизу будет график, посмотрим, правда ли это). Поддерживает Oh My Zsh плагины, поддерживает множество систем (Linux, Android, OpenWrt, FreeBSD and macOS), асинхронную загрузку, хуки, сам является расширяемым менеджером для плагинов.

Далее будет информация предоставленная с вот этого репозитория😊 Все картинки распространяются по вот этой лицензии.

Давайте глянем на время установки плагинов различными менеджерами:

И действительно автор zpm не соврал нам и менеджер быстрее всех устанавливает плагины. Однако нас мало волнует время установки, нам нужно быстрое время запуска самого шелла, так как в будущем при работе с шеллом долгий запуск будет нас только раздражать. Вот startup time у разных менеджеров:

Тут мы ясно и четко видим, что время загрузки самих плагинов у antibody, antigen, sheldon и zgen — примерно одинаковое, а вот zpm грузит плагины достаточно долго😳, не говоря уже про zplug🐌

И все-таки какой менеджер плагинов использовать? Одним из лучших по юзабельности является antigen, он является стандартом не просто так. Он достаточно быстро грузит все плагины (как и устанавливает) и не мельтешит перед глазами лишний раз. Один раз установим плагины и забудем даже, что он у нас есть😊

Для начала нужно создать .zshrc, который будет находится в корневой директории пользователя ($HOME).

Внутри самого .zshrc следует поместить следующее:

Данные настройки у каждого пользователя разные. Хорошей практикой в конфигурации шелла является объявлять все переменные вверху файла, а также допиливать функционал в шелле, которого не хватает стандартными методами (как допиливание сохранения истории из сессии в сессию).

Далее пойдут обычные условия на дополения переменной PATH, данная специальная переменная является строкой, которая подсказывает шеллу откуда таскать бинарники для команд:

Далее наконец-то перейдем к самой установке плагинов🎉 Всё, что нам нужно сделать — подключить сам Antigen, а затем объявить плагины, которые нам нужно скачать😊

Давайте пройдемся по всем плагинам, что я здесь указал😊

Последним плагином перед antigen apply является тема для самого шелла😊 Это Typewritten, минималистичная тема, которая имеет асинхронный Git Status

Если вам была интересна данная статья и вы хотите больше подобного материала, то советую вам подписаться на мой канал, я хоть и не часто, но выкладываю там что-то интересное✨