Автор REST в своей диссертации , в которой он собственно представил REST, очень явно обосновывает свое решение ссылаясь на другую работу, ссылку на которую я также привел в статье. Суть архитектуры в том, что она явно обозначает ограничения которые должны быть соблюдены для достижения результата, при этом архитектура не диктует «как» реализовывать. Он пишет:
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request
То есть stateless – не REST, а «коммуникация» между клиентом и сервером. Это в том числе вытекает из ограничений остальных компонентов системы, например транспорта. Каждый TCP пакет в последовательности должен содержать идентификатор соединения, каждый Request должен содержать идентификатор пользователя и т.д.
Тоже остается справедливым и для фронтенда, где каждый Request (Event), содержит всю необходимую информацию. Когда мы пишем el.addEventListener('input', cb), браузер передает не просто строку с новым текстом, полагая что мы понимаем от какого именно <input /> оно пришло, а Event со всей необходимой информацией, делая нашу «шину» stateless по природе.
Имеется ввиду что map, filter и т.д. возвращают промисы? Это же принесет больше проблем, нет? Что если там девять элементов, и на обработке шестого произошла ошибка? Или например map отработал, а на reduce в третьем элементе произошла ошибка?
А причем тут вообще роутер? Я про кнопку в браузере. Она уже есть, работает как надо, и ею пользуются. Вы же не делаете в интерфейсе адресную строку, чтобы пользователь вводит туда ссылки на ваш же сайт, а кнопку назад для чего делаете? Я этого не понимаю. Еще я ожидаю, что если она вдруг зачем-то есть, то работает также как в браузере, а в описанным вами сценарии это не так. Если я перешел на страницу товара сразу, например из результатов выдачи Гугла, то при нажатии назад, я хочу вернуться назад, то есть в результаты выдачи Гугла, а не на страницу с вашим каталогом которую я вовсе не посещал.
Ограничения c H.265 в веб-браузерах больше лицензионные
Это больше миф. Не все видеокарты умеют декодировать этот кодек, и если у вас ни одно видео не работает, значит или вообще нет видеокарты, или она старая, или в браузере выключена настройка hardware acceleration.
Все современные браузеры этот кодек поддерживают (если железо его поддерживает), а прошлым летом его занесли даже в WebRTC.
Автор явно не работал с этим серьезно. Тогда бы он упомянул то, о чем я написал в комментариях выше, а главное про то, что некоторые вендоры, особенно Китайцы, спецом ломают профиль, что бы видео нормально работало только в их клиентах. Я двух таких нашел, поток разбирал, смотрел каждый пакет, и искал в чем же косяк. Берут какой-то байт подменяют другим значением, из-за чего некорректно формируется профиль, условно говоря вместо hev1.2.3.e получается hev1.2.3.f — и вуаля, любой клиент говорит «я не знаю что это за кодек, воспроизвести не могу».
А в главном автор как раз ошибается. При одинаковых пресетах, и в одинаковых условиях (освещение, сцена и пр), две камеры разных производителей на одном и том же кодеке ведут себя вполне одинаково.
Что-то я не понял. Статья содержит очень много повторений одной и той же мысли, а главное — суть умещается в одну фразу: Есть кодеки, например H264 или H265, и у каждого кодека есть набор профилей, а от профиля зависит все остальное: битрейт, степень сжатия, фпс и прочее. Между H265 с восьми-битным 2К профилем и H265 шестнадцати-битным 8К профилем — огромная разница. Один может работать в вашем браузере, второй нет, при этом оба H265.
Да кто же вам генерирует эти дурацкие заголовки?! Каждая третья статья с тем же паттерном в заголовке [я/мы/он/она] [чё-то там] — и вот [как/почему/зачем]
Zod позволяет описать схему один раз — и получить сразу и тип, и рантайм-валидацию:
import { z } from 'zod';
const UserSchema = z.object({
id: z.number(),
name: z.string(),
email: z.string().email(),
});
type User = z.infer<typeof UserSchema>; // тип выводится автоматически
const getUser = async (): Promise<User> => {
const res = await fetch('/api/user');
const data = await res.json();
return UserSchema.parse(data); // если структура не та — бросит ошибку
};
Лично для меня этот подход крайне спорный, и я его не использую из следующих соображений:
Данные пришедшие с сервера по определению валидны, так как они проходят валидацию при сохранении. Нам не нужно проверять что поле email это правда емэйл. Да – правда. Его бы не занесли в базу будь он не валидным.
Проверять нужно только соответствие контракту: ждали строку – пришла строка, ждали свойство userName – пришло userName, а не user_name.
Можно валидировать данные перед отправкой, и для этого я использую Constraint Validation – min, max, pattern и пр.
Мне не нужны какие-то непонятные схемы, мне нужна конкретная модель сущнсти, и я предпочитаю rich models.
И для этого я написал себе библиотеку, которая решает мои задачи. То что вы называете схемой, у меня – модель:
import { Transformer } from 'kr-transformer';
class UserModel {
// Тип – строка
name = '';
// Тип – число
age = 0;
// тип – булево
student = false;
setName() {
// ...какой-то метод
}
get someComputation() {
return this.age * 3;
}
}
const json1 = { name: 'John', age: 42, student: true };
const json2 = { name: 'John', age: "42", student: true };
const json3 = { name: 'John', age: 42, student: null };
const json4 = { username: 'John', age: 42, student: false };
try {
// валидный JSON, ошибок нет
const model = Transformer.fromJSON(json1, UserModel);
} catch(error) {
console.log(error) //
}
try {
// age строка – невалидно
const model = Transformer.fromJSON(json2, UserModel);
} catch(error) {
console.log(error) // Unexpected type of <age>, expect Number but receive String
}
try {
// student null – невалидно
const model = Transformer.fromJSON(json3, UserModel);
} catch(error) {
console.log(error) // ...ошибка
}
try {
// username вместо name – невалидно
const model = Transformer.fromJSON(json4, UserModel);
} catch(error) {
console.log(error) // ...ошибка
}
То есть, полученный с сервера невалидный JSON, просто превратится в модель с понятной ошибкой. Модель сама по себе тип. С моделью дальше гораздо удобнее работать чем с каким-то json-ом.
Во-вторых, можете ли Вы привести сравнительные примеры того, как одни и те же задачи решаются без применения веб-компонентов и с применением веб-компонентов.
QA инженеры на своем селениуме. Есть сторя, для нее автотесты такой же артефакт как сборка. Эти тесты живут вместе с продуктом, и прогоняются при каждом инкременте
Не пишу никаких текстов вообще, уже года 4. Просто не вижу в этом смысла. Пока я пишу код, у меня открыт браузер и я сразу проверяю работу. Потом деплой, автотесты, ручное тестирование тестировщиками и нт. Если какой-то баг и закрался — найдут пользаки в проде, а правка дело плевое. Вообще не понимаю зачем тратить время на попытки сэмулировать браузер в ноде и что-то там тестировать. Как-то начал еще playwrite тесты писать, но потом и их выкинул.
Автор REST в своей диссертации , в которой он собственно представил REST, очень явно обосновывает свое решение ссылаясь на другую работу, ссылку на которую я также привел в статье. Суть архитектуры в том, что она явно обозначает ограничения которые должны быть соблюдены для достижения результата, при этом архитектура не диктует «как» реализовывать. Он пишет:
То есть stateless – не REST, а «коммуникация» между клиентом и сервером. Это в том числе вытекает из ограничений остальных компонентов системы, например транспорта. Каждый TCP пакет в последовательности должен содержать идентификатор соединения, каждый Request должен содержать идентификатор пользователя и т.д.
Тоже остается справедливым и для фронтенда, где каждый Request (Event), содержит всю необходимую информацию. Когда мы пишем
el.addEventListener('input', cb), браузер передает не просто строку с новым текстом, полагая что мы понимаем от какого именно<input />оно пришло, а Event со всей необходимой информацией, делая нашу «шину» stateless по природе.Что вы имеете ввиду, есть пример из других яп?
Имеется ввиду что map, filter и т.д. возвращают промисы? Это же принесет больше проблем, нет? Что если там девять элементов, и на обработке шестого произошла ошибка? Или например map отработал, а на reduce в третьем элементе произошла ошибка?
А для чего это может быть нужно? Что с ними делать?
Вы из какого года пишете?
Завезли почти десят лет назад
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/AsyncIterator
Никогда бы в голову не пришло, накручивать. Даже больше скажу, для меня, как автора, мне важно не количество, а от кого эти звезды.
Я как раз про нативную браузерную кнопку назад и писал, и да, она всегда делает ровно то, что должна.
В действительности как раз все так. Браузерная кнопка назад имеет предсказуемое и стабильно поведение.
А причем тут вообще роутер? Я про кнопку в браузере. Она уже есть, работает как надо, и ею пользуются. Вы же не делаете в интерфейсе адресную строку, чтобы пользователь вводит туда ссылки на ваш же сайт, а кнопку назад для чего делаете? Я этого не понимаю. Еще я ожидаю, что если она вдруг зачем-то есть, то работает также как в браузере, а в описанным вами сценарии это не так. Если я перешел на страницу товара сразу, например из результатов выдачи Гугла, то при нажатии назад, я хочу вернуться назад, то есть в результаты выдачи Гугла, а не на страницу с вашим каталогом которую я вовсе не посещал.
Еще ни одному ПО или дезигнеру не удалось меня заставить добавить в интерфейс кнопку «назад». Она уже есть в браузере. В любом. Битва продолжается)
Это больше миф. Не все видеокарты умеют декодировать этот кодек, и если у вас ни одно видео не работает, значит или вообще нет видеокарты, или она старая, или в браузере выключена настройка hardware acceleration.
Все современные браузеры этот кодек поддерживают (если железо его поддерживает), а прошлым летом его занесли даже в WebRTC.
Пы сы — сайт не мой.
Какая дичь. Что только не придумывают, лишь бы не признавать свое помешательство на иммутабельности.
Автор явно не работал с этим серьезно. Тогда бы он упомянул то, о чем я написал в комментариях выше, а главное про то, что некоторые вендоры, особенно Китайцы, спецом ломают профиль, что бы видео нормально работало только в их клиентах. Я двух таких нашел, поток разбирал, смотрел каждый пакет, и искал в чем же косяк. Берут какой-то байт подменяют другим значением, из-за чего некорректно формируется профиль, условно говоря вместо hev1.2.3.e получается hev1.2.3.f — и вуаля, любой клиент говорит «я не знаю что это за кодек, воспроизвести не могу».
А в главном автор как раз ошибается. При одинаковых пресетах, и в одинаковых условиях (освещение, сцена и пр), две камеры разных производителей на одном и том же кодеке ведут себя вполне одинаково.
Что-то я не понял. Статья содержит очень много повторений одной и той же мысли, а главное — суть умещается в одну фразу: Есть кодеки, например H264 или H265, и у каждого кодека есть набор профилей, а от профиля зависит все остальное: битрейт, степень сжатия, фпс и прочее. Между H265 с восьми-битным 2К профилем и H265 шестнадцати-битным 8К профилем — огромная разница. Один может работать в вашем браузере, второй нет, при этом оба H265.
Тест страница с разными профилями https://lf-tk-sg.ibytedtos.com/obj/tcs-client-sg/resources/video_demo_hevc.html
Да кто же вам генерирует эти дурацкие заголовки?! Каждая третья статья с тем же паттерном в заголовке [я/мы/он/она] [чё-то там] — и вот [как/почему/зачем]
Лично для меня этот подход крайне спорный, и я его не использую из следующих соображений:
Данные пришедшие с сервера по определению валидны, так как они проходят валидацию при сохранении. Нам не нужно проверять что поле
emailэто правда емэйл. Да – правда. Его бы не занесли в базу будь он не валидным.Проверять нужно только соответствие контракту: ждали строку – пришла строка, ждали свойство
userName– пришлоuserName, а неuser_name.Можно валидировать данные перед отправкой, и для этого я использую Constraint Validation –
min,max,patternи пр.Мне не нужны какие-то непонятные схемы, мне нужна конкретная модель сущнсти, и я предпочитаю rich models.
И для этого я написал себе библиотеку, которая решает мои задачи. То что вы называете схемой, у меня – модель:
То есть, полученный с сервера невалидный JSON, просто превратится в модель с понятной ошибкой. Модель сама по себе тип. С моделью дальше гораздо удобнее работать чем с каким-то json-ом.
https://habr.com/ru/articles/994666/
QA инженеры на своем селениуме. Есть сторя, для нее автотесты такой же артефакт как сборка. Эти тесты живут вместе с продуктом, и прогоняются при каждом инкременте
Потому, что некоторые не читают, а видят только то, что хотят видеть))
Некоторые увидели «я не пишу тесты», и для них это значит «нет тестов», хотя я написал:
Подержите мое пиво!
Не пишу никаких текстов вообще, уже года 4. Просто не вижу в этом смысла. Пока я пишу код, у меня открыт браузер и я сразу проверяю работу. Потом деплой, автотесты, ручное тестирование тестировщиками и нт. Если какой-то баг и закрался — найдут пользаки в проде, а правка дело плевое. Вообще не понимаю зачем тратить время на попытки сэмулировать браузер в ноде и что-то там тестировать. Как-то начал еще playwrite тесты писать, но потом и их выкинул.
Не только в Китае…