The pit of Failure (or Success)

Часто при проектировании API кроме того что нам важно думать не только о фичах и возможностях которые он дает, но и какой импакт этот API несет при использовании. И тут есть 2 противоположных концепта: Falling Into The Pit of Success/Failure или при переводе Упасть В Яму Успеха/Неудачи.

Какие же ключевые принципы разработки за этим скрываются? Если сократить и упростить, то выйдет: Делай так чтобы правильно было использовать легко, а неправильно сложно. Те наша задача мотивировать людей и поощрять правильное использование API и делать так, чтобы некорректное использование всем видом кричало, что тут дела обстоят не так (fall into the pit of success). Обратный пример, когда API словно подталкивает использовать себя грязно, а использовать корректно больше похоже на тернистый путь или полосу испытаний (Я думаю каждый сталкивался с таким ощущением)

Давайте возьмем пару примеров из API и рассмотрим их:
React:

<div dangerouslySetInnerHTML={{ __html: "Hello" }} />

И тут нам интересно API dangerouslySetInnerHTML, видите что оно делает? Да, оно всем своим видом кричит, что вы делаете что-то опасное и нехорошее, а громоздкость с { __html: "Hello" } дополняет картинку. В добавок вам еще будет сложнее точно сходу вспомнить правильное написание и вы пойдете в документацию, где вам еще раз дадут понять: "скорее всего ты делаешь что-то не то". Это прекрасный пример того, как с помощью API вам не дают применить нечто потенциально опасное.

И вот сегодня я увидел обратный пример из мира Svelte:

let double = $derived(count*2);
double = 3.14;

Это сегодняшний анонс долгожданной фичи, чтобы вычислимые значения могли быть временно изменены. Крутая же фича? В целом да, ее запрашивали и ждали, а без нее приходилось использовать костыли. И вроде как надо радоваться? Нам же дали возможность и маловероятно, что оно что-то сломает... Но вот тут как раз всплывает тема того к чему мы подталкиваем дизайном нашего API.

В реактивной системе необходимость делать writable вычислимые поля достаточно редка. Кроме того нам дали возможность делать только прямую запись, а не условный сеттер который бы позволил сделать two way connection, нет, это не тот случай! Те мы можем просто лезть в кэш вычислимого свойства и подменять его до изменения значения. Ну надо же людям эту фичу, в чем проблема? А в том, что в 99% случаев эта фича не нужна, а вот все 100% $derived полей стали вместо read-only теперь writable. И никакой вас TypeScript не спасет от записи в него случайно (например, при рефакторинге) и вы больше видя перед собой $derived не можете быть уверены записывают что-то в него или нет, эта информация лежит где-то в другом месте компонента и пока вы не прочтете код компонента полностью вы больше не можете быть в этом уверены.

Таким образом эта возможность не подталкивает к правильному использованию сигналов, делает так что допускать случайные ошибки стало проще и при этом осталось относительно скудным по возможностям (как и написал это не дает возможность делать two way connection). С другой стороны мы покрыли возможность 1% от случаев. Вот это пример, когда мы видим собой pit of failure, да нас не мотивируют прямым образом использовать этот функционал неправильно, но "заборчик" рядом с ямой куда-то унесли.

Как этого можно было избежать?
Использовать отдельный нейминг

let double = $writableDerived(count*2);
double = 3.14;

Или использовать отдельный параметр

let double = $derived(count*2, { writable: true }); // или любая другая явная модификация
double = 3.14;

Или на худой конец если мы хотим оставить магию в нашем мире, то создать явное API

let double = $derived(count*2);
$modifyDerivedCache(double, 3.14); // мы сделали неудобное, но однозначное API

Это все еще лучше, чем выкинуть забор и дать неявное по смыслу API.

Не думайте что это "написать плохо на чем угодно можно" /"вопрос прямых рук". НЕТ! Вы, как автор API, должны формировать у людей прямые руки, а кривые выпрямлять. Пожалуйста, прикидывайте в голове эти сценарии: "мотивирую ли я делать что-то плохое" и "поощряю ли я правильное использование". Спасибо...

Дождался. Доклад по Шестеренкам реактивности Vue наконец-то вышел. В нем были разобраны базовые механизмы на которых основана работа реактивности во Vue.

- Ссылка на презентацию
- Ссылка на карту реактивности

И так полезный сопровождающий материал:
- Chibivue [Ru]
- Курс от Michael Thiessen

Когда речь заходит о изучении TypeScript в голову сразу приходит Matt Pocock. Настоящий маг TypeScript-а и автор лучших статей по этому языку. И вот он выкатил нам новый подарок: Total TypeScript Essentials.

Это книга по всему TypeScript который нужен разработчику, да она не охватывает все таинства языка, но базу дает очень хорошую. Книга совершенно бесплатная и при быстром обзоре мне показалась очень хорошо структурированной и наполненной. Вполне возможно, что на данный момент это наиболее актуальная и лучшая книга для изучения TypeScript (так как книга была выложена лишь недавно, то прочесть полностью ее я не успел, чтобы это утверждать однозначно).

В целом появление таких ресурсов всегда радует. А если содержания книги вам покажется мало, то однозначно рекомендую ознакомиться с его статьями и youtube каналом, где разбираются уже более узкие темы подробно

#ts #материалы

С минуты на минуту (в 19:00мск) приму участие в Frontend-свояке от SiberiaCanCode (большое спасибо за приглашение Диме!). Думаю будет много веселых вопросов и неожиданных тупняков. В целом приглашаю весело провести с нами время!

Площадки: twitch, youtube

С минуты на минуту будем заполнять The State Of HTML 2025 и обсуждать текущее положение веба.

Ожидается огромный поток информации на выпуск :D

#подкаст

Заполняем State of HTML 2025 в новом выпуске «Тяжелого утра» — завтра, 2 августа в 11:00 по Москве.

Подключайтесь к нам на удобной платформе:

— Twitch
— YouTube
— VK Видео