Различия блочных и строчных элементов
Простой вопрос с собеседования, в котором путается много новичков. Предлагаю расставить всё по местам.
Итак, все элементы в HTML делятся на две основные группы: блочные и строчные.
Блочные элементы - это та группа элементов, которые при размещении занимают всю доступную ширину. Блочные элементы всегда становятся друг под другом.
Строчные элементы - это группа элементов, ширина которых соответствует ширине контента внутри них. В отличии от блочных элементов, они располагаются в строку, если для этого хватает места.
Также тип элемента можно изменять при помощи стилей. Если блочному элементу необходимо задать поведение строчного, то достаточно для него указать правило
Также существует что-то среднее между блочным и строчным элементом. Для этого необходимо задать правило
Пример блочных элементов:
Пример строчных элементов:
Из интересного, в более старых версиях HTML было так, что в блочные элементы можно было вкладывать как блочные, так и строчные элементы. А в строчные можно было вложить только строчные. Сейчас такого нет. В HTML5 порядок вложения тегов ни на что не влияет. В новой спецификации используется категориальное деление тегов. Об этом в других постах.
И на этом всё. Достаточно просто, но почему-то вызывает много путаницы. Да и для повторения лишним не будет. Спасибо за прочтение, это важно для меня ❤️
#web #theory
Простой вопрос с собеседования, в котором путается много новичков. Предлагаю расставить всё по местам.
Итак, все элементы в HTML делятся на две основные группы: блочные и строчные.
Блочные элементы - это та группа элементов, которые при размещении занимают всю доступную ширину. Блочные элементы всегда становятся друг под другом.
Строчные элементы - это группа элементов, ширина которых соответствует ширине контента внутри них. В отличии от блочных элементов, они располагаются в строку, если для этого хватает места.
Также тип элемента можно изменять при помощи стилей. Если блочному элементу необходимо задать поведение строчного, то достаточно для него указать правило
display: inline. Для обратной ситуации по аналогии указывается display: block.Также существует что-то среднее между блочным и строчным элементом. Для этого необходимо задать правило
display: inline-block. Пример блочных элементов:
<div>, <p>, <ul>, <h1>Пример строчных элементов:
<a>, <span>, <strong>, <img>Из интересного, в более старых версиях HTML было так, что в блочные элементы можно было вкладывать как блочные, так и строчные элементы. А в строчные можно было вложить только строчные. Сейчас такого нет. В HTML5 порядок вложения тегов ни на что не влияет. В новой спецификации используется категориальное деление тегов. Об этом в других постах.
И на этом всё. Достаточно просто, но почему-то вызывает много путаницы. Да и для повторения лишним не будет. Спасибо за прочтение, это важно для меня ❤️
#web #theory
👍1
Зачем нужен DOCTYPE в HTML
Вроде бы все знают, что в начале каждого HTML документа необходимо указывать магический тег
Этот тег - отдельная структура в языках разметки, которая называется Document Type Definition или аббревиатура DTD. Похожие определяющие тип документа теги или свойства встречаются, например, в SVG или XML:
И этот тег как раз определяет версию документа. Думаю так же многие знают, что актуальная сейчас версия — HTML5. Чтобы сказать браузеру, что мы используем именно эту версию языка HTML, в начале документа мы указываем тег, который соответствует этой версии, то есть:
Вот так вот просто. Вариантов написания этого тега далеко не один, полный список определений можно найти в интернете. Версию браузеру нужно указывать для того, чтобы рассказать ему как правильно парсить наш документ. От этого зависит на сколько правильно будет отображаться контент на странице, так что лучше не полениться и дописать одну строчку.
И на этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #theory
Вроде бы все знают, что в начале каждого HTML документа необходимо указывать магический тег
<!DOCTYPE html>, но мало кто может объяснить зачем это нужно делать. Все делают, вот и я делаю тоже. В этом посте расскажу зачем. Этот тег - отдельная структура в языках разметки, которая называется Document Type Definition или аббревиатура DTD. Похожие определяющие тип документа теги или свойства встречаются, например, в SVG или XML:
<?xml version="1.0" encoding="UTF-8"?>
<svg
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
>
И этот тег как раз определяет версию документа. Думаю так же многие знают, что актуальная сейчас версия — HTML5. Чтобы сказать браузеру, что мы используем именно эту версию языка HTML, в начале документа мы указываем тег, который соответствует этой версии, то есть:
<!DOCTYPE html>
Вот так вот просто. Вариантов написания этого тега далеко не один, полный список определений можно найти в интернете. Версию браузеру нужно указывать для того, чтобы рассказать ему как правильно парсить наш документ. От этого зависит на сколько правильно будет отображаться контент на странице, так что лучше не полениться и дописать одну строчку.
И на этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #theory
Понятия URL, URI и URN
Когда речь заходит о локации документов и адресации, в голову всегда приходит такое понятие, как URL. Это так называемая ссылка для получения документа. Но на самом деле это лишь часть общей теории о локации документов, и сейчас мы разберём эту тему подробнее.
Итак, в адресации существует 3 понятия:
URI - Uniform Resource Identifier - общий идентификатор ресурса.
URL - Uniform Resource Locator - подмножество URI, которое указывает на адрес к ресурсу и механизм обращения к ресурсу.
URN - Uniform Resource Name - имя ресурса, которое записывается по определенному шаблону и является частью URI, но не гарантирует доступность этого ресурса.
На примере это выглядит так:
И механизмом обращения может быть конечно-же не только
И так же важно знать, что:
URL - это всегда URI
А URI - не всегда URL
Это связано с тем, что в URL не входит ресурс, как
На этом у меня всё. Спасибо за прочтение, это важно для меня. И спасибо, что для моего канала показали большую активность в опросе выше. Ценю.
#web #theory
Когда речь заходит о локации документов и адресации, в голову всегда приходит такое понятие, как URL. Это так называемая ссылка для получения документа. Но на самом деле это лишь часть общей теории о локации документов, и сейчас мы разберём эту тему подробнее.
Итак, в адресации существует 3 понятия:
URI - Uniform Resource Identifier - общий идентификатор ресурса.
URL - Uniform Resource Locator - подмножество URI, которое указывает на адрес к ресурсу и механизм обращения к ресурсу.
URN - Uniform Resource Name - имя ресурса, которое записывается по определенному шаблону и является частью URI, но не гарантирует доступность этого ресурса.
На примере это выглядит так:
URI: https://github.com/grnbows/markdown-github-blog#usage
URL: https://github.com/grnbows/markdown-github-blog
URN: github.com/grnbows/markdown-github-blog#usage
https:// в данном случае называется механизмом обращения к ресурсу, #usage — самим ресурсом, в всё что между — это путём до ресурса.И механизмом обращения может быть конечно-же не только
https:// или http://. Также механизмом обращения будет, например ftp://, smb://, file:// и т.д.И так же важно знать, что:
URL - это всегда URI
А URI - не всегда URL
Это связано с тем, что в URL не входит ресурс, как
#usage в примере.На этом у меня всё. Спасибо за прочтение, это важно для меня. И спасибо, что для моего канала показали большую активность в опросе выше. Ценю.
#web #theory
Что такое cookies
Эти окошки с уведомлением об использовании cookies на сайте лично мне уже надоели 🙂Предлагаю хотя бы разобраться что это такое.
cookies — это способ хранить данные на стороне клиента. Сервер присваивает к ответу на запрос некоторую key-value структуру данных, которая сохраняется на стороне клиента. А после клиент при каждом обращении к этому серверу будет отправлять эти самые cookies в составе каждого запроса. Таким образом, cookies — это данные, которые постоянно летают от пользователя к серверу и обратно.
Эта концепция очень востребована в вебе, так как позволяет реализовать большой блок функционала на сайте, например:
— Аутентификация
— Отслеживание разных статусов пользователя
— Локальные настройки пользователя
— Отслеживание действий и предпочтений пользователя
— и т.д.
Также cookies бывают разных уровней:
— Сессионные cookies — удаляются после закрытия браузера
— Постоянные cookies — удаляются через какой-то установленный промежуток времени и не удаляются при закрытии браузера
— Сторонние cookies — куки, которые не привязаны к домену
— Супер cookie — доступны на уровне доменной зоны ( .ru, например )
— Зомби cookie — кукисы, которые сложно или невозможно удалить ( их восстанавливают через JavaScript даже после удаления )
Когда использовать куки? Тогда, когда какая-то информация на сервере нам нужна постоянно. Когда актуальность и скорость в приоритете. Но стоит учитывать, что максимальный размер вообще всех cookies - 4093 байта или почти 4 КБайта. Это очень маленький размер.
Тот же localstorage, например, позволяет хранить данные размером до 10 Мегабайт.
Также учитывайте и то, что для хранения cookies у пользователя необходимо запрашивать разрешение. На всё остальное разрешение нам не нужно, делаем что хотим.
Скоро напишу пост о всех доступных способах хранения информации на клиенте, это очень популярный вопрос на собеседовании. Ну и пока на этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #theory
Эти окошки с уведомлением об использовании cookies на сайте лично мне уже надоели 🙂Предлагаю хотя бы разобраться что это такое.
cookies — это способ хранить данные на стороне клиента. Сервер присваивает к ответу на запрос некоторую key-value структуру данных, которая сохраняется на стороне клиента. А после клиент при каждом обращении к этому серверу будет отправлять эти самые cookies в составе каждого запроса. Таким образом, cookies — это данные, которые постоянно летают от пользователя к серверу и обратно.
Эта концепция очень востребована в вебе, так как позволяет реализовать большой блок функционала на сайте, например:
— Аутентификация
— Отслеживание разных статусов пользователя
— Локальные настройки пользователя
— Отслеживание действий и предпочтений пользователя
— и т.д.
Также cookies бывают разных уровней:
— Сессионные cookies — удаляются после закрытия браузера
— Постоянные cookies — удаляются через какой-то установленный промежуток времени и не удаляются при закрытии браузера
— Сторонние cookies — куки, которые не привязаны к домену
— Супер cookie — доступны на уровне доменной зоны ( .ru, например )
— Зомби cookie — кукисы, которые сложно или невозможно удалить ( их восстанавливают через JavaScript даже после удаления )
Когда использовать куки? Тогда, когда какая-то информация на сервере нам нужна постоянно. Когда актуальность и скорость в приоритете. Но стоит учитывать, что максимальный размер вообще всех cookies - 4093 байта или почти 4 КБайта. Это очень маленький размер.
Тот же localstorage, например, позволяет хранить данные размером до 10 Мегабайт.
Также учитывайте и то, что для хранения cookies у пользователя необходимо запрашивать разрешение. На всё остальное разрешение нам не нужно, делаем что хотим.
Скоро напишу пост о всех доступных способах хранения информации на клиенте, это очень популярный вопрос на собеседовании. Ну и пока на этом у меня всё. Спасибо за прочтение, это важно для меня.
#web #theory
👍1🔥1
Как запретить изменение объекта
Итак, этот вопрос встречается на собеседованиях довольно часто в разных формулировках. В этом посте постараюсь дать максимально обширный ответ на этот вопрос.
Для объяснения введём объект для примеров:
Чтобы запретить изменения объекта существует два метода —
После выполнения этого кода получим объект:
Свойство
После выполнения получим объект:
Все манипуляции с объектом проигнорируются, в
При этом стоит понимать, что обе этих функции не осуществляют рекурсивных преобразований, а как следствие, замораживают только верхний уровень свойств:
После выполнения кода получим:
То есть проблем с изменениями нет.
И часто функцию
И на этом у меня всё, спасибо за прочтение, это важно для меня ❤️
#theory #web
Итак, этот вопрос встречается на собеседованиях довольно часто в разных формулировках. В этом посте постараюсь дать максимально обширный ответ на этот вопрос.
Для объяснения введём объект для примеров:
const obj = {
name: "progway",
type: "channel",
subscribers: 435
}
Чтобы запретить изменения объекта существует два метода —
Object.freeze и Object.seal. Они оба запрещают изменять объект, но только по разному.Object.seal запрещает добавлять в объект новые свойства. Если мы попытаемся добавить в объект новое поле, например avatar, которое будет URL-ом до аватарки канала, то мы это сделать не сможем. Но изменять свойства объекта получится: Object.seal(obj)
obj.avatar = '...url'
obj.subscribers = 999
После выполнения этого кода получим объект:
{
name: "progway",
type: "channel",
subscribers: 999
}
Свойство
avatar просто не будет добавлено. При этом в strict режиме мы получим TypeError. Об этом режиме расскажу в следующих постах, но это важно знать уже сейчас.Object.freeze действует на объект так же, как и Object.seal, но при этом не позволяет изменять уже записанные свойства. Состояние полностью замораживается и не может быть изменено:Object.freeze(obj)
obj.avatar = '...url'
obj.subscribers = 9999
После выполнения получим объект:
{
name: "progway",
type: "channel",
subscribers: 435
}
Все манипуляции с объектом проигнорируются, в
strict режиме так же получаем TypeError.При этом стоит понимать, что обе этих функции не осуществляют рекурсивных преобразований, а как следствие, замораживают только верхний уровень свойств:
const obj = {
name: "progway",
type: "channel",
avatar: {
url: "...url",
extension: "jpeg"
}
}
Object.freeze(obj)
obj.avatar.extension = "png"
После выполнения кода получим:
{
name: "progway",
type: "channel",
avatar: {
url: "...url",
extension: "png"
}
}
То есть проблем с изменениями нет.
И часто функцию
deepFreeze просят написать на собеседованиях. Всвязи с этим запускаю ещё один опрос ниже, информацию о нём можете прочитать следующим постом.И на этом у меня всё, спасибо за прочтение, это важно для меня ❤️
#theory #web
👍3
Хоть где-то ваш голос важен
В посте выше я сказал, что хочу провести новый опрос, вот в чём суть:
В этом канале я часто разбираю теоретические вопросы с собеседования, но так же на этих самых собеседованиях встречаются задачи. Идея заключается в том, чтобы ввести и разборы задач с собеседования, которые будут выходить время от времени под новым хештегом #task. Думаю, что это будет полезно многим и мы немного разбавим теорию практикой, что очень полезно. А вы что думаете?
В посте выше я сказал, что хочу провести новый опрос, вот в чём суть:
В этом канале я часто разбираю теоретические вопросы с собеседования, но так же на этих самых собеседованиях встречаются задачи. Идея заключается в том, чтобы ввести и разборы задач с собеседования, которые будут выходить время от времени под новым хештегом #task. Думаю, что это будет полезно многим и мы немного разбавим теорию практикой, что очень полезно. А вы что думаете?
Что такое timestamp
Без введения, timestamp — это unix-значение, равное количеству миллисекунд, прошедших с 1 января 1970 года по всемирному координированному времени (по Гринвичу).
Это очень важное значение в программировании, которое позволяет отслеживать и сортировать датированную информацию динамически. И работает это потому что timestamp — это обычно большое положительное число, как способ представления времени, которое легко поддаётся обработке операторами сравнения. Чем больше число, тем больше миллисекунд прошло с начала 1970 года и, следовательно, тем позже это время.
Практически все операции со временем производятся с преобразованием в timestamp. Это воспринимается просто, если привыкнуть.
В JavaScript timestamp можно получить при помощи метода глобального класса
Метод
И, соответственно, timestamp можно преобразовать в дата-строку. Делается это вот так:
Форматов времени больше чем эти два, что я показал. Их все можно посмотреть на MDN.
На этом у меня всё, спасибо за прочтение. Это важно для меня ❤️
#web #theory
Без введения, timestamp — это unix-значение, равное количеству миллисекунд, прошедших с 1 января 1970 года по всемирному координированному времени (по Гринвичу).
Это очень важное значение в программировании, которое позволяет отслеживать и сортировать датированную информацию динамически. И работает это потому что timestamp — это обычно большое положительное число, как способ представления времени, которое легко поддаётся обработке операторами сравнения. Чем больше число, тем больше миллисекунд прошло с начала 1970 года и, следовательно, тем позже это время.
Практически все операции со временем производятся с преобразованием в timestamp. Это воспринимается просто, если привыкнуть.
В JavaScript timestamp можно получить при помощи метода глобального класса
Date. Запись выглядит так: const timestamp = Date.now() // 1627142678295
Метод
now является статическим, так что использовать его можно без оператора new у класса. В timestamp-e из комментария зашифровано время написания поста, так что можете посмотреть когда это было. Кто узнает, тот молодец. И, соответственно, timestamp можно преобразовать в дата-строку. Делается это вот так:
const date = new Date(timestamp)
date.toLocaleDateString("ru-RU") // "24.07.2021"
date.toLocaleDateString("en-US") // "7/24/2021"
Форматов времени больше чем эти два, что я показал. Их все можно посмотреть на MDN.
На этом у меня всё, спасибо за прочтение. Это важно для меня ❤️
#web #theory
👍1
Структура HTTP запроса
Сегодня с вами поговорим о структуре HTTP запроса, разберёмся из чего он состоит.
Итак, HTTP запрос состоит из нескольких частей:
— Строка запроса
Method — Метод запроса — это описание действия, которое должен выполнить запрос
URL — Адрес запроса — строка, указывающая на расположение ресурса в сети
Версия HTTP протокола — например,
— Headers — Заголовки
Набор полей, которые описывают сопутствующую запросу информацию. Например это
— Body — Тело сообщения
Если строка запроса и заголовки есть всегда, то тело — необязательный параметр. В теле запроса мы можем передавать данные в самых разных форматах.
Более подробно о методах запроса мы поговорим позже, в отдельном посте.
Если соединить все составляющие в единый текст, то мы получим типовое сообщение, которыми клиент и сервер общаются по протоколу HTTP.
И на этом всё. Как вы можете заметить, это было достаточно просто. Советую выучить эту информацию, она очень часто встречается на собеседовании. Спасибо за прочтение, это важно для меня.
#web #theory
Сегодня с вами поговорим о структуре HTTP запроса, разберёмся из чего он состоит.
Итак, HTTP запрос состоит из нескольких частей:
— Строка запроса
Method — Метод запроса — это описание действия, которое должен выполнить запрос
URL — Адрес запроса — строка, указывающая на расположение ресурса в сети
Версия HTTP протокола — например,
HTTP/1.1— Headers — Заголовки
Набор полей, которые описывают сопутствующую запросу информацию. Например это
User-Agent, Authentification, Cookie и так далее— Body — Тело сообщения
Если строка запроса и заголовки есть всегда, то тело — необязательный параметр. В теле запроса мы можем передавать данные в самых разных форматах.
Более подробно о методах запроса мы поговорим позже, в отдельном посте.
Если соединить все составляющие в единый текст, то мы получим типовое сообщение, которыми клиент и сервер общаются по протоколу HTTP.
И на этом всё. Как вы можете заметить, это было достаточно просто. Советую выучить эту информацию, она очень часто встречается на собеседовании. Спасибо за прочтение, это важно для меня.
#web #theory
Блокировка ввода/вывода для самых маленьких
Я думаю, многие встречали это:
Эта мифическая запись, на самом деле, — просто сокращение записи
Почему это понятие важно? Почему так часто встречается?
Практически во всех языках программирования существует такое понятие, как блокировка ввода/вывода, или
В неблокирующих операциях всё одновременно сложно и просто. Мы можем выполнять любые действия, но у них нет гарантированной последовательности. Для максимально бытового примера возьмём моё утро:
Я просыпаюсь и хочу позавтракать. Иду на кухню и ставлю кипятиться свой чайник. Для меня эта операция неблокирующая. Я не буду как истукан стоять и смотреть на чайник, пока он даст мне результат запроса — горячую воду. Пока чайник занят делом, я приведу себя в порядок, например, схожу почистить зубы и умоюсь. Это ещё ряд операций. После этого я вернусь на кухню и увижу, что чайник всё еще работает. Тогда я возьму свою кружку, приготовлю заварник и рано или поздно услышу характерный щелчок кнопки чайника. Этим звуком он оповестил меня, что результат готов. Операция закончена.
На уровне ОС всё так же: допустим, что нам нужно прочитать файл. Программа сделает неблокирующий запрос в ОС и скажет «дай мне файл вот по этому адресу». Но вместо ожидания результат она пойдет и посчитает мне факториал. После этого снова обратится к ОС и спросит «результат уже готов?». ОС ответит, что нет, а моя программа не обидится и сделает ещё некоторые операции. Тогда ОС либо оповестит мою программу о готовом результате, или моя программа сама спросит это, не важно. Суть в другом.
Вместо того, чтобы ждать, мы сделали ещё кучу всего полезного. В итоге вся последовательность действий заняла меньше времени, чем если бы эти действия выполнялись синхронно.
Если бы моё утро было синхронным, то я бы пришёл на кухню, включил чайник и завис. Всё, я больше ничего не могу делать. Я смотрю на чайник и жду пока он закончит. Только потом сделал бы всё остальное.
И эти концепции опускаются куда ниже уровня современных языков программирования или быта. Мы опустимся на уровень ОС и управления потоками.
С блокирующим вводом-выводом вы просите ОС «усыпить» ваш поток и «разбудить» его только после того, как данные из файла будут доступны для чтения.
То есть блокирующий ввод-вывод называется так, потому что поток, который его использует, блокируется и переходит в режим ожидания, пока ввод-вывод не будет завершён.
И неблокирующие операции, конечно, позволяют выполнять некоторые действия быстрее, но проблема с ними заключается в том, что работать с ними на самом деле не удобно. Всё только в теории круто, а на практике куча нюансов. Для примера возьмём
Мы запрашиваем у пользователя число и как результат выводим его же, умноженное на два. Если бы
В общем, блокировка ввода/вывода — это приказ ждать данных. Огромный рассказ вышел, но зато мне кажется, после этого невозможно не понять.
Возможно для многих эта информация будет очевидной, но не все ведь такие, как вы, да?
Спасибо за прочтение, это важно для меня ❤️
#theory
Я думаю, многие встречали это:
I/O. Практически у всех начинающих разработчиков эта конструкция вызывает шок и подёргивание правого глаза. Но на самом деле это очень просто, сейчас объясню.Эта мифическая запись, на самом деле, — просто сокращение записи
Input/Output. И, казалось бы, тайна раскрыта, расходимся. И всё конечно очень просто, но не на столько.Почему это понятие важно? Почему так часто встречается?
Практически во всех языках программирования существует такое понятие, как блокировка ввода/вывода, или
I/O Block. И на самом деле, существует два вида операций — блокирующие и неблокирующие. Такое разделение нужно для избежания ошибок в ходе работы компьютера. В неблокирующих операциях всё одновременно сложно и просто. Мы можем выполнять любые действия, но у них нет гарантированной последовательности. Для максимально бытового примера возьмём моё утро:
Я просыпаюсь и хочу позавтракать. Иду на кухню и ставлю кипятиться свой чайник. Для меня эта операция неблокирующая. Я не буду как истукан стоять и смотреть на чайник, пока он даст мне результат запроса — горячую воду. Пока чайник занят делом, я приведу себя в порядок, например, схожу почистить зубы и умоюсь. Это ещё ряд операций. После этого я вернусь на кухню и увижу, что чайник всё еще работает. Тогда я возьму свою кружку, приготовлю заварник и рано или поздно услышу характерный щелчок кнопки чайника. Этим звуком он оповестил меня, что результат готов. Операция закончена.
На уровне ОС всё так же: допустим, что нам нужно прочитать файл. Программа сделает неблокирующий запрос в ОС и скажет «дай мне файл вот по этому адресу». Но вместо ожидания результат она пойдет и посчитает мне факториал. После этого снова обратится к ОС и спросит «результат уже готов?». ОС ответит, что нет, а моя программа не обидится и сделает ещё некоторые операции. Тогда ОС либо оповестит мою программу о готовом результате, или моя программа сама спросит это, не важно. Суть в другом.
Вместо того, чтобы ждать, мы сделали ещё кучу всего полезного. В итоге вся последовательность действий заняла меньше времени, чем если бы эти действия выполнялись синхронно.
Если бы моё утро было синхронным, то я бы пришёл на кухню, включил чайник и завис. Всё, я больше ничего не могу делать. Я смотрю на чайник и жду пока он закончит. Только потом сделал бы всё остальное.
И эти концепции опускаются куда ниже уровня современных языков программирования или быта. Мы опустимся на уровень ОС и управления потоками.
С блокирующим вводом-выводом вы просите ОС «усыпить» ваш поток и «разбудить» его только после того, как данные из файла будут доступны для чтения.
То есть блокирующий ввод-вывод называется так, потому что поток, который его использует, блокируется и переходит в режим ожидания, пока ввод-вывод не будет завершён.
И неблокирующие операции, конечно, позволяют выполнять некоторые действия быстрее, но проблема с ними заключается в том, что работать с ними на самом деле не удобно. Всё только в теории круто, а на практике куча нюансов. Для примера возьмём
Python и рассмотрим код:number = input('Введите число: ')
print(int(number) * 2)
Мы запрашиваем у пользователя число и как результат выводим его же, умноженное на два. Если бы
input не был блокирующей операцией, а он такой является, то программа пошла бы и уже что-то вывела. Но зачем? Что в таком случае будет в number, если пользователь еще ничего не ввёл? Как много вопросов, но так мало ответов...В общем, блокировка ввода/вывода — это приказ ждать данных. Огромный рассказ вышел, но зато мне кажется, после этого невозможно не понять.
Возможно для многих эта информация будет очевидной, но не все ведь такие, как вы, да?
Спасибо за прочтение, это важно для меня ❤️
#theory
👍1
Что такое CRUD endpoint
Без вступления скажу, что этот вопрос очень важен для работы с апи. Без этого понятия вы работать не сможете. Точнее, работать то сможете, но вот собеседование можете не пройти 🙂
Это комплексное понятие. Два разных понятия объединяются и создают новое более расширенное. Давайте разберёмся по порядку:
Что такое CRUD?
Это цикл в обработке данных. Данный акроним состоит из 4 слов, которые собой характеризуют полный цикл обработки информации: Create, Read, Update, Remove. Если что-то поддерживает сразу 4 эти операции, то это что-то называется CRUD-полным или же просто поддерживающим цикл CRUD.
Что такое endpoint?
Endpoint — это понятие в разработке API, дословно «конечная точка». Каждая точка взаимодействия с API называется конечной. Для примера возьмём типичный endpoint REST-API для получения списка пользователей:
Этот путь и называется enpoint.
Так что же такое CRUD-endpoint?
Это endpoint, поддерживающий цикл CRUD 🙂
Например, вышеописанный путь
Пример CRUD-полного endpoint'a:
Подробнее в официальной документации. Такое расширение нашего endpoint'a также имеет название CRUD endpoint.
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#theory #useful
Без вступления скажу, что этот вопрос очень важен для работы с апи. Без этого понятия вы работать не сможете. Точнее, работать то сможете, но вот собеседование можете не пройти 🙂
Это комплексное понятие. Два разных понятия объединяются и создают новое более расширенное. Давайте разберёмся по порядку:
Что такое CRUD?
Это цикл в обработке данных. Данный акроним состоит из 4 слов, которые собой характеризуют полный цикл обработки информации: Create, Read, Update, Remove. Если что-то поддерживает сразу 4 эти операции, то это что-то называется CRUD-полным или же просто поддерживающим цикл CRUD.
Что такое endpoint?
Endpoint — это понятие в разработке API, дословно «конечная точка». Каждая точка взаимодействия с API называется конечной. Для примера возьмём типичный endpoint REST-API для получения списка пользователей:
(GET) /users
Этот путь и называется enpoint.
Так что же такое CRUD-endpoint?
Это endpoint, поддерживающий цикл CRUD 🙂
Например, вышеописанный путь
/users не является CRUD-полным. Этот путь в описанной спецификации поддерживает только HTTP метод GET, который можно отнести к операции Read. Остальные 3 операции нам недоступны.Пример CRUD-полного endpoint'a:
(POST) - /users - Create
(GET) - /users - Read
(PUT/PATCH) - /users - Update or replace/modify
(DELETE) - /users - Delete
Подробнее в официальной документации. Такое расширение нашего endpoint'a также имеет название CRUD endpoint.
На этом у меня всё. Спасибо за прочтение, это важно для меня.
#theory #useful
❤1
Теперь не только в Telegram
К сожалению или счастью, следуем трендам. Теперь @prog_way_blog доступен в TikTok'е и некоторые посты будут дублироваться там в видео-формате. Основной поток постов не изменится и всё так же продолжит выходить в прежнем формате на лучшей площадке мира — в Telegram.
Об аккаунте в TikTok я рассказываю тут для интересующихся, чтобы дать этому аккаунту какой-то старт. Далее вы о нём вряд ли услышите. Всех, кто иногда заходит полистать видосики, прошу поддержать меня там.
Аккаунт доступен по ссылке
Я надеюсь, что этот старт поможет мне расширить аудиторию канала, так что ваша активность под видосиками очень кстати. Всем неравнодушным — спасибо за поддержку.
И всем без исключения спасибо, что находите мой канал интересным и остаётесь в нём. И так же спасибо за прочтение, это очень важно для меня ❤️
#blog
К сожалению или счастью, следуем трендам. Теперь @prog_way_blog доступен в TikTok'е и некоторые посты будут дублироваться там в видео-формате. Основной поток постов не изменится и всё так же продолжит выходить в прежнем формате на лучшей площадке мира — в Telegram.
Об аккаунте в TikTok я рассказываю тут для интересующихся, чтобы дать этому аккаунту какой-то старт. Далее вы о нём вряд ли услышите. Всех, кто иногда заходит полистать видосики, прошу поддержать меня там.
Аккаунт доступен по ссылке
Я надеюсь, что этот старт поможет мне расширить аудиторию канала, так что ваша активность под видосиками очень кстати. Всем неравнодушным — спасибо за поддержку.
И всем без исключения спасибо, что находите мой канал интересным и остаётесь в нём. И так же спасибо за прочтение, это очень важно для меня ❤️
#blog
Что такое DTO
Часто бывает так, что в базе данных хранятся пользователи нашего сайта. Для них в базе данных много полей и связей. А для отображения на фронтенде нам нужны всего лишь, например, его имя, уровень и аватар. Нам что теперь, отправить всю базу данных на фронт? Сейчас разберёмся как решить эту проблему.
Самым правильным способом тут является, как мне кажется, генерация DTO.
DTO — Data Transfer Object — объект, который деструктуризирует базу данных и создаёт новый объект на её основе для передачи данных.
Для простоты примера представим, что в качестве базы данных используется MongoDB, чтобы данные о пользователе хранились в JSON'е. Далее рассмотрим такой псевдокод:
Код максимально простой, зато сколько пользы. Теперь эту DTO можно задокументировать, а лучше создать отдельный тип в TypeScript'e и развернуть его на весь проект. При изменении типа, линтер сразу покажет ошибки.
1. В ответе только нужные данные
2. Ответ от сервера быстрее приходит и меньше весит
Максимально полезный концепт, всем советую. И на этом у меня всё. Спасибо за прочтение, это важно для меня.
#useful #theory #data
Часто бывает так, что в базе данных хранятся пользователи нашего сайта. Для них в базе данных много полей и связей. А для отображения на фронтенде нам нужны всего лишь, например, его имя, уровень и аватар. Нам что теперь, отправить всю базу данных на фронт? Сейчас разберёмся как решить эту проблему.
Самым правильным способом тут является, как мне кажется, генерация DTO.
DTO — Data Transfer Object — объект, который деструктуризирует базу данных и создаёт новый объект на её основе для передачи данных.
Для простоты примера представим, что в качестве базы данных используется MongoDB, чтобы данные о пользователе хранились в JSON'е. Далее рассмотрим такой псевдокод:
// класс-конструктор DTO. Обычно отдельным файлом
// в папке dto или dtos
class UserDTO {
constructor(user) {
this.name = user.name
this.level = user.stats.level
this.avatar = user.media.avatar
}
}
// псевдозапрос к базе данных
const user = database.getUser()
// генерация DTO
const userDto = new UserDTO(user)
// отправляем ответ
res.status(200).json(userDto)
Код максимально простой, зато сколько пользы. Теперь эту DTO можно задокументировать, а лучше создать отдельный тип в TypeScript'e и развернуть его на весь проект. При изменении типа, линтер сразу покажет ошибки.
1. В ответе только нужные данные
2. Ответ от сервера быстрее приходит и меньше весит
Максимально полезный концепт, всем советую. И на этом у меня всё. Спасибо за прочтение, это важно для меня.
#useful #theory #data
О важности вёрстки
Этот пункт часто упускают, стараясь углубиться во что угодно, кроме него самого. Разработчики учат 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. Специальный метод
hasOwnProperty2. Оператор
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
