Comments 15
Плюсанул не читая.
Наблюдаю манию изобретательности.
Почему она неуместна? Потому что масштаб изобретений никакой.
Когда человек пишет программу, ему приходится решать простенькие задачки типа "куда сохранить ввод" или "как найти ранее введённое". И если у человека есть мания, то он обязательно начинает изобретать очень умные подходы к решению этих простеньких задач. Так наизобретали кучу всяких ангуляров с реактами, задумавшись однажды над экзистенциальным вопросом "а не выделить ли нам Action-ы?". И вот все экшены уже выделены, но аппетит ведь приходит во время еды, ну и теперь пришёл черёд задачкам типа "как бы мне покороче записать операцию присваивания", да с реактивностью, и разумеется, в функциональном стиле, ну и ещё с миллионом очень умно выглядящих английских слов (для тех, кто не знает их перевод).
Ну ладно, пусть увлечённые манией маньяки развлекаются. Разве мы против? Только вот дети смотрят на такие игры и некоторые могут заразиться... Но дети, подумайте о смысле. Операция присваивания и так уже очень короткая. Зачем к ней прикручивать так называемый "фрэймворк"? Хотя да, тогда время улетает незаметно и ощущение собственной крутости растёт не по дням, а по часам. Правда возьмись вы конкурировать на сайте фриланса за заказы... В общем - не всё то круто, что блестит.
"как бы мне покороче записать операцию присваивания"
Все-таки там цель не в укорачивании записии операции присванивания.
И самой концепции "вызов без аргументов - геттер, вызов с аргументом - сеттер", уже много лет - https://api.jquery.com/val/
Когда пишешь счетчик с одной кнопкой и выводом значения на экран, возможно данное объяснение уместно. А когда приходится удерживать в голове какие-нибудь каскады данных со сложными зависимостями и множественными источниками, то начинаешь замечать, что из множества решений простеньких задач по типу получить/сохранить/вывести, простенькое решение общей задачи по работе со всем этим как-то не обнаруживается.
Если честно я не знаю специфики работы на фрилансе, но подозреваю, что если имеется какой-то более менее сложный проект, где порядок различных сущностей хранящихся в бд исчисляется сотнями, то оформлять заказ для фрилансеров на такой проект не самый эффективный способ его реализации.
А к нативным интерфейсам это тоже относится, Qt там всякие?
Всякое в жизни приходилось встречать, за 20 лет карьеры в Вебе, но когда вижу очередную попытку сделать из JavaScript'a Python, то просто заканчиваю чтение.
Начните уже уважать читателя с хотя бы "eslint:recommended"
if( !proto ) return value
if( Reflect.getPrototypeOf( proto ) === null ) return value
Не в том дело, есть 99 процентов кода написанного на JavaScript в общепринятом стиле, со скобками и точками с запятой. И глаз разработчика уже на автомате приспособился читать JS код именно в таком виде и отличать его от Python/go например.
В питоне бы за такое просто из профессии погнали. PEP8 там не обсуждается даже
А, вы про рюшечки. Тогда вам сюда. А по теме статьи есть что добавить?
Зашел в комментарии в поисках содержательной рецензии, но не нашел!
Прочитал полную версию, довольно сжато и местами непонятны детали, но в целом ок.
Что сильно смущает, так throw promise: аж передергивает от этого. Разве нельзя было сделать условный Atom<{ value; isPending; error; }> и менять его значение по вызову fetch и получению данных? Да, оно снаружи получается не столь красивым, зато внутри проще.
Не понял смысла в mol_wire_async, синхронные функции разве не предпочтительнее всегда?
Проблема не в том, как оно внутри, а в том, что это влияет на сигнатуры, что приводит к ещё одному цвету функций, и как следствие к превращению простого и понятного кода в кашу с постоянными проверками типа возвращённого значения или в жонглирование монадами, вирусно расползающуюся по всему приложению. А в прикладном коде все эти isPending и error нужны примерно никогда - их имеет смысл обрабатывать лишь в обобщённом коде рендеринга DOM - это буквально пара мест во фреймворке.
Асинхронные функции нужны для интеграции - они вместо кидания обещания возвращают его.
В том как оно внутри есть проблема, потому что на юзкейсах все гладко, а потом надо лезть в кишки и удивляться.
На мой взгляд существует золотая середина между полностью синхронным кодом и дофига асинхронным. Про жоглирование монадами вообще не понял.
IsPending и error не только во фреймворке надо обрабатывать, но и в приложении - выводить ошибку или лоадер иногда.
Про жоглирование монадами вообще не понял.
Это всякие then, catch и final у обещаний, например, в купе с их статическими методами.
на юзкейсах все гладко, а потом надо лезть в кишки и удивляться.
Можете глянуть исходники любого приложения на $mol и убедиться, что там тоже всё гладко. В частности, таких вещей вы там не найдёте за не надобностью:
IsPending и error не только во фреймворке надо обрабатывать, но и в приложении - выводить ошибку или лоадер иногда.
Как это работает я рассказывал тут.
Проектируем идеальную систему реактивности