Что будет в консоли?
Anonymous Quiz
25%
progway, undefined
18%
progway, ReferenceError
6%
ReferenceError, 4
52%
undefined, ReferenceError
🔥23🐳6😁4😐3❤2🍌1
Как сохранять состояние в URL
В одном из прошлых постов я рассматривал требования к стажировке в Авито. Одним из требований к тестовому было кешировать значения в URL, в этом посте рассмотрим это более подробно и сделаем самую простую реализацию такого функционала.
Представим, что у нас есть строковый инпут для имени пользователя, его состояние в URL может выглядеть следующим образом:
Соответственно, нам нужен инструмент, который позволит управлять этим состоянием. Как бы хотелось это видеть? Лично мне — ровно так же, как работает и обычный
Первым аргументом будем указывать ключ в URL, а вторым — изначальное состояние. Далее рассмотрим внутреннюю имплементацию хука и начнём с его интерфейса, тут всё достаточно просто:
Реализуем наш собственный хук на базе
Ну а всё что нужно далее — реагировать на изменение состояния и обновлять URL в соответствии с ним. Если в инпуте вдруг окажется пустая строка, то мы просто удалим наше состояние из Query параметров
Да и всё. Всё работает.
Вот весь код, который, конечно же, не идеальный. Смысл поста — отразить основную суть.
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #code #typescript #web #react
В одном из прошлых постов я рассматривал требования к стажировке в Авито. Одним из требований к тестовому было кешировать значения в URL, в этом посте рассмотрим это более подробно и сделаем самую простую реализацию такого функционала.
Представим, что у нас есть строковый инпут для имени пользователя, его состояние в URL может выглядеть следующим образом:
www.site.com/?name=progway
Соответственно, нам нужен инструмент, который позволит управлять этим состоянием. Как бы хотелось это видеть? Лично мне — ровно так же, как работает и обычный
useState
. Тогда от этого и будем отталкиваться:const [name, setName] = useQueryState("name");
const [surname, setSurname] = useQueryState("surname", "Putnov");
Первым аргументом будем указывать ключ в URL, а вторым — изначальное состояние. Далее рассмотрим внутреннюю имплементацию хука и начнём с его интерфейса, тут всё достаточно просто:
type QueryValue = string | undefined;
function useQueryState<I extends QueryValue>(
queryKey: string,
defaultValue?: I,
) {
// тело хука
}
Реализуем наш собственный хук на базе
useSearchParams
из react-router-dom
для удобного доступа к состоянию URL-a. Если вы используете другой роутинг, можно использовать аналогичный механизм, который подойдёт именно в вашем проекте. Мы же будем его использовать для изменения URL-a и восстановления состояния из URL-a при маунте компонента. Если в URL-е уже есть состояние, мы будем использовать его. Если нет, будем использовать defaultValue
:const [searchParams, setSearchParams] = useSearchParams();
const [state, setState] = useState<QueryValue>(() => {
const targetValue = searchParams.get(queryKey);
if (targetValue !== null) {
return targetValue;
}
return defaultValue;
});
Ну а всё что нужно далее — реагировать на изменение состояния и обновлять URL в соответствии с ним. Если в инпуте вдруг окажется пустая строка, то мы просто удалим наше состояние из Query параметров
useLayoutEffect(() => {
setSearchParams((prev) => {
if (state) {
prev.set(queryKey, state);
} else {
prev.delete(queryKey);
}
return prev;
});
}, [state, queryKey, setSearchParams]);
Да и всё. Всё работает.
Вот весь код, который, конечно же, не идеальный. Смысл поста — отразить основную суть.
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #code #typescript #web #react
🔥26👍7🤯4🐳3☃1🍌1
Что делать новичку
Ноги подкашиваются, руки трясутся, паника, в глазах потемнело… Типичная реакция человека, который вчера только на уроках программирования в школе в экселе сидел, а сегодня увидел перечень необходимых навыков для реализации ToDo-листа.
В этом посте выдам своё ИМХО для первых шагов в фронтенде. Как раз зафиксирую все необходимые ссылки, чтобы не писать одно и то же каждый раз. Далее я описываю конкретные шаги, которые нужно пройти последовательно:
1. Базовое понимание вёрстки, среды разработки
Вёрстка — это основа веб страницы. Нужно понимать какие есть теги и как они используются, уметь стилизовать элементы страницы и переиспользовать уже готовые части кода. В моём понимании, джун — тот, кто может худо-бедно сверстать ozon.ru
Лучший плейлист по вёрстке на русском языке
2. Система контроля версий
Важная часть, которую необходимо изучать сразу же после того, как вы сверстаете свои первые значимые странички. Пункт зачтён, когда на каждый проект вы умеете создавать репозиторий, владеете
Лучшая базовая статья по гиту
3. JavaScript
Ура, программирование. Нужно уметь решать алгоритмические задачи easy уровня с leetcode.com, понимать что такое DOM, события, event loop, замыкание. Тут важно сделать акцент на взаимодействии с HTML — добавление и удаление элементов на страницу, изменение их состояния, базовые умения работать с сетью по HTTP. Чем больше вы проведете времени на этом этапе, тем лучше. Рынку не нужны “React-программисты”. Знать базу очень важно. Аналогия очень простая: без хорошего понимания что такое
Лучшее видео по JavaScript
4. TypeScript
На хорошую JS базу отлично ляжет TypeScript. Переходить к фреймворкам/библиотекам без TypeScript’a я вообще не вижу смысла.
Лучший базовый плейлист по TypeScript
5. Выбор фреймворка
Абсолютно всё равно что вы возьмёте для первоначального знакомства. Я глубоко убежден, что, например, из Vue в React и обратно, реально перекатиться за два полных рабочих дня. Да, вы не будете знать абсолютно всех мелочей, но сможете писать адекватный код. Лично я, если бы начинал, выбрал бы Vue или React. Без объяснения причин, мне просто прикольно поизучать их. Ангуляр никогда не вызывал интереса. Экзотику типа Svelte для первого знакомства мы не берём точно. В выбранный инструмент углубляться можно сколько угодно долго. Работу я бы начал искать после написания 3-5 серьёзных пет-проектов
Лучшие видео по React и Vue на канале Ulbi TV
6. NodeJS
Кто бы что ни говорил, я уверен, что NodeJS фронтендер знать обязан хотя бы на базовом уровне. Необходимо понимать что такое express, как обрабатываются заголовки, куки, полезная нагрузка запроса и тд.
Лучшие видео по NodeJS на канале Ulbi TV
Дальнейший путь вы можете обсудить со своим ментором, но я уверен, что 9/10 человек смогут и без ментора понять куда двигаться дальше на таком уровне. Если будут ещё вопросы, не стесняйтесь спросить в комментах.
Также абсолютно всем без исключения советую именно это видео. Ничего лучше вы не найдёте.
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #web #blog #useful
Ноги подкашиваются, руки трясутся, паника, в глазах потемнело… Типичная реакция человека, который вчера только на уроках программирования в школе в экселе сидел, а сегодня увидел перечень необходимых навыков для реализации ToDo-листа.
В этом посте выдам своё ИМХО для первых шагов в фронтенде. Как раз зафиксирую все необходимые ссылки, чтобы не писать одно и то же каждый раз. Далее я описываю конкретные шаги, которые нужно пройти последовательно:
1. Базовое понимание вёрстки, среды разработки
Вёрстка — это основа веб страницы. Нужно понимать какие есть теги и как они используются, уметь стилизовать элементы страницы и переиспользовать уже готовые части кода. В моём понимании, джун — тот, кто может худо-бедно сверстать ozon.ru
Лучший плейлист по вёрстке на русском языке
2. Система контроля версий
Важная часть, которую необходимо изучать сразу же после того, как вы сверстаете свои первые значимые странички. Пункт зачтён, когда на каждый проект вы умеете создавать репозиторий, владеете
git add, commit, push, pull, checkout, fetch
Лучшая базовая статья по гиту
3. JavaScript
Ура, программирование. Нужно уметь решать алгоритмические задачи easy уровня с leetcode.com, понимать что такое DOM, события, event loop, замыкание. Тут важно сделать акцент на взаимодействии с HTML — добавление и удаление элементов на страницу, изменение их состояния, базовые умения работать с сетью по HTTP. Чем больше вы проведете времени на этом этапе, тем лучше. Рынку не нужны “React-программисты”. Знать базу очень важно. Аналогия очень простая: без хорошего понимания что такое
sin
и cos
, вас никто не заставит решать квадратные тригонометрические уравнения. Не надо лезть во всякие реакты, прежде чем вы не знаете базыЛучшее видео по JavaScript
4. TypeScript
На хорошую JS базу отлично ляжет TypeScript. Переходить к фреймворкам/библиотекам без TypeScript’a я вообще не вижу смысла.
Лучший базовый плейлист по TypeScript
5. Выбор фреймворка
Абсолютно всё равно что вы возьмёте для первоначального знакомства. Я глубоко убежден, что, например, из Vue в React и обратно, реально перекатиться за два полных рабочих дня. Да, вы не будете знать абсолютно всех мелочей, но сможете писать адекватный код. Лично я, если бы начинал, выбрал бы Vue или React. Без объяснения причин, мне просто прикольно поизучать их. Ангуляр никогда не вызывал интереса. Экзотику типа Svelte для первого знакомства мы не берём точно. В выбранный инструмент углубляться можно сколько угодно долго. Работу я бы начал искать после написания 3-5 серьёзных пет-проектов
Лучшие видео по React и Vue на канале Ulbi TV
6. NodeJS
Кто бы что ни говорил, я уверен, что NodeJS фронтендер знать обязан хотя бы на базовом уровне. Необходимо понимать что такое express, как обрабатываются заголовки, куки, полезная нагрузка запроса и тд.
Лучшие видео по NodeJS на канале Ulbi TV
Дальнейший путь вы можете обсудить со своим ментором, но я уверен, что 9/10 человек смогут и без ментора понять куда двигаться дальше на таком уровне. Если будут ещё вопросы, не стесняйтесь спросить в комментах.
Также абсолютно всем без исключения советую именно это видео. Ничего лучше вы не найдёте.
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #web #blog #useful
❤35👍15🔥8🐳3😍1🍌1
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 1);
}
for (let i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 1);
}
@prog_way_blog — чат — #quiz
🐳10❤3🍌1
👍12🐳7🍌1
JavaScript там, где не ждали
Просто интересностей пост. Общались с одним из подписчиков на тему интересных кейсов применения JS и возникла идея описать их отдельным постом, подписчику привет. А вот и он.
Вообще, JavaScript многие воспринимают как язык веб-фронтенда. В последнее время для людей также прижилось его применение в разработке бекенда, например, на NodeJS, и мобильных приложений на чём-то типа React Native или ionic.
К сожалению или к счастью, это далеко не единственные варианты применения языка. Например, на JS легко можно программировать микроконтроллеры. Вот уж точно враг там, где не ждали. Есть множество различных интерпретаторов и библиотек JavaScript’a для микроконтроллеров, но самая популярная — это Espruino.
Вся эта экосистема открывает для языка такие области, как робототехника, встроенные системы, интернет вещей и т.д. То есть на JavaScript можно запрограммировать тостер, так что больше не жалуйтесь, когда вас просят его починить по причине “ты ж программист”
Также не забываем, что JavaScript отлично подходит для визуализации чего либо. Его можно использовать в научной среде для формализации данных, разработки игр, в том числе HTML5 игр, разрабатывать интерфейсы для банкоматов, касс самообслуживания, рекламных баннеров, интернет-меню, использовать для визуализации трёхмерных объектов с использованием чего-то типа three.js.
Также для JavaScript есть множество библиотек типа web3.js, с помощью которых можно взаимодействовать с удаленными нодами в распределенных сетях.
На JavaScript можно написать даже собственное окружение рабочего стола линукса! Вот, пожалуйста.
Ну и не будем списывать со счетов тонну библиотек. Кажется, что библиотеки есть уже буквально под всё.
Разные примеры применения JavaScript'a c фото — в комментариях)
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #javascript
Просто интересностей пост. Общались с одним из подписчиков на тему интересных кейсов применения JS и возникла идея описать их отдельным постом, подписчику привет. А вот и он.
Вообще, JavaScript многие воспринимают как язык веб-фронтенда. В последнее время для людей также прижилось его применение в разработке бекенда, например, на NodeJS, и мобильных приложений на чём-то типа React Native или ionic.
К сожалению или к счастью, это далеко не единственные варианты применения языка. Например, на JS легко можно программировать микроконтроллеры. Вот уж точно враг там, где не ждали. Есть множество различных интерпретаторов и библиотек JavaScript’a для микроконтроллеров, но самая популярная — это Espruino.
Вся эта экосистема открывает для языка такие области, как робототехника, встроенные системы, интернет вещей и т.д. То есть на JavaScript можно запрограммировать тостер, так что больше не жалуйтесь, когда вас просят его починить по причине “ты ж программист”
Также не забываем, что JavaScript отлично подходит для визуализации чего либо. Его можно использовать в научной среде для формализации данных, разработки игр, в том числе HTML5 игр, разрабатывать интерфейсы для банкоматов, касс самообслуживания, рекламных баннеров, интернет-меню, использовать для визуализации трёхмерных объектов с использованием чего-то типа three.js.
Также для JavaScript есть множество библиотек типа web3.js, с помощью которых можно взаимодействовать с удаленными нодами в распределенных сетях.
На JavaScript можно написать даже собственное окружение рабочего стола линукса! Вот, пожалуйста.
Ну и не будем списывать со счетов тонну библиотек. Кажется, что библиотеки есть уже буквально под всё.
Разные примеры применения JavaScript'a c фото — в комментариях)
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #javascript
❤23🐳7💯4👍3🔥2🍌1
Сколько времени читается статья?
Очень интересная фишка в блогах и на других текстовых сайтах — указывать рядом со статьёй время её чтения. Видели что-то подобное: “Время чтения: менее 5 минут”?
Реализовать это максимально просто, для этого нужно два вводных параметра:
— количество символов в статье
— количество картинок в статье
В среднем, взрослый человек может прочитать за 1 минуту 1500 символов, а каждую картинку просмотреть за 12 секунд. Из этих параметров не сложно получить время прочтения в секундах:
А далее секунды можно легко форматировать в читаемый промежуток времени через конструкцию
Кода получается совсем не много, зато мы сильно улучшаем UX. Есть идеи какие ещё фишки можем разобрать? Пишите в комментарии)
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #code
Очень интересная фишка в блогах и на других текстовых сайтах — указывать рядом со статьёй время её чтения. Видели что-то подобное: “Время чтения: менее 5 минут”?
Реализовать это максимально просто, для этого нужно два вводных параметра:
— количество символов в статье
— количество картинок в статье
В среднем, взрослый человек может прочитать за 1 минуту 1500 символов, а каждую картинку просмотреть за 12 секунд. Из этих параметров не сложно получить время прочтения в секундах:
const CHARACTERS_PER_MINUTE = 1500;
const SECONDS_PER_IMAGE = 12;
const SECONDS_IN_MINUTE = 60;
const calculateReadingTimeInSeconds = (articleLength: number, numberOfImages = 0) => {
const charactersReadingTime =
articleLength / CHARACTERS_PER_MINUTE * SECONDS_IN_MINUTE;
const imagesReadingTime = numberOfImages * SECONDS_PER_IMAGE;
const readingTime = Math.ceil(charactersReadingTime + imagesReadingTime);
return readingTime;
}
А далее секунды можно легко форматировать в читаемый промежуток времени через конструкцию
switch (true)
, например, вот так:const formatReadingTime = (seconds: number) => {
switch (true) {
case seconds < SECONDS_IN_MINUTE:
return "Менее 1 минуты"
case seconds < SECONDS_IN_MINUTE * 5:
return "Менее 5 минут"
case seconds >= SECONDS_IN_MINUTE * 5:
return "Более 5 минут"
default:
return null
}
}
Кода получается совсем не много, зато мы сильно улучшаем UX. Есть идеи какие ещё фишки можем разобрать? Пишите в комментарии)
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #code
❤27🔥16👍4🐳1
Дженерики
Сколько я не бился в попытках объяснить что такое дженерик, кажется, что эта тема многим даётся тяжело. В этом канале я планирую написать несколько постов на эту тему, в которых разберу самые частые варианты использования дженериков на практике начиная от легкого к сложному. И начнем с самого простого:
Generic Type — обобщённый тип — это тип, который позволяет создавать по своему подобию другие типы или же динамически вычислять типы в зависимости от входных данных. Тут я максимально отойду от какой-то академичности и приведу простую аналогию:
Тип — это переменная
Дженерик тип — это функция, которая возвращает тип
И дженерик типы называть функциями в корне неверно, зато такая аналогия для начала будет понятна большинству. Разберем на примере:
В этом примере у нас есть переменная, на основе которой мы можем получить некоторый объект
Уже в этом примере мы наблюдаем чем-то похожую ситуацию коду выше — мы создаём какую-то новую сущность на основе уже существующей. В первом случае — новый объект, а во втором — новый тип.
В таком контексте дженерики можно воспринимать как функции-конструкторы, которые, основываясь на некоторых входных параметрах, могут создавать новые типы. И из всего этого можно сделать вывод, что дженерики — это конструкторы типов.
На этом моменте у многих новичков часто возникает закономерный вопрос — а зачем их использовать? И ответ на него очень прост — почти за тем же, что и обычные функции.
Дженерик типы позволяют не дублировать код, а выносить некоторые общие части, чтобы далее их переиспользовать. Попробуем написать уже такой код, что легко встретится на практике:
В этом случае мы создали тип конструктор
Это самый базовый пример использования дженериков, который может встретиться на практике. Не забывайте, что дженерики есть не только у типов, а и у интерфейсов, классов, функций… Даже у React-компонентов и хуков (что в целом тоже либо класс либо функция).
Примеры с другими сущностями тоже хотелось бы показать, но уже в рамках других постов.
Спасибо за прочтение, это важно для меня ❤️
#web #theory #typescript
Сколько я не бился в попытках объяснить что такое дженерик, кажется, что эта тема многим даётся тяжело. В этом канале я планирую написать несколько постов на эту тему, в которых разберу самые частые варианты использования дженериков на практике начиная от легкого к сложному. И начнем с самого простого:
Generic Type — обобщённый тип — это тип, который позволяет создавать по своему подобию другие типы или же динамически вычислять типы в зависимости от входных данных. Тут я максимально отойду от какой-то академичности и приведу простую аналогию:
Тип — это переменная
Дженерик тип — это функция, которая возвращает тип
И дженерик типы называть функциями в корне неверно, зато такая аналогия для начала будет понятна большинству. Разберем на примере:
const name = "Denis"
const getPerson = (name) => ({
name,
type: "person"
})
const person = getPerson(name)
В этом примере у нас есть переменная, на основе которой мы можем получить некоторый объект
person
используя функцию getPerson
. А теперь рассмотрим нечто похожее в типах:type Status = "success" | "error"
type Response<T> = {
status: T,
message: string,
code: number,
}
type ApiResponse = Response<Status>
Уже в этом примере мы наблюдаем чем-то похожую ситуацию коду выше — мы создаём какую-то новую сущность на основе уже существующей. В первом случае — новый объект, а во втором — новый тип.
В таком контексте дженерики можно воспринимать как функции-конструкторы, которые, основываясь на некоторых входных параметрах, могут создавать новые типы. И из всего этого можно сделать вывод, что дженерики — это конструкторы типов.
На этом моменте у многих новичков часто возникает закономерный вопрос — а зачем их использовать? И ответ на него очень прост — почти за тем же, что и обычные функции.
Дженерик типы позволяют не дублировать код, а выносить некоторые общие части, чтобы далее их переиспользовать. Попробуем написать уже такой код, что легко встретится на практике:
// объявим сущности приложения
type User = {
name: string,
age: number,
}
type Task = {
completed: boolean,
title: string,
}
// ответ api в случае ошибки
type ResponseError = {
code: number;
message: string;
}
// ответ api в случае успеха
type ListResponseSuccess<T> = {
data: T[],
total: number;
}
// общий тип со всеми возможными
// состояниями ответа
type ListResponse<T> = ListResponseSuccess<T> | ResponseError
// типы для наших сущностей
type UserListResponse = ListResponse<User>
type TaskListReponse = ListResponse<Task>
// и их может быть сколько угодно...
type CarListResponse = ListResponse<Car>
type RoleListResponse = ListResponse<Role>
type UserGroupListResponse = ListResponse<UserGroup>
// и тд
В этом случае мы создали тип конструктор
ListResponse
, который в дальнейшем сможем использовать для типизации всего нашего API без лишнего дублирования общих частей.Это самый базовый пример использования дженериков, который может встретиться на практике. Не забывайте, что дженерики есть не только у типов, а и у интерфейсов, классов, функций… Даже у React-компонентов и хуков (что в целом тоже либо класс либо функция).
Примеры с другими сущностями тоже хотелось бы показать, но уже в рамках других постов.
Спасибо за прочтение, это важно для меня ❤️
#web #theory #typescript
🔥29👍12❤4🤯1🐳1
const shape = {
radius: 10,
diameter() {
return this.radius * 2;
},
perimeter: () => 2 * Math.PI * this.radius,
};
console.log(shape.diameter());
console.log(shape.perimeter());
@prog_way_blog — чат — #quiz
🔥7🐳3
👍13🐳4🔥1
Шпаргалка по Utility-типам в TypeScript
В этом посте разберу только самые часто используемые, посмотреть все utility-типы можно в официальной документации.
Делает все ключи необязательными
Обратное действие
Запрещает изменять поля объекта
Создаёт тип из ключей и значений, указанных отдельно
Выбирает только нужные ключи из типа и возвращает новый тип
Удаляет ненужные свойства из типа и возвращает новый тип
Возвращает тип параметров функции
Возвращает тип возвращаемого параметра из функции
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #typescript #useful
В этом посте разберу только самые часто используемые, посмотреть все utility-типы можно в официальной документации.
type Person = {
name: string;
surname: string;
age: number
}
Partial<T>
Делает все ключи необязательными
type PartialPerson = Partial<Person>
// то же самое, что
type PartialPerson = {
name?: string;
surname?: string;
age?: number
}
Required<T>
Обратное действие
Partial
— делает все ключи обязательнымиRequired<Partial<Person>> === Person
Readonly<Type>
Запрещает изменять поля объекта
const person: Readonly<Person> = {
name: "Denis",
surname: "Putnov",
age: 22
}
// ошибка, так как
// person нельзя изменять,
// только считывать (readonly)
person.name = 'Денис'
Record<Keys, Values>
Создаёт тип из ключей и значений, указанных отдельно
// ключи могут быть только строкой
// значения - только числом
type WordCounter = Record<string, number>
type Status = 'success' | 'error'
type StatusCounter = Record<Status, number>
// то же самое, что и Record ранее
type StatusCounter = {
success: number
error: number
}
Pick<Type, Keys>
Выбирает только нужные ключи из типа и возвращает новый тип
// из типа Person выбираем только свойства
// name и surname
type PersonName = Pick<Person, 'name' | 'surname'>
// то же самое
type PersonName = {
name: string
surname: string
}
Omit<Type, Keys>
Удаляет ненужные свойства из типа и возвращает новый тип
// Из типа Person исключаем свойство 'age'
type PersonName = Omit<Person, 'age'>;
// то же самое
type PersonName = {
name: string
surname: string
}
Parameters<Function>
Возвращает тип параметров функции
type Foo = (a: number, b: number) => string
type Params = Parameters<Foo>
Params // [a: number, b: number]
ReturnType<Function>
Возвращает тип возвращаемого параметра из функции
type Foo = (a: number, b: number) => string
type Return = ReturnType<Foo>
Return // string
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #typescript #useful
🔥40❤8👍5🐳4
Че там в React 19
У меня сейчас, к сожалению или к счастью, нет времени полностью посмотреть React Conf, которая длится аж 4 часа, что имхо очень много.
Я пролистал конфу и нашёл пару интересных моментов, которыми хочу поделиться тут.
Как я понял, React Compiler — это что-то, что стоит сравнивать скорее с компилятором TypeScript. Также один из спикеров сравнивает его с компиляторами типа WebAssembly и Hermes, который сейчас используется в React Native. По сути, всё, что он делает — разбирает весь ваш код и представляет его в виде полностью контролируемого графа. Сам по себе компилятор содержит очень много оптимизаций, типа автоматического удаления неиспользуемого кода, распространения констант и ещё куча умных слов. Все эти техники оптимизации не новы, но спикеры подмечают, что, конечно же, подсосали всё из Rust и C++, что не удивительно.
Цель такого компилятора — дополнительно оптимизировать весь наш код без видимых изменений для разработчика, тем самым улучшить и DX, и UX.
Что наиболее интересно — компилятор приносит нам такое интересное понятие как Computation Graph. Как я понимаю, это понятие мы ещё не раз услышим в будущем.
Computation Graph — граф, который отображает вычислительные зависимости между сущностями в коде. Показывает то, каким образом данные влияют на другие данные и на вёрстку в целом. Что-то типа
Тут обращаем внимание на скрины. Со 2 по 6 мы видим то, что такое Computation Graph и как он получается из нашего кода. На 7 скрине мы видим как это работает. Из полученного графа мы можем узнать минимально нужный перечень сущностей для обновления, то есть что конкретно мы хотим обновить, при этом не затрагивая остальные несвязанные ветви графа.
Во что конкретно компилятор собирает это — я пока не досмотрел. Но даже эта ограниченная информация — очень интересно)
@prog_way_blog — чат — #theory #react #news
У меня сейчас, к сожалению или к счастью, нет времени полностью посмотреть React Conf, которая длится аж 4 часа, что имхо очень много.
Я пролистал конфу и нашёл пару интересных моментов, которыми хочу поделиться тут.
Как я понял, React Compiler — это что-то, что стоит сравнивать скорее с компилятором TypeScript. Также один из спикеров сравнивает его с компиляторами типа WebAssembly и Hermes, который сейчас используется в React Native. По сути, всё, что он делает — разбирает весь ваш код и представляет его в виде полностью контролируемого графа. Сам по себе компилятор содержит очень много оптимизаций, типа автоматического удаления неиспользуемого кода, распространения констант и ещё куча умных слов. Все эти техники оптимизации не новы, но спикеры подмечают, что, конечно же, подсосали всё из Rust и C++, что не удивительно.
Цель такого компилятора — дополнительно оптимизировать весь наш код без видимых изменений для разработчика, тем самым улучшить и DX, и UX.
Что наиболее интересно — компилятор приносит нам такое интересное понятие как Computation Graph. Как я понимаю, это понятие мы ещё не раз услышим в будущем.
Computation Graph — граф, который отображает вычислительные зависимости между сущностями в коде. Показывает то, каким образом данные влияют на другие данные и на вёрстку в целом. Что-то типа
useMemo
и других хуков, когда мы напрямую указывали реакту, изменение чего конкретно нужно отслеживать и что конкретно нужно пересчитать. Теперь этим полностью занимается компилятор. Тут обращаем внимание на скрины. Со 2 по 6 мы видим то, что такое Computation Graph и как он получается из нашего кода. На 7 скрине мы видим как это работает. Из полученного графа мы можем узнать минимально нужный перечень сущностей для обновления, то есть что конкретно мы хотим обновить, при этом не затрагивая остальные несвязанные ветви графа.
Во что конкретно компилятор собирает это — я пока не досмотрел. Но даже эта ограниченная информация — очень интересно)
@prog_way_blog — чат — #theory #react #news
👍24❤5🔥2🤯1🐳1
Какие ошибки есть в JavaScirpt?
Уже не помню где, скорее всего в чате канала, просили разобрать какие есть ошибки в языке. Вот и этот пост.
Что вообще такое ошибка? Ошибка — ответ программы на возможное неожиданное, некорректное поведение. Всего в JavaScript существует всего 7 встроенных ошибок, но также есть возможность создавать собственные, что я уже разбирал в отдельном посте ранее.
Также важно знать, что в языке есть встроенная конструкция
Этой вводной должно быть достаточно, перейдём к самим ошибкам:
Как вы можете видеть, ошибок очень мало. Последние три встречаются так редко, что их буквально можно не учитывать. Практически любая библиотека или фреймворк предоставляют собственный набор ошибок, поэтому придётся обращать внимание и на них. К счастью, большинство из них имеют достаточно подробное описание уже в самой консоли.
Пост вдохновлён статьей с доки
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #javascript
Уже не помню где, скорее всего в чате канала, просили разобрать какие есть ошибки в языке. Вот и этот пост.
Что вообще такое ошибка? Ошибка — ответ программы на возможное неожиданное, некорректное поведение. Всего в JavaScript существует всего 7 встроенных ошибок, но также есть возможность создавать собственные, что я уже разбирал в отдельном посте ранее.
Также важно знать, что в языке есть встроенная конструкция
try {
// потенциально ошибочный код
} catch (error) {
// обработка ошибки из
// участка кода выше
}
Этой вводной должно быть достаточно, перейдём к самим ошибкам:
SyntaxError
— ошибка, связанная с некорректным синтаксисом в программе, то есть некорректной, постановкой скобок, точек с запятой и прочих символов:console.log(()
// Uncaught SyntaxError: Unexpected token ')'
Reference Error
— возникает при попытке обратиться к несуществующей переменнойprogway.length
// ReferenceError: progway is not defined
Type Error
— возникает при попытке обратиться к несуществующему свойству объекта или попытке вызвать то, что вызвать нельзяconsole.log(null.length)
// TypeError: Cannot read property 'length' of null
undefined()
// TypeError: undefined is not a function
Range Error
— возникает, когда мы выходим за диапазон допустимых значенийnew Array(10_000_000_000)
// RangeError: Недопустимая длина массива
URIError
— возникает при некорректной обработке URI встроенными средствами языкаdecodeURIComponent('%')
// URIError: URI malformed
Eval Error
— по сути, любая вышеперечисленная ошибка внутри функции eval
eval('progway.length')
Как вы можете видеть, ошибок очень мало. Последние три встречаются так редко, что их буквально можно не учитывать. Практически любая библиотека или фреймворк предоставляют собственный набор ошибок, поэтому придётся обращать внимание и на них. К счастью, большинство из них имеют достаточно подробное описание уже в самой консоли.
Пост вдохновлён статьей с доки
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #javascript
🔥20👍9❤4🐳1🤓1
В чём разница между функцией, методом и процедурой
Функция и метод — это два базовых понятия в программировании, но они используются в разных контекстах.
1. Функция — полностью независимый блок, который может быть объявлен где угодно в коде. Каждая функция возвращает значение и может принимать аргументы:
2. Процедура — то же самое, что и функция, но процедура лишь выполняет какие-то действия, но ничего не возвращает:
3. Метод — то же самое, что функция или процедура, но принадлежащая определенному объекту или классу. Всегда вызывается от родительской сущности через точечную нотацию:
Принципиально ли использовать правильные названия для каждого из случаев? Для такого душнилы, как я, — да. Я считаю, что верная терминология делает любой разговор более продуктивным и предметным, чем “ну вот это фигня там вот с этой фигней”. Понять друг друга можно и без терминологии, но с ней — гораздо проще. Да и звучите вы профессиональнее, если это для кого-то важно.
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #javascript
Функция и метод — это два базовых понятия в программировании, но они используются в разных контекстах.
1. Функция — полностью независимый блок, который может быть объявлен где угодно в коде. Каждая функция возвращает значение и может принимать аргументы:
// самая настоящая функция, причём чистая
function add(a, b) {
return a + b;
}
2. Процедура — то же самое, что и функция, но процедура лишь выполняет какие-то действия, но ничего не возвращает:
// что-то делаем, но ничего не возвращаем
function greet(name) {
console.log("Hello, " + name);
}
3. Метод — то же самое, что функция или процедура, но принадлежащая определенному объекту или классу. Всегда вызывается от родительской сущности через точечную нотацию:
let obj = {
x: 4,
// метод
double: function() {
return this.x * 2;
}
};
let result = obj.double();
console.log(result); // Выведет: 8
Принципиально ли использовать правильные названия для каждого из случаев? Для такого душнилы, как я, — да. Я считаю, что верная терминология делает любой разговор более продуктивным и предметным, чем “ну вот это фигня там вот с этой фигней”. Понять друг друга можно и без терминологии, но с ней — гораздо проще. Да и звучите вы профессиональнее, если это для кого-то важно.
Спасибо за прочтение, это важно для меня ❤️
@prog_way_blog — чат — #theory #javascript
🔥33👍17❤5👏1🐳1