О важности вёрстки
Этот пункт часто упускают, стараясь углубиться во что угодно, кроме него самого. Разработчики учат JavaScript фреймворки, сборщики, шаблонизаторы и метаязыки, но не знают о существовании тега time и скринридеров 🙂 Почему же вёрстка — это так важно?
Во-первых, это, конечно же, доступность для бо́льшего круга пользователей. Скринридеры позволяют людям с ограниченными возможностями пользоваться сайтами, а значит делать заказы и приносить бизнесу и вам деньги. Но важно тут то, что скринридеров помогают только при наличии качественной вёрстки, с использованием правильных тегов и настроенной семантикой уровня свойств типа
Во-вторых, качественная верстка грузится и обрабатывается быстрее. DOM-Api — это узкое горлышко в вебе, которое замедляет работу всего JavaScript. Чем больше уровней вложенности и тегов в вашем DOM дереве, тем медленнее работает сайт.
В третьих, качественная вёрстка стоит дороже. Тут без лишних комментариев.
И грустно, что в интернете особо нет качественных источников с обзорами, например, юзкейсов семантических тегов. Но, на самом деле, лучший способ обучения — это практика. Вы не изучите теги, не поймете разницу между отзывчивостью и адаптивность, не сможете вырасти как специалист, если просто не будете верстать. Практика и гугл — это лучший способ чему-то научиться.
Удобнее всего верстать с расчетом на наполнение своего портфолио. Мы либо делаем пет-проекты, либо верстаем макеты. Их не сложно найти в интернетах, но легче всего искать что-то в телеграм каналах. У моего знакомого есть подобный канал, его я и могу порекомендовать. Там каждый день новые макеты, а ещё есть сортировка по категории, сложности, другим параметрам и это очень удобно.
Ссылочка: @uniquetemplates
Верстайте. Практика — это лучшее, что может быть в этом деле. Ну и лекции Макеева, конечно.
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #useful
Этот пункт часто упускают, стараясь углубиться во что угодно, кроме него самого. Разработчики учат JavaScript фреймворки, сборщики, шаблонизаторы и метаязыки, но не знают о существовании тега time и скринридеров 🙂 Почему же вёрстка — это так важно?
Во-первых, это, конечно же, доступность для бо́льшего круга пользователей. Скринридеры позволяют людям с ограниченными возможностями пользоваться сайтами, а значит делать заказы и приносить бизнесу и вам деньги. Но важно тут то, что скринридеров помогают только при наличии качественной вёрстки, с использованием правильных тегов и настроенной семантикой уровня свойств типа
aria-label
. В ином случае, незрячий, который захочет принести вам свои деньги, не сможет этого сделать. Это не выгодно никому из вас.Во-вторых, качественная верстка грузится и обрабатывается быстрее. DOM-Api — это узкое горлышко в вебе, которое замедляет работу всего JavaScript. Чем больше уровней вложенности и тегов в вашем DOM дереве, тем медленнее работает сайт.
В третьих, качественная вёрстка стоит дороже. Тут без лишних комментариев.
И грустно, что в интернете особо нет качественных источников с обзорами, например, юзкейсов семантических тегов. Но, на самом деле, лучший способ обучения — это практика. Вы не изучите теги, не поймете разницу между отзывчивостью и адаптивность, не сможете вырасти как специалист, если просто не будете верстать. Практика и гугл — это лучший способ чему-то научиться.
Удобнее всего верстать с расчетом на наполнение своего портфолио. Мы либо делаем пет-проекты, либо верстаем макеты. Их не сложно найти в интернетах, но легче всего искать что-то в телеграм каналах. У моего знакомого есть подобный канал, его я и могу порекомендовать. Там каждый день новые макеты, а ещё есть сортировка по категории, сложности, другим параметрам и это очень удобно.
Ссылочка: @uniquetemplates
Верстайте. Практика — это лучшее, что может быть в этом деле. Ну и лекции Макеева, конечно.
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #useful
Основные структуры данных: Стек
Стек — это структура данных, которая подчиняется принципу LIFO, что расшифровывается как «Last In First Out». Суть заключается в расшифровке принципа: первым будет доступен тот элемент, который положен последним.
На бытовом примере, стек — это принглс. Мы можем достать только ту чипсину, что вверху, возле крышки. При этом та, что в коробке оказалось первой и сейчас лежит внизу, в наших руках окажется последней. Мы, конечно, можем перевернуть коробку и высыпать всё, но допустим, что не можем и нам нужно доставать чипсы по одной.
В JavaScript реализация стека максимально простая. Как вы наверное знаете, у массива есть методы
Но чтобы всё работало нормально, нельзя к массиву применять никакие другие методы. Ну или необходимо написать свою обёртку:
Таким образом мы полностью ограничили использование других методов над стеком.
Это первый подобный пост. Я решил описать большинство структур данных и выделить их отдельным хештегом #data. Тут будут все структуры данных, а так же в целом всё, что связано с данными. Закреп обновлён.
Спасибо за прочтение, это правда важно для меня ❤️
#theory
Стек — это структура данных, которая подчиняется принципу LIFO, что расшифровывается как «Last In First Out». Суть заключается в расшифровке принципа: первым будет доступен тот элемент, который положен последним.
На бытовом примере, стек — это принглс. Мы можем достать только ту чипсину, что вверху, возле крышки. При этом та, что в коробке оказалось первой и сейчас лежит внизу, в наших руках окажется последней. Мы, конечно, можем перевернуть коробку и высыпать всё, но допустим, что не можем и нам нужно доставать чипсы по одной.
В JavaScript реализация стека максимально простая. Как вы наверное знаете, у массива есть методы
push
и pop
. Первый добавляет элемент в конец, а второй с конца удаляет и возвращает. То есть стек уже как будто бы существует в JavaScript нативно и выглядеть это будет так:const stack = []
stack.push(1)
stack.push(2)
stack.pop() // 2
stack.pop() // 1
stack.pop() // undefined
Но чтобы всё работало нормально, нельзя к массиву применять никакие другие методы. Ну или необходимо написать свою обёртку:
class Stack {
constructor() {
this.stack = []
}
add(value) {
this.stack.push(value)
}
get() {
return this.stack.pop()
}
}
const stack = new Stack()
stack.add(1)
stack.add(2)
console.log(stack.get()) // 2
console.log(stack.get()) // 1
console.log(stack.get()) // undefined
Таким образом мы полностью ограничили использование других методов над стеком.
Это первый подобный пост. Я решил описать большинство структур данных и выделить их отдельным хештегом #data. Тут будут все структуры данных, а так же в целом всё, что связано с данными. Закреп обновлён.
Спасибо за прочтение, это правда важно для меня ❤️
#theory
Что такое BFF
В мире разработки чуть ли не каждый день возникают новые архитектурные подходы, особенно во FrontEnd'e. Один из относительно новых затрагивает и BackEnd.
BackEnd for FrontEnd, или BFF — это архитектурное направление, которое подразумевает создание отдельного интерфейса взаимодействия для каждого из FrontEnd'ов. Вместо создания одного общего API разработчики ограничивают зоны ответственности и появляются отдельные интерфейсы для каждого из клиентов.
На примере телеграм, у нас есть:
— Веб версия
— Десктопные клиенты
— Мобильные приложения
— Sticker API
— Bot API
— и так далее
И BFF, как часть микросервисного мышления гласит, что один интерфейс-монолит — это неудобно. Зачем делать огромный API, если мы можем сделать несколько поменьше, дабы увеличить скорость работы, поставить зоны ответственности и сделать систему более динамичной, уменьшив связность?
При соблюдении BFF, у Telegram будет несколько интерфейсов API:
— Bot API
— Sticker API
— Mobile API
— Web API
При том допускается разделение Mobile и Web API на, например:
— Chat API
— Channel API
— Audio Call API
— Video Call API
— и так далее
Этих интерфейсов может быть достаточно много для такого большого сервиса. Подробнее можно почитать в разборе Сэма Ньюмана, автора книги «Building Microservices» в издательстве O'REILLY.
На этом у меня всё. Спасибо за прочтение, это правда важно для меня.
#web #theory #patterns #principles
В мире разработки чуть ли не каждый день возникают новые архитектурные подходы, особенно во FrontEnd'e. Один из относительно новых затрагивает и BackEnd.
BackEnd for FrontEnd, или BFF — это архитектурное направление, которое подразумевает создание отдельного интерфейса взаимодействия для каждого из FrontEnd'ов. Вместо создания одного общего API разработчики ограничивают зоны ответственности и появляются отдельные интерфейсы для каждого из клиентов.
На примере телеграм, у нас есть:
— Веб версия
— Десктопные клиенты
— Мобильные приложения
— Sticker API
— Bot API
— и так далее
И BFF, как часть микросервисного мышления гласит, что один интерфейс-монолит — это неудобно. Зачем делать огромный API, если мы можем сделать несколько поменьше, дабы увеличить скорость работы, поставить зоны ответственности и сделать систему более динамичной, уменьшив связность?
При соблюдении BFF, у Telegram будет несколько интерфейсов API:
— Bot API
— Sticker API
— Mobile API
— Web API
При том допускается разделение Mobile и Web API на, например:
— Chat API
— Channel API
— Audio Call API
— Video Call API
— и так далее
Этих интерфейсов может быть достаточно много для такого большого сервиса. Подробнее можно почитать в разборе Сэма Ньюмана, автора книги «Building Microservices» в издательстве O'REILLY.
На этом у меня всё. Спасибо за прочтение, это правда важно для меня.
#web #theory #patterns #principles
Где хранить данные на клиенте
Web-приложения сейчас — это уже давно не обычные странички для отображения текста. Сейчас почти каждое приложение обладает авторизацией, собственным состоянием и часто манипулирует с данными. Сохраняет их, обрабатывает и выдаёт пользователю какой-то результат. Сегодня поговорим о том, как и где можно сохранить данные на клиенте.
Мне известно 4 способа: LocalStorage, SessionStorage, IndexedDB и Cookies. И я ранее уже делал посты с более подробным объяснение что такое LocalStorage, SessionStorage и Cookies. В этом посте мы разберемся не в том что это такое, а в каких ситуациях и что использовать.
Итак, если с LocalStorage, SessionStorage и Cookies всё плюс минус понятно после прочтения моих прошлых постов, то с IndexedDB появляется проблема: я ни разу не видел IndexedDB на практике 🤔 Информации в интернете тоже не особо много, так что тут мы затронем этот способ только косвенно. Также не будем трогать штуки типа MobX, Redux и так далее. Остановимся только на нативных инструментах.
Для вас я приготовил характеристическую таблицу-сравнение этих способов. Ознакомиться с ней можно по ссылке. Таблица, как говорили в СССР про квартиру — маленькая, зато своя.
Далее же в посте я разберу частые примеры:
1. Аутентификация — cookies.
Аутентификация, по большей части, работа серверная. Сервер должен решать авторизован ли пользователь, получая какие-то исходные данные, и понимать, отдавать информацию или нет. Cookies отправляются на сервер с каждым запросом без исключения, поэтому часто в cookies сидит httpOnly токен авторизации. LocalStorage тут лучше не использовать из-за того, что это менее безопасно и сервер не имеет доступа к LocalStorage, что важно для скорости и отказоустойчивости.
2. Сохранение корзины пользователя — cookies или LocalStorage.
Если нам не важно что в корзине у пользователя, то LocalStorage - наш вариант, потому что это никак не нагружает соединение и позволяет сохранять DTO без последствий. На безопасность наплевать. Если злоумышленник получит JSON корзины, то что? Cookies тоже жизнеспособный вариант, но корзина нужна далеко не на всех страницах сайта, так что трафик будет излишне нагружен. Если необходимо сохранить корзину на сервере, то лучше создать для этого отдельный CRUD-endpoint и использовать REST Api.
3. Метрики — cookies. Нужны всегда и нужны на сервере.
4. Сохранить данные формы — LocalStorage или SessionStorage. На сервере нам это не нужно.
5. Фильтры на сайте — cookies или SessionStorage.
Для фильтров жизненный цикл сессии — идеален. LocalStorage хранит эти данные слишком долго. Сессия же хранит файлы столько, сколько нужно, не нагружая соединение. Ну и так же фильтры не нужны на всех страницах.
В итоге, панацеи нет. Есть несколько вариантов и под каждую из ситуаций просто нужно выбрать свой. И на этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #theory #useful #data
Web-приложения сейчас — это уже давно не обычные странички для отображения текста. Сейчас почти каждое приложение обладает авторизацией, собственным состоянием и часто манипулирует с данными. Сохраняет их, обрабатывает и выдаёт пользователю какой-то результат. Сегодня поговорим о том, как и где можно сохранить данные на клиенте.
Мне известно 4 способа: LocalStorage, SessionStorage, IndexedDB и Cookies. И я ранее уже делал посты с более подробным объяснение что такое LocalStorage, SessionStorage и Cookies. В этом посте мы разберемся не в том что это такое, а в каких ситуациях и что использовать.
Итак, если с LocalStorage, SessionStorage и Cookies всё плюс минус понятно после прочтения моих прошлых постов, то с IndexedDB появляется проблема: я ни разу не видел IndexedDB на практике 🤔 Информации в интернете тоже не особо много, так что тут мы затронем этот способ только косвенно. Также не будем трогать штуки типа MobX, Redux и так далее. Остановимся только на нативных инструментах.
Для вас я приготовил характеристическую таблицу-сравнение этих способов. Ознакомиться с ней можно по ссылке. Таблица, как говорили в СССР про квартиру — маленькая, зато своя.
Далее же в посте я разберу частые примеры:
1. Аутентификация — cookies.
Аутентификация, по большей части, работа серверная. Сервер должен решать авторизован ли пользователь, получая какие-то исходные данные, и понимать, отдавать информацию или нет. Cookies отправляются на сервер с каждым запросом без исключения, поэтому часто в cookies сидит httpOnly токен авторизации. LocalStorage тут лучше не использовать из-за того, что это менее безопасно и сервер не имеет доступа к LocalStorage, что важно для скорости и отказоустойчивости.
2. Сохранение корзины пользователя — cookies или LocalStorage.
Если нам не важно что в корзине у пользователя, то LocalStorage - наш вариант, потому что это никак не нагружает соединение и позволяет сохранять DTO без последствий. На безопасность наплевать. Если злоумышленник получит JSON корзины, то что? Cookies тоже жизнеспособный вариант, но корзина нужна далеко не на всех страницах сайта, так что трафик будет излишне нагружен. Если необходимо сохранить корзину на сервере, то лучше создать для этого отдельный CRUD-endpoint и использовать REST Api.
3. Метрики — cookies. Нужны всегда и нужны на сервере.
4. Сохранить данные формы — LocalStorage или SessionStorage. На сервере нам это не нужно.
5. Фильтры на сайте — cookies или SessionStorage.
Для фильтров жизненный цикл сессии — идеален. LocalStorage хранит эти данные слишком долго. Сессия же хранит файлы столько, сколько нужно, не нагружая соединение. Ну и так же фильтры не нужны на всех страницах.
В итоге, панацеи нет. Есть несколько вариантов и под каждую из ситуаций просто нужно выбрать свой. И на этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #theory #useful #data
Как проверить есть ли свойство в объекте
Отличный вопрос с собеседований, который ещё и на практике помогает. И в JavaScript есть два способа определить есть ли у объекта свойство, о них сегодня и поговорим.
1. Специальный метод
2. Оператор
Запись выглядит так:
Оба способа вернут нам
Но эти способы не равнозначны, они работают по разному. Отличие заключается в том, что метод
Это важно учитывать. И если речь идёт о нахождении собственного свойства в объекте, то лучше использовать первый метод.
На этом у меня всё. Спасибо за прочтение, это важно для меня ❤️
#javascript #theory #useful
Отличный вопрос с собеседований, который ещё и на практике помогает. И в JavaScript есть два способа определить есть ли у объекта свойство, о них сегодня и поговорим.
1. Специальный метод
hasOwnProperty
2. Оператор
in
Запись выглядит так:
const obj = {
name: "Denis",
age: 20
}
obj.hasOwnProperty("name") // true
"age" in obj // true
Оба способа вернут нам
boolean
значение, которое укажет на присутствие свойства в объекте. Но эти способы не равнозначны, они работают по разному. Отличие заключается в том, что метод
hasOwnProperty
рассматривает конкретный объект, а оператор in
рассматривает объект и его цепочку прототипов. Таким образом:obj.hasOwnProperty("toString") // false
"toString" in obj // true
Это важно учитывать. И если речь идёт о нахождении собственного свойства в объекте, то лучше использовать первый метод.
На этом у меня всё. Спасибо за прочтение, это важно для меня ❤️
#javascript #theory #useful
❤1
Что такое SSR
Иногда бывает так, что веб приложение разрастается на столько, что начинает грузиться неоправданно долго. Эта одни из причин использовать SSR. О том что это такое и зачем ещё это нужно сегодня и поговорим.
SSR — Server-Side Rendering — это технология рендеринга страницы на сервере. Таким образом наше, например React приложение, полностью генерирует весь HTML на сервере, отправляя клиенту все компоненты приложения полностью готовыми.
К плюсам SSR можно отнести:
1. Улучшение воспринимаемой скорости загрузки страницы
2. Гарантия правильной индексации поисковыми ботами
3. Пререндеринг контента для ссылок в социальных сетях. Появляется красивый предварительный просмотр с заголовком страницы, описанием и изображением
4. Полная разгрузка пользователя
К минусам:
1. Размер отправляемого файла с сервера больше, сам файл сложнее.
2. Высокая нагрузка на сервер
3. Полная перезагрузка страницы при смене рута
Из всего этого можно сделать вывод, что SSR идеально подходит для статических сайтов с большим количеством контента или для тех сайтов, где важна индексация каждой его странице в поиске. Не смотря на то, что Google сделал заявление, что приложения с Client-Side Rendering индексируются так же хорошо, вопрос всё ещё находится в довольно подвешенном состоянии. Полное сравнение CSR и SSR можно посмотреть тут.
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #useful #theory
Иногда бывает так, что веб приложение разрастается на столько, что начинает грузиться неоправданно долго. Эта одни из причин использовать SSR. О том что это такое и зачем ещё это нужно сегодня и поговорим.
SSR — Server-Side Rendering — это технология рендеринга страницы на сервере. Таким образом наше, например React приложение, полностью генерирует весь HTML на сервере, отправляя клиенту все компоненты приложения полностью готовыми.
К плюсам SSR можно отнести:
1. Улучшение воспринимаемой скорости загрузки страницы
2. Гарантия правильной индексации поисковыми ботами
3. Пререндеринг контента для ссылок в социальных сетях. Появляется красивый предварительный просмотр с заголовком страницы, описанием и изображением
4. Полная разгрузка пользователя
К минусам:
1. Размер отправляемого файла с сервера больше, сам файл сложнее.
2. Высокая нагрузка на сервер
3. Полная перезагрузка страницы при смене рута
Из всего этого можно сделать вывод, что SSR идеально подходит для статических сайтов с большим количеством контента или для тех сайтов, где важна индексация каждой его странице в поиске. Не смотря на то, что Google сделал заявление, что приложения с Client-Side Rendering индексируются так же хорошо, вопрос всё ещё находится в довольно подвешенном состоянии. Полное сравнение CSR и SSR можно посмотреть тут.
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #useful #theory
Что такое lazy load
С ростом веб приложений всё более актуальной стала проблема загрузки страницы. Объём текста, картинок, скриптов и других частей страницы стал очень быстро увеличиваться. Вместе со скоростью загрузки страницы.
Одним из решений стала стратегия ленивой загрузки. HTML документ читается сверху вниз и когда натыкается на какой-либо ресурс, операция загрузки этого ресурса является блокирующей. Lazy load же декларирует ресурс как «неблокирующий», что позволяет полностью сформировать документ без загрузки подобных ресурсов. Загрузка становится асинхронной.
На практике это чаще всего применяется к изображениям, как с самым тяжелым частям страницы. В итоге получается, что картинки догружаются уже после загрузки страницы постепенно. Также подобные изображения не загружаются, например, пока пользователь не доскроллил до них. Таким образом мы оптимизируем потребление ресурсов сети.
В вёрстке чаще всего это задаётся через свойство
Есть и другие способы, но их оставим как домашнее заданее 🙂
Спасибо за прочтение. Это важно для меня ❤️
#web #theory
С ростом веб приложений всё более актуальной стала проблема загрузки страницы. Объём текста, картинок, скриптов и других частей страницы стал очень быстро увеличиваться. Вместе со скоростью загрузки страницы.
Одним из решений стала стратегия ленивой загрузки. HTML документ читается сверху вниз и когда натыкается на какой-либо ресурс, операция загрузки этого ресурса является блокирующей. Lazy load же декларирует ресурс как «неблокирующий», что позволяет полностью сформировать документ без загрузки подобных ресурсов. Загрузка становится асинхронной.
На практике это чаще всего применяется к изображениям, как с самым тяжелым частям страницы. В итоге получается, что картинки догружаются уже после загрузки страницы постепенно. Также подобные изображения не загружаются, например, пока пользователь не доскроллил до них. Таким образом мы оптимизируем потребление ресурсов сети.
В вёрстке чаще всего это задаётся через свойство
load:
<img src="image.jpg" loading="lazy" alt="..." />
Есть и другие способы, но их оставим как домашнее заданее 🙂
Спасибо за прочтение. Это важно для меня ❤️
#web #theory
Что такое прогрессивный рендеринг
Довольно старая и интересная концепция в вебе, которую очень любят интервьюеры.
Прогрессивный рендеринг — это все методы оптимизации загрузки страницы, когда мы стараемся показать пользователю контент как можно быстрее. Особенно это актуально для устройств с медленным интернетом, то есть для мобильных устройств.
И прогрессивный рендеринг — это не одна технология, а их комплекс. Чаще всего на собеседовании от вас ждут такие способы, как ленивая загрузка, разбиение приложения на мелкие файлы или SSR.
Подробнее я разбирал некоторые из этих способов оптимизации ранее, так что не вижу смысла повторяться. На каждый разобранный способ есть ссылка.
Спасибо за прочтение, это важно для меня.
#web #theory
Довольно старая и интересная концепция в вебе, которую очень любят интервьюеры.
Прогрессивный рендеринг — это все методы оптимизации загрузки страницы, когда мы стараемся показать пользователю контент как можно быстрее. Особенно это актуально для устройств с медленным интернетом, то есть для мобильных устройств.
И прогрессивный рендеринг — это не одна технология, а их комплекс. Чаще всего на собеседовании от вас ждут такие способы, как ленивая загрузка, разбиение приложения на мелкие файлы или SSR.
Подробнее я разбирал некоторые из этих способов оптимизации ранее, так что не вижу смысла повторяться. На каждый разобранный способ есть ссылка.
Спасибо за прочтение, это важно для меня.
#web #theory
Основные структуры данных: Очередь
Очередь — это структура данных, которая подчиняется принципу FIFO, что расшифровывается как «First In First Out», то есть первым будет доступен тот элемент, который положен в очередь первым.
Бытовой пример очереди примитивен. Очередь в данных — это сама честная очередь, например, из больницы, где первым в кабинет врача попадёт тот, кто и пришёл первым, пока остальные ждут. Все мы конечно знаем что такое очереди в больницах, но почему бы не помечтать?
Так же как и для стека, в JavaScript очередь может быть реализована через нативные методы массива:
Но чтобы всё работало нормально, нельзя к массиву применять никакие другие методы. Ну или необходимо написать свою обёртку:
Таким образом мы полностью ограничили использование других методов над очередью.
Также напомню, что ранее в канале уже рассматривалась такая структура данных как стек.
Спасибо за прочтение, это правда важно для меня ❤️
#theory #data
Очередь — это структура данных, которая подчиняется принципу FIFO, что расшифровывается как «First In First Out», то есть первым будет доступен тот элемент, который положен в очередь первым.
Бытовой пример очереди примитивен. Очередь в данных — это сама честная очередь, например, из больницы, где первым в кабинет врача попадёт тот, кто и пришёл первым, пока остальные ждут. Все мы конечно знаем что такое очереди в больницах, но почему бы не помечтать?
Так же как и для стека, в JavaScript очередь может быть реализована через нативные методы массива:
push
и shift
. Первый добавляет элемент в конец, а второй из начала удаляет и возвращает. Выглядеть это будет примерно так:const queue = []
queue.push(1)
queue.push(2)
queue.shift() // 1
queue.shift() // 2
queue.shift() // undefined
Но чтобы всё работало нормально, нельзя к массиву применять никакие другие методы. Ну или необходимо написать свою обёртку:
class Queue {
constructor() {
this.queue = []
}
enqueue(value) {
this.queue.push(value)
}
dequeue() {
return this.queue.shift()
}
}
const queue = new Queue()
queue.enqueue(1)
queue.enqueue(2)
queue.dequeue() // 1
queue.dequeue() // 2
queue.dequeue() // undefined
enqueue
— вставить элемент в очередьdequeue
— удалить элемент из очереди и получить егоТаким образом мы полностью ограничили использование других методов над очередью.
Также напомню, что ранее в канале уже рассматривалась такая структура данных как стек.
Спасибо за прочтение, это правда важно для меня ❤️
#theory #data
Способы создания объекта
Тоже очень популярный вопрос с собеседований по JavaScript, который показывает ваши познания в своеобразном мире объектов. Итак, существует 4 разных метода:
1. Литеральная нотация
2. Через функцию конструктор или класс. Стоит помнить, что классы в JavaScript — это обёртка над функциями конструкторами, так что объединяю эти два способа в один
3. Через конструктор объекта
4. Через метод-конструктор объекта
Спасибо за прочтение, это важно для меня ❤️
#web #javascript #theory
Тоже очень популярный вопрос с собеседований по JavaScript, который показывает ваши познания в своеобразном мире объектов. Итак, существует 4 разных метода:
1. Литеральная нотация
const obj = {}
2. Через функцию конструктор или класс. Стоит помнить, что классы в JavaScript — это обёртка над функциями конструкторами, так что объединяю эти два способа в один
function CatFunc(name) {
this.name = name
}
Cat.prototype.run = function() {
console.log("run")
}
class CatClass {
constructor(name) {
this.name = name
}
run() {
console.log("run")
}
}
const barsik = new CatFunc("Барсик")
const tom = new CatClass("Том")
3. Через конструктор объекта
const obj = new Object()
4. Через метод-конструктор объекта
const obj = Object.create(Object.prototype)
Спасибо за прочтение, это важно для меня ❤️
#web #javascript #theory
Мутабельные и иммутабельные данные
Сегодня разберемся что такое мутабельность данных на примере JavaScript, изучим нюансы и рассмотрим примеры.
Данные называются мутабельными, если после создания они могут менять своё состояние. Соответственно, иммутабельные данные своего состояния менять не могут.
В JavaScript как пример мутабельных данных возьмём массив, а иммутабельных — строку.
Строка не изменилась, в отличии от массива. И, кстати, в Python всё сработало бы идеально, так как строки там — мутабельны.
Все типы данных в JavaScript, кроме объектов, являются иммутабельными, то есть значения не могут быть модифицированы, а только перезаписаны новым полным значением.
И я напоминаю, что массив — это тоже объект в JavaScript.
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #javascript #theory
Сегодня разберемся что такое мутабельность данных на примере JavaScript, изучим нюансы и рассмотрим примеры.
Данные называются мутабельными, если после создания они могут менять своё состояние. Соответственно, иммутабельные данные своего состояния менять не могут.
В JavaScript как пример мутабельных данных возьмём массив, а иммутабельных — строку.
const mutableArray = [1,2,3]
const immutableStroke = "progway"
mutableArray.push(4)
// [1,2,3,4]
immutableStroke[0] = "A"
// "progway"
Строка не изменилась, в отличии от массива. И, кстати, в Python всё сработало бы идеально, так как строки там — мутабельны.
Все типы данных в JavaScript, кроме объектов, являются иммутабельными, то есть значения не могут быть модифицированы, а только перезаписаны новым полным значением.
И я напоминаю, что массив — это тоже объект в JavaScript.
typeof [] // "object"
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #javascript #theory
Операторы сравнения в JavaScript
Вопрос, который встречается чуть ли не на каждом втором собеседовании. Пора разобраться с этим.
Итак, в JavaScript есть несколько операторов сравнения: больше, меньше... и всё это не особо интересно. Внимание стоит уделить типам, а именно операторам
И разница в этих двух операторах довольно примитивная, сначала рассмотрим пример:
Суть в том, что двойное равенство работает с автоприведением типов. Поэтому в JavaScript строка
Тройное же равенство всегда вернёт
Аналогично
Использованием операторов с автоприведением типов считается плохим тоном.
Спасибо за прочтение, это важно для меня ❤️
#web #javascript #theory
Вопрос, который встречается чуть ли не на каждом втором собеседовании. Пора разобраться с этим.
Итак, в JavaScript есть несколько операторов сравнения: больше, меньше... и всё это не особо интересно. Внимание стоит уделить типам, а именно операторам
==
и ===
.И разница в этих двух операторах довольно примитивная, сначала рассмотрим пример:
"1" === 1 // false
2 == "2" // true
Суть в том, что двойное равенство работает с автоприведением типов. Поэтому в JavaScript строка
"2"
и число 2
могут быть равны. И работает это итеративно. При использовании двойного равенства, интерпретатор JavaScript старается привести данные к одному типу. Если привести не получается, то последним действием итерации сравнения, грубо говоря, используется оператор ===
. Тройное же равенство всегда вернёт
false
, если типы сравниваемых значений разные.Аналогично
==
и ===
есть операторы !=
и !==
, суть та же.Использованием операторов с автоприведением типов считается плохим тоном.
Спасибо за прочтение, это важно для меня ❤️
#web #javascript #theory
Разница for..in и for..of
В JavaScript есть много способов перебрать итерабельные объекты, и циклы
Эти циклы — это что-то очень похожее на обычный
Для начала рассмотрим код:
Цикл
Поэтому после первого цикла в консоли мы увидим значения
Цикл
И, в целом, на этом всё. Общий вывод кода выше будет такой:
В этом и заключается вся разница. Спасибо за прочтение, это важно дня меня ❤️
#web #javascript #theory
В JavaScript есть много способов перебрать итерабельные объекты, и циклы
for..in
и for..of
— способы, достойные внимания.Эти циклы — это что-то очень похожее на обычный
for
, что удивительным назвать сложно. Я бы назвал это некоторой надстройкой, сейчас объясню почему.Для начала рассмотрим код:
const arr = [10,20]
for (let key in arr) {
console.log(key)
}
for (let value of arr) {
console.log(value)
}
Цикл
for..in
перебирает сущность по его перечисляемым свойствам. В массиве такими свойствами являются индексы элементов, а в объекте, например, — ключи объекта.Поэтому после первого цикла в консоли мы увидим значения
"0"
и "1"
Цикл
for..of
перебирает только те сущности, где реализован внутренний итератор, обычно возвращающий значения объекта. Тут мы не будем углубляться о том что это такое, разберёмся позже. Скорее важно понимать, что цикл применим только к итерируемым объектам. Обычный объект итерируемым не является.И, в целом, на этом всё. Общий вывод кода выше будет такой:
"0"
"1"
10
20
В этом и заключается вся разница. Спасибо за прочтение, это важно дня меня ❤️
#web #javascript #theory
Кстати, про 500 человек на канале я так ничего и не написал...
...Но видимо настало время, ведь более крутой картинки на этот случай я не найду.
Вот так выглядит 547 человеков пауков. Спасибо восьмилапым товарищам за эту цифорку✨
#blog
...Но видимо настало время, ведь более крутой картинки на этот случай я не найду.
Вот так выглядит 547 человеков пауков. Спасибо восьмилапым товарищам за эту цифорку✨
#blog
Логические операторы JavaScript
В JavaScript, как и во многих других языках, есть логические операторы для объединения различных условий. В этом посте закрепим эту тему, рассмотрим как они применяются и изучим некоторые нюансы.
Не будем опускаться до всяких базовых вещей типа записи комплексных условий. Но для галочки запишу пример:
Сегодня будем говорить о чём-то более интересном.
1. Всего операторов три:
2. Преобразовать значение к типу
3. Оператор
4. Оператор
5. Операторы
Это первое, что приходит в голову на эту тему.
Спасибо за прочтение, это важно для меня ❤️
#web #javascript #theory
В JavaScript, как и во многих других языках, есть логические операторы для объединения различных условий. В этом посте закрепим эту тему, рассмотрим как они применяются и изучим некоторые нюансы.
Не будем опускаться до всяких базовых вещей типа записи комплексных условий. Но для галочки запишу пример:
if (x > 0 && (y === 2 || y === 7)) {
doSomething()
}
Сегодня будем говорить о чём-то более интересном.
1. Всего операторов три:
&&, ||, !
2. Преобразовать значение к типу
boolean
быстро можно, используя двойное отрицание.let name = "Denis"
let age
let obj = { age }
!!name // true
!!age // false
!!obj // true
3. Оператор
||
возвращает первое истинное значение.const name = "Denis" || "Max" || undefined
// name = "Denis"
4. Оператор
&&
возвращает первое ложное значение.const age = 20 && '' && null
// age = ''
5. Операторы
||
и &&
можно использовать вместо if
.let x, y
true && (x = 2)
true || (y = 10)
// x = 2
// y = undefined
Это первое, что приходит в голову на эту тему.
Спасибо за прочтение, это важно для меня ❤️
#web #javascript #theory
🔥1
Преобразование строки в число
Хочу, кстати, рассказать об интересном и неявном способе преобразовать строку в число в JavaScript. Речь идет о плюсике. Об обычном плюсике, да. Выглядит это так:
Коротко и со смыслом мне кажется, ведь на этом, по сути, и правда всё.
Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
Хочу, кстати, рассказать об интересном и неявном способе преобразовать строку в число в JavaScript. Речь идет о плюсике. Об обычном плюсике, да. Выглядит это так:
const string = "20"
const num = +string
const num2 = 10 + +string
// num = 20
// num2 = 30, не ошибка
Коротко и со смыслом мне кажется, ведь на этом, по сути, и правда всё.
Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
🔥1
Оператор объединения с null '??'
Относительно новая замена оператору
С сервера приходит адрес пользователя, который может быть
Какая-то совсем страшная кроказябра написана сверху, не так ли?
А можно записать вот так:
Оператор
И кто-то заметит, что вместо
Что если в вышепредставленном
Смотрим код:
Оператор
На этом всё. Спасибо за прочтение, это важно для меня.
#web #theory #javascript
Относительно новая замена оператору
||
в быту разработчика. Рассмотрим вот такую ситуацию:С сервера приходит адрес пользователя, который может быть
null
либо undefined
. В таком случае, обработать этот кейс можно так:const state = (json.city !== null && json.city !== undefined) ? json.city : "default"
Какая-то совсем страшная кроказябра написана сверху, не так ли?
А можно записать вот так:
const state = json.city ?? "default"
Оператор
??
возвращает первый аргумент, если он не null/undefined
, иначе второй. В этой ситуации это однозначно спасает ситуацию и делает код более читаемым.И кто-то заметит, что вместо
??
можно использовать ||
. А вот и нет. Такая ситуация:Что если в вышепредставленном
json
есть поле score
. Оно либо ноль, либо null/undefined
.Смотрим код:
// json.score = 0
json.score || 1000 // 1000
json.score ?? 1000 // 0
Оператор
??
работает только с null
и undefined
, а ||
также обрабатывает falsy-значения. На этом всё. Спасибо за прочтение, это важно для меня.
#web #theory #javascript
👍2❤1
Что такое Spread и Rest операторы и в чём их отличие
Итак, Rest оператор — это оператор, который позволяет собрать лишние аргументы. Сразу на примере:
В объявлении функции мы используем Rest оператор, который собирает все оставшиеся поданные в функцию аргументы в массив.
Spread оператор, в свою очередь, не применяется как способ развернуть один объект в другой:
Так же это работает не только с массивами, но и, например, с объектами.
Разница Spread и Rest оператора заключается конечно же в том, какой результат выполнения они имеют. Но можно заметить, что они имеют одинаковый синтаксис
— Rest оператор применяется только в объявлении функции с целью создания коллекции аргументов.
— Spread оператор применяется во всех остальных случаях.
На этом у меня всё. Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
Итак, Rest оператор — это оператор, который позволяет собрать лишние аргументы. Сразу на примере:
function foo(a, b, ...manyMoreArgs) {
console.log("a", a);
console.log("b", b);
console.log("manyMoreArgs", manyMoreArgs);
}
foo(1, 2, 3, 4, 5, 6);
// a, 1
// b, 2
// manyMoreArgs, [3, 4, 5, 6]
В объявлении функции мы используем Rest оператор, который собирает все оставшиеся поданные в функцию аргументы в массив.
Spread оператор, в свою очередь, не применяется как способ развернуть один объект в другой:
const arr1 = [1, 2]
const arr2 = [4, 5]
const arr3 = [...arr1, 3, ...arr2]
// arr3, [1, 2, 3, 4, 5]
Так же это работает не только с массивами, но и, например, с объектами.
Разница Spread и Rest оператора заключается конечно же в том, какой результат выполнения они имеют. Но можно заметить, что они имеют одинаковый синтаксис
(...)
. Отсюда сделаем замечание, что:— Rest оператор применяется только в объявлении функции с целью создания коллекции аргументов.
— Spread оператор применяется во всех остальных случаях.
На этом у меня всё. Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
👍1
Что такое нечистый объект
Информации нет в интернете, кстати. Не знаю почему, но видел этот вопрос только на тестовом собеседовании, а вот в интернете ответа просто нет. Эксклюзив, получается 🙂
Итак, понятие "нечистый объект" появляется в контексте клонирования объекта. Нечистым объектом называется тот объект, который внутри себя содержит ссылки на себя же.
Пример:
Тут объект ссылается сам на себя, из-за чего при копировании код будет завершаться переполнением стека вызова.
На этом всё. Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
Информации нет в интернете, кстати. Не знаю почему, но видел этот вопрос только на тестовом собеседовании, а вот в интернете ответа просто нет. Эксклюзив, получается 🙂
Итак, понятие "нечистый объект" появляется в контексте клонирования объекта. Нечистым объектом называется тот объект, который внутри себя содержит ссылки на себя же.
Пример:
const obj = {
foo: 1,
bar: obj
}
или
const obj = {
foo: 1,
bar: {
obj.x
},
x: obj.bar
}
Тут объект ссылается сам на себя, из-за чего при копировании код будет завершаться переполнением стека вызова.
На этом всё. Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
❤2🤷♂1👍1
Какой объект называется итерабельным
Сегодня поговорим о том какой объект называется итерабельным, а именно, какой объект можно проитерировать при помощи цикла
У любого итерабельного объекта в JavaScript присутствует специальный ключ
Следовательно, чтобы сделать объект неитерабельным, необходимо удалить это свойство.
И в целом на этом всё. Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
Сегодня поговорим о том какой объект называется итерабельным, а именно, какой объект можно проитерировать при помощи цикла
for..of
.У любого итерабельного объекта в JavaScript присутствует специальный ключ
[Symbol.Iterator]
. По этому ключу доступен генератор, который предоставляет для итерации значения. Подробнее о работе генераторов я расскажу в другой раз.Следовательно, чтобы сделать объект неитерабельным, необходимо удалить это свойство.
И в целом на этом всё. Спасибо за прочтение, это важно для меня ❤️
#web #theory #javascript
👍1