Если было подлито 200px вместо 20px и это попало на прод, то, вероятно, есть моменты в процессе обеспечения качества, на которые нужно обратить внимание, т.к. такое изменение было пропущено на ревью, в тестировании и т.д.
Погодите, вопрос же был, про то, как компиляция помогает в обеспечении тестировании верстки?
То, что элемент имеет определённый стиль в зависимости от условий является в целом важной проверкой, которую не нужно проверять скриншотом. При этом шанс того, что иконка не отобразится - ничтожен.
это почему? разработчик/или другая команда подредактировала общий css или удалила/изменила файл c иконками - иконки отображаются не те, или не отображаются вовсе. наличие/отсутствие стиля эту ситуацию не отловит.
Подождите, немного не понятно - как компиляция помогает тестировать верстку? width:20px и width:200px корректные css правила, но верстка совершенно разная. синтаксические проверки css были и до angular 9. тот же vscode подсвечивает неправильные стили.
Вы в своем тесте на иконки проверили не то что иконки отобразились, а то что элемент имеет определенный стиль, что согласитесь разные вещи.
Это не так работает. После приема припарата вас будет тошнить. Есть не хочется. Сигналы насыщения будут приходить раньше. От переедания будет расстройство пищеварения.
Вообще async/await это можно сказать костыль для языков и платформ, которые не смогли в обозримое десятилетие завести green thread и переписали свои библиотеки под async await.
Единообразия кмк мало в Task/ValueTask, да и вы забыли написать что написание асинхронного кода сложнее, и часто провоцирует ошибки, да и само разделения кода на синхронный асинхронный - лишняя сущность.
"отправьте письмо с контентом самому себе по электронной почте и не открывайте его до востребования. " - это как? Что такое "до востребования" для электронного письма?
дак и до этого было все видно. там остальные случаи слишком простые и на них не видно было суть.
Посмотрев на код с использованием Supercat Store, программист, не знакомый с библиотекой, поймет что делает код. С ней легко начать работу даже новичку и потом контролировать что новичок написал.
c mobX еще проще - т.к. там действий меньше. меньше действий => проще понять что происходит.
По поводу использования реактивных переменных, очевидно, что работа с ними безопаснее работы с апи на строках
в mobX работа идет на уровне свойств стора. помогает ide и компилятор, что еще 'более безопаснее'.
Редактор кода подскажет методы создания реактивных переменных и работы с ними.
И наверное подскажет то, что при вызове store.getAtom() передано неправильное имя свойства стора?
Еще скажу, что архитектура, построенная с помощью явных подписок на конкретные реактивные переменные - это и есть ключ к написанию корректного кода, в нем невооруженным глазом виден принцип разделения ответственности.
просто Ваша либа не умеет в автоматические подписки.
Вы упростили пример - нету кейса когда необходимо делать реакцию на изменения 2 свойств. судить о читабельности - рано кмк.
Необходимо явно подписываться на изменения свойств - при рефакторинге, изменении требований, etc - легко забыть подписаться на нужное свойство/отписаться от ненужного. Да и не хочется этим заниматься.
В коде используются магические константы - при рефакторинге/наборе можно перепутать.
Linq Skip и Take это по-моему база. Неужели трудно повторить базу перед прохождением собеса? Ну и TL оценивают и как разработчика при прохождении интервью.
Юра, как же ты в апреле совершил свой высокий полет без gps?
Т.е. Вы предлагаете заменить автоматический инструмент ручным тестированием и ручным просмотром кода? Звучит как регресс.
Погодите, вопрос же был, про то, как компиляция помогает в обеспечении тестировании верстки?
это почему? разработчик/или другая команда подредактировала общий css или удалила/изменила файл c иконками - иконки отображаются не те, или не отображаются вовсе. наличие/отсутствие стиля эту ситуацию не отловит.
Подождите, немного не понятно - как компиляция помогает тестировать верстку? width:20px и width:200px корректные css правила, но верстка совершенно разная. синтаксические проверки css были и до angular 9. тот же vscode подсвечивает неправильные стили.
Вы в своем тесте на иконки проверили не то что иконки отобразились, а то что элемент имеет определенный стиль, что согласитесь разные вещи.
Я все это взял из собственного опыта. -8 кг за первый месяц.
А почему к каждой картинке одна и тажа подпись?
Это не так работает. После приема припарата вас будет тошнить. Есть не хочется. Сигналы насыщения будут приходить раньше. От переедания будет расстройство пищеварения.
Возможно, для того что бы использовать спец синтаксис для каналов.
Чем лучше то?
Ну т.е. у ms пока не получается да?
Вообще async/await это можно сказать костыль для языков и платформ, которые не смогли в обозримое десятилетие завести green thread и переписали свои библиотеки под async await.
Единообразия кмк мало в Task/ValueTask, да и вы забыли написать что написание асинхронного кода сложнее, и часто провоцирует ошибки, да и само разделения кода на синхронный асинхронный - лишняя сущность.
как в Go нет- go каналы на уровне языка.
А когда в дотнет завезут green threads?
"отправьте письмо с контентом самому себе по электронной почте и не открывайте его до востребования. " - это как? Что такое "до востребования" для электронного письма?
дак и до этого было все видно. там остальные случаи слишком простые и на них не видно было суть.
c mobX еще проще - т.к. там действий меньше. меньше действий => проще понять что происходит.
в mobX работа идет на уровне свойств стора. помогает ide и компилятор, что еще 'более безопаснее'.
И наверное подскажет то, что при вызове store.getAtom() передано неправильное имя свойства стора?
просто Ваша либа не умеет в автоматические подписки.
Выделил отдельно код по кейсу с двумя переменными:
mobx
Ваше
Вы правда считаете, что распухание кода в 2 раза, копипаста и boilerplate ведет к увеличение читабельности кода?
У этого монитора есть как минусы так и недостатки.
Вы упростили пример - нету кейса когда необходимо делать реакцию на изменения 2 свойств. судить о читабельности - рано кмк.
Необходимо явно подписываться на изменения свойств - при рефакторинге, изменении требований, etc - легко забыть подписаться на нужное свойство/отписаться от ненужного. Да и не хочется этим заниматься.
В коде используются магические константы - при рефакторинге/наборе можно перепутать.
А вас есть пример делающий тоже самое?
Имхо сравнивают с mobx и понимают что mobx лучше.
Он не прибит к реакту. Посмотрите примеры из самого mobx.
Linq Skip и Take это по-моему база. Неужели трудно повторить базу перед прохождением собеса? Ну и TL оценивают и как разработчика при прохождении интервью.