Лонгрид о JavaScript
JavaScript — ужасный язык программирования. По сравнению с другими распространёнными языками он выглядит генетическим уродом. Дело даже не в отсутствии многопоточности, или статической типизации, или того, что node-modules для простого проекта занимают сотни мегабайт, а в том, что в JavaScript столько стилей и подходов, что семь человек одну и ту же несложную задачу могут написать на нём семью различными способами. Каждый из них с трудом будет понимать, что написал другой, и тихо материться. Причем, так напишут и новички, и опытные программисты, которые просто привыкли писать по‑своему или захотели выпендриться.
Ссылка
#статьи
JavaScript — ужасный язык программирования. По сравнению с другими распространёнными языками он выглядит генетическим уродом. Дело даже не в отсутствии многопоточности, или статической типизации, или того, что node-modules для простого проекта занимают сотни мегабайт, а в том, что в JavaScript столько стилей и подходов, что семь человек одну и ту же несложную задачу могут написать на нём семью различными способами. Каждый из них с трудом будет понимать, что написал другой, и тихо материться. Причем, так напишут и новички, и опытные программисты, которые просто привыкли писать по‑своему или захотели выпендриться.
Ссылка
#статьи
const user = {
email: "my@email.com",
updateEmail: email => {
this.email = email
}
}
user.updateEmail("new@email.com")
console.log(user.email)Что будет на выходе?
Anonymous Quiz
30%
my@email.com
54%
new@email.com
11%
undefined
5%
ReferenceError
Пояснение к ответу
Функция updateEmail представляет собой стрелочную функцию и не привязана к объекту пользователя. Это означает, что ключевое слово this не относится к объекту user, а в данном случае относится к глобальной области видимости. Значение email в объекте user не обновляется. При регистрации значения ||user.email|| возвращается исходное значение ||my@email.com||.
Почему реактивность без VDOM (с реальным DOM) лучше, чем реактивность с VDOM?
В этой статье я хотел бы поделиться своими мыслями о том, почему виртуального DOM можно избежать при создании реактивности сегодня. Я работаю со всем этим уже около полутора лет, создавая фреймворк Cample.js, и у меня есть некоторые соображения по этому поводу.
Ссылка
#framework
В этой статье я хотел бы поделиться своими мыслями о том, почему виртуального DOM можно избежать при создании реактивности сегодня. Я работаю со всем этим уже около полутора лет, создавая фреймворк Cample.js, и у меня есть некоторые соображения по этому поводу.
Ссылка
#framework
const promise1 = Promise.resolve('First')
const promise2 = Promise.resolve('Second')
const promise3 = Promise.reject('Third')
const promise4 = Promise.resolve('Fourth')
const runPromises = async () => {
const res1 = await Promise.all([promise1, promise2])
const res2 = await Promise.all([promise3, promise4])
return [res1, res2]
}
runPromises()
.then(res => console.log(res))
.catch(err => console.log(err))Что будет на выходе?
Anonymous Quiz
23%
[['First', 'Second'], ['Fourth']]
35%
[['First', 'Second'], ['Third', 'Fourth']]
21%
[['First', 'Second']]
22%
'Third'
Пояснение к ответу
Метод Promise.all выполняет переданные промисы параллельно. Если одно обещание не выполняется, метод Promise.all отколняется со значением отклоненного обещания. В этом случае promise3 отклонен со значением "Third". Мы перехватываем отклоненное значение в цепочке методов catch при вызове runPromises, чтобы перехватывать любые ошибки внутри функции runPromises. Только "Third" регистрируется, так как promise3 отклонено с этим значением.
Этот опасный рефакторинг
Ошибки во время рефакторинга могут дорого обойтись. Модернизация, ведущая к отказу системы, или внесение новой функциональности параллельно с ошибочными правками явно принесут вред. Но степень вреда может быть разной.
Любой рефакторинг сопряжён с рисками
Доработка кода – это рисковая затея, поскольку подразумевает изменение работающей системы. Всё верно. Но во многих ситуациях разработчики могут снизить эти риски, сделав их допустимыми.
Ссылка
#статьи
Ошибки во время рефакторинга могут дорого обойтись. Модернизация, ведущая к отказу системы, или внесение новой функциональности параллельно с ошибочными правками явно принесут вред. Но степень вреда может быть разной.
Любой рефакторинг сопряжён с рисками
Доработка кода – это рисковая затея, поскольку подразумевает изменение работающей системы. Всё верно. Но во многих ситуациях разработчики могут снизить эти риски, сделав их допустимыми.
Ссылка
#статьи
const keys = ["name", "age"]
const values = ["Lydia", 22]
const method = /* ?? */
Object[method](keys.map((_, i) => {
return [keys[i], values[i]]
})) // { name: "Lydia", age: 22 }
Каким должно быть значение method для регистрации { name: "Lydia", age: 22 }?
Anonymous Quiz
23%
entries
24%
values
40%
fromEntries
13%
forEach
Пояснение к ответу
Метод fromEntries превращает двумерный массив в объект. Первый элемент в каждом подмассиве будет ключом, а второй элемент в каждом подмассиве будет значением. В этом случае мы сопоставляем массив keys, который возвращает массив, первый элемент которого является элементом массива ключей текущего индекса, а второй элемент является элементом массива значений текущего индекса.
Это создает массив подмассивов, содержащих правильные ключи и значения, что приводит к { name: "Lydia", age: 22 }
Это создает массив подмассивов, содержащих правильные ключи и значения, что приводит к { name: "Lydia", age: 22 }
Деструктуризация в React. Очевидно, но важно
Деструктуризация, которая появилась в стандарте ES6, уже не вызывает вопросов у многих из нас, есть большое количество статей, раскрывающих ее возможности. В основном, мы все тесно с ней дружим и пользуемся.
Казалось бы, что можно рассказать о том, о чем все и так знают? Но практика и чтение статей на Хабре, показали, что есть некоторые нюансы использования деструктуризации в React, о которых не все из нас знают или просто не задумываются, хотя они и являются очевидными.
Ссылка
#статьи
Деструктуризация, которая появилась в стандарте ES6, уже не вызывает вопросов у многих из нас, есть большое количество статей, раскрывающих ее возможности. В основном, мы все тесно с ней дружим и пользуемся.
Казалось бы, что можно рассказать о том, о чем все и так знают? Но практика и чтение статей на Хабре, показали, что есть некоторые нюансы использования деструктуризации в React, о которых не все из нас знают или просто не задумываются, хотя они и являются очевидными.
Ссылка
#статьи
const createMember = ({ email, address = {}}) => {
const validEmail = /.+@.+\..+/.test(email)
if (!validEmail) throw new Error("Valid email pls")
return {
email,
address: address ? address : null
}
}
const member = createMember({ email: "my@email.com" })
console.log(member)Пояснение к ответу
Значением по умолчанию для address является пустой объект {}. Когда мы устанавливаем переменную member равной объекту, возвращаемому функцией createMember, мы не передаем значение для адреса, что означает, что значение адреса является пустым объектом по умолчанию {}. Пустой объект является истинным значением, что означает, что условие address ? address : null условно возвращает true. Значением адреса является пустой объект {}.
Анатомия Htmx
htmx — это библиотека, которая предоставляет доступ к AJAX, переходам CSS, WebSockets и Server Sent Events прямо из HTML через атрибуты, что позволяет создавать современные пользовательские интерфейсы (насколько сложные — другой вопрос), пользуясь простотой и мощью гипертекста. На сегодняшний день у библиотеки почти 30 000 звезд на Github. Удивительно, что до такого решения мы додумались только сейчас, учитывая, что весь функционал был доступен уже 10 лет назад (вы сами убедитесь в этом, когда мы изучим исходный код htmx).
Ссылка
#статьи
htmx — это библиотека, которая предоставляет доступ к AJAX, переходам CSS, WebSockets и Server Sent Events прямо из HTML через атрибуты, что позволяет создавать современные пользовательские интерфейсы (насколько сложные — другой вопрос), пользуясь простотой и мощью гипертекста. На сегодняшний день у библиотеки почти 30 000 звезд на Github. Удивительно, что до такого решения мы додумались только сейчас, учитывая, что весь функционал был доступен уже 10 лет назад (вы сами убедитесь в этом, когда мы изучим исходный код htmx).
Ссылка
#статьи
let randomValue = { name: "Lydia" }
randomValue = 23
if (!typeof randomValue === "string") {
console.log("It's not a string!")
} else {
console.log("Yay it's a string!")
}Что будет на выходе?
Anonymous Quiz
50%
It's not a string!
33%
Yay it's a string!
14%
TypeError
2%
undefined
Пояснение к посту
Условие в операторе if проверяет, равно ли значение !typeof randomValue "строке". Оператор ! преобразует значение в логическое значение. Если значение истинно, возвращаемое значение будет "ложным", если значение ложным, возвращаемое значение будет "истинным". В этом случае возвращаемое значение typeof randomValue является истинным значением "number", что означает, что значение !typeof randomValue является логическим значением false.
!typeof randomValue === "string" всегда возвращает false, поскольку на самом деле мы проверяем false === "string". Поскольку условие вернуло false, запускается блок кода оператора else, и в журнал заносится сообщение Yay it's a string!.
!typeof randomValue === "string" всегда возвращает false, поскольку на самом деле мы проверяем false === "string". Поскольку условие вернуло false, запускается блок кода оператора else, и в журнал заносится сообщение Yay it's a string!.