https://mol.hyoo.ru/ -- английской документации, как я понимаю, нет -- индикатор языка слева внизу показывает "English", но вся документация, кроме меню -- на русском. Переключение языка переключает только язык навигации. Ну да ладно, в гитхабе доки есть, это не глюк, а ограничение целевой аудитории.
https://page.hyoo.ru/#!=6leyma_5ks814 -- примеры втиснуты в милипиздрические фреймы, на экране лаптопа превращающиеся в горизонтально-скроллируемые бронещели танка; зато куча экранной ширины щедро отдана под бесполезную и неубираемую/неизменяемую панель закладок и боковые поля
При всём этом аттракционе щедрости, весьма полезный вертикальный скроллбар тоже миллипиздрический, словно от сердца оторванный. И если зажать ползунок и потащить его мышкой, то мышка отрывается от ползунка, и тот скроллится со своей скоростью. Да, я помню ваш аргумент, что это ограничение виртуального скроллинга, где размеры элементов заранее не известны и параметры скроллера вычисляется динамически -- вот только то же самое случается на коротких статических страницах где виртуальный скроллинг не нужен, и нет динамически подгружаемого контента. Но у вас он впихнут везде, как я понимаю. Поэтому выходит, что скроллер прыгает даже на жалких 2-3-х экранах статического текста: https://page.hyoo.ru/#!=3498sy_ioyx6t . Можно очень много, долго и убедительно рассказывать про борьбу за производительность, но видя такое хочется закрыть вкладку и забыть немедленно, потому что возникает впечатление, эта это борьба ради борьбы (впрочем, это почти про все фреймворки можно сказать).
Даже если проблему пересчёта не обойти, почему бы не сделать изменение размера скроллера более незаметным, через плавное изменение высоты, например?
Это только то, что бросилось в глаза за первые 5 минут чтения.
Этот прокси а) опциональный "сахар", б) создаётся на стороне писателя (которых мало), в) создаётся на короткое время, пока правится "черновик" изменений, а не висит постоянно в сторе (движок может оптимизировать это через escape anaysis и аллокации на стеке или в nursery).
После создания объекта с измениями он (объект) остаётся простым иммутабельным POJO до самого уничтожения.
учить новый непопулярный синтаксис с жёсткими правилами на форматирование и невидимые символы (табы, переносы строк и проч),
тащить в проект кодогенерацию (бррр),
тащить в проект непопулярный билдер с неясными проблемами совместимости с либами,
и проч
-- т.е. повышаете уровень входа до уровня ангуляра. Это значит, что мелкие проекты не возьмут ваш фреймворк практически никогда -- слишком много возни. А крупные проекты не возьмут ваш фреймворк вообще никогда -- из-за рисков, глючной документации с плохим/отсутствующим/нерабочим английским, attitude issues и т.п.
Но вы продолжайте считать несогласных говноедами, а ваш фрейморк самым правильным, это так успокаивает.
Класс, рекурсивный обход 2х объектов и сравнение полей)
Или Immer, например.
Но, вообще говоря, писатель обычно не просто так меняет данные, и вероятность, что он постоянно меняет данные на точно такие же, мала.
У MobX есть такая штука
Я, вообще-то, спрашивал про голые JS проперти, без того чтобы вместо POJO втаскивать прокси на каждый объект в сторе и на его собаку, развесистый реактивный граф коллбэков (и системой, поощряющей делать его как можно развесистей), c потенциалом налететь на утечки, циклические зависимости и бесконечный цикл, N+1, чувствительность к порядку апдейтов, который мы не выбираем явно. Проблем, конечно, можно избежать -- но вы же требуете полной беззаботности со стороны девов, а сами её предложить не можете.
А ещё боремся за почетное звание «Дома высокой культуры и быта!» (с)
Правда в том, что борясь за одно, приходится жертвовать другим.
вы путаетесь в показаниях и включаете заднюю
Или у вас есть фантазия, что вы будто бы прокурор, а я будто бы даю вам какие-то показания.
Я с первого коммента сказал, что иммутабельность -- не панацея, и что для получения гарантий нужна дисциплина со стороны писателя. Вы же, судя по вашей бурной реакции, почему-то предположили, что я топлю за иммутабельность как за серебрянную пулю и отчаянно бьюсь с вами.
Представляете, есть люди, которые занимаются разными вещами в разное время, и как-то время им чем-то приходится не пользоваться. Поэтому скорость забывания значение имеет.
Признаться, после чтения статей про атомы и проч я был заинтригован, и тайпскриптная часть была интересной. Поэтому я потратил некоторое время на изучение документации. Оно вроде как и не сильно сложно, но нет, мне не показалось очень мнемоничным. Т.е. когда читаешь доку, вроде понятна идея. Но, вернувшись через некоторое время, я понял, что практически ничего не запомнилось, и трудно по памяти восстановить, какая именно идея стояла за определённым синтаксисом. Т.е. ход "идея --> синтаксис" работает, а обратный ход "синтаксис --> идея" -- не очень.
У меня не сильно хорошая память, я, например, и вимом не пользуюсь поэтому -- слишком много клавиатурных жестов запоминать, потом мучительно вспоминать после пауз. Вдобавок, я фронтендом занимаюсь лишь эпизодически, поэтому паузы длинные. Так что я решил, что это не моя чашка чая. И, подозреваю, так решили многие (если не все).
ЗЫ. Я так же не люблю snake_case и yaml, и с большой неохотой пользуюсь всякими декораторами, атрибутами и проч, так как они создают паралельный язык, которым легко злоупотреблять (привет, ангуляр), получить проблемы с рефакторингом и проч. Но это личные загоны.
Это ответственность того, кто меняет данные. Обычно писателей мало, читателей много, поэтому забота о том, чтобы не создавать ложных псевдо-изменений ложится на писателей. Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
есть такие штуки getters/setters ... Было изменение, вызывает реакции
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Да вы что, прям яваскрипт знает какая часть неизменной будет, а какая нет?)))
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Каждая манипуляция стоит времени, места и энергии.
Именно поэтому нужно избегать манипуляций, когда они не нужны. А не нужны они там, где ничего не поменялось. А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
У вас в эмбеде наверное нету развесистых деревьев состояний и их презентаций, как в пользовательском UI, вот вам и не нужно это всё. Вы с другой колокольни смотрите.
Оно читаемое -- сразу после момента когда прочитал документацию. Но через некоторое время, после работы с другими вещами, которые занимали мозг, большая часть знаний это птичьего языка улетучивается, и без заглядывания в доки опять ничего не понятно.
ПДД — гарантирует безопасное передвижение по дорогам общего пользования, в случае когда пользователи этих самых дорог САМИ же их и исполняют!
LOL ещё 3 раза. Я ещё помню времена, когда в ПДД до недавнего времени не было даже определённости, что называть "обгоном", и до сих пор имеются неоднозначные формулировки, которые можно интерпретировать по-разному. И это только ПДД РФ, в то время как в мире имеются ПДД других стран.
Плюс имеются best practices, не прописанные в ПДД, и даже есть рекомендации плохих практик (например, рекомендация перестраиваться заранее перед сужением вместо "zip merge", что приводит к растягиванию пробок).
У меня цель— прогрессивное развитие нашей Цивилизации.
Поздравляю, вы один такой белый рыцарь, все остальные -- жадные ублюдки, после которых хоть потоп. /s
Что конкретного Вы уже сделали для достижения этой цели, кроме уговаривания других?
Я предлагаю— хорошенчеко сесть т подумать над всем комплексом.
Ваш снисходительный совет специалистам "хорошенечко сесть, подумать и написать директивы" является настолько же бесполезным, насколько бесплатным. Проблема не в отсутствии статей и рекоменаций -- их написано тонны. Проблема в том, что панацей, серебрянных пуль и универсальных парадигм с гарантией успеха, не существует, как бы вам не хотелось.
самолетная отрасль полетов — полностью зарегулирована.
Иммутабельность даёт гарантии, что объект, который ты получил, не взорвётся у тебя в руках останется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флагов isModified, или перерисовывать весь UI на каждый чих.
Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Как у любого решения, у этого есть своя цена, каждый сам должен решать, что выгоднее в его конкретном случае.
С каких пор полное копирование участка памяти(объекта) с целью его изменения
При правильном подходе новый объект создаётся не полным копированием всех данных, а путём копирования ссылок на неизменённые данные, плюс новые примитивы/ссылки в местах изменений. Т.е. копирование происходит только для части ссылок и части примитивов, но это достаточно дёшево, так как для них есть быстрые кучи/арены. Когда вы меняете строку "по месту", у вас точно так же есть шанс получить либо перераспределение памяти, либо её недоиспользование, поэтому строки в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.
И как появились ПДД, все их выучили наизусть, и все нарушения немедленно кончились и воцарилось благоденствие?
удачи дальше спорить чей стек лучше.
Как будто в "Комитете по доктринам" споров не будет, ага. И с решениями Комитета все будут единогласно согласны, конечно же.
Я вам своми вопросом "в никуда" как бы намекнул, что у вас в голове какая-то детская вера в мудрость Больших Дядь в Комитетах и в магию Незыблемых Директив. Та же благословенная OSI, с которой вы носитесь, нарушается только пыль стоит.
В реальном мире (а не в воображаемом вами) вначале само сообщество разработчиков набивает шишки на реальных задачах (что означает баги!), потом публикует статьи по этим набитым шишкам и по лучшим практикам того, как избегать их набивания. Потом приходят новые люди, которое либо грамотны, но остались неудовлетворены существующими решениями, либо тупо ничего из всего этого написанного этого не читала, но имеет мнение -- и начинает изобретать свои велосипеды, набивая новые шишки.
Вы не предлагаете никаких инженерных решений, решающих реальные проблемы. Вы предлагаете административное ограничение -- обязать всех писать только по директиве. Это никогда не работало, и работать не будет. В списке ["физические ограничения", "технические ограничения", "административные ограничения"], административные -- самые слабые, ибо легко нарушаются/обходятся. Они же -- самые заманчивые для тех, кто не умеет в технические.
У меня как-то не связывается собственно тушение с передотвращением дальнейшего распространения и ожиданием, пока уже загоревшееся не выгорит.
Между тем это основная тактика тушения трудных пожаров, особенно при дефиците воды. Cкажем, при сильном возгорании деревянного дома (в который рискованно входить) эффективнее дать ему сгореть дотла, не давая загореться соседним -- причём это выгоднее даже пострадавшему, так как дом всё равно под снос и расчистку площадки под новый, а убрать пепел вместо вывоза кучи полуобгорелого мусора обойдётся намного дешевле. То же с горением батарей -- проще дать ей выгореть и не дать загореться остальному, чем тушить. Но если нужно тушить, то именно заливая большим количеством воды, не боясь сказок про литий или разряд через воду.
https://mol.hyoo.ru/ -- английской документации, как я понимаю, нет -- индикатор языка слева внизу показывает "English", но вся документация, кроме меню -- на русском. Переключение языка переключает только язык навигации. Ну да ладно, в гитхабе доки есть, это не глюк, а ограничение целевой аудитории.
https://page.hyoo.ru/#!=6leyma_5ks814 -- примеры втиснуты в милипиздрические фреймы, на экране лаптопа превращающиеся в горизонтально-скроллируемые бронещели танка; зато куча экранной ширины щедро отдана под бесполезную и неубираемую/неизменяемую панель закладок и боковые поля
При всём этом аттракционе щедрости, весьма полезный вертикальный скроллбар тоже миллипиздрический, словно от сердца оторванный. И если зажать ползунок и потащить его мышкой, то мышка отрывается от ползунка, и тот скроллится со своей скоростью. Да, я помню ваш аргумент, что это ограничение виртуального скроллинга, где размеры элементов заранее не известны и параметры скроллера вычисляется динамически -- вот только то же самое случается на коротких статических страницах где виртуальный скроллинг не нужен, и нет динамически подгружаемого контента. Но у вас он впихнут везде, как я понимаю. Поэтому выходит, что скроллер прыгает даже на жалких 2-3-х экранах статического текста: https://page.hyoo.ru/#!=3498sy_ioyx6t . Можно очень много, долго и убедительно рассказывать про борьбу за производительность, но видя такое хочется закрыть вкладку и забыть немедленно, потому что возникает впечатление, эта это борьба ради борьбы (впрочем, это почти про все фреймворки можно сказать).
Даже если проблему пересчёта не обойти, почему бы не сделать изменение размера скроллера более незаметным, через плавное изменение высоты, например?
Это только то, что бросилось в глаза за первые 5 минут чтения.
Этот прокси а) опциональный "сахар", б) создаётся на стороне писателя (которых мало), в) создаётся на короткое время, пока правится "черновик" изменений, а не висит постоянно в сторе (движок может оптимизировать это через escape anaysis и аллокации на стеке или в nursery).
После создания объекта с измениями он (объект) остаётся простым иммутабельным POJO до самого уничтожения.
Вы уже предлагаете
учить новый непопулярный синтаксис с жёсткими правилами на форматирование и невидимые символы (табы, переносы строк и проч),
тащить в проект кодогенерацию (бррр),
тащить в проект непопулярный билдер с неясными проблемами совместимости с либами,
и проч
-- т.е. повышаете уровень входа до уровня ангуляра. Это значит, что мелкие проекты не возьмут ваш фреймворк практически никогда -- слишком много возни. А крупные проекты не возьмут ваш фреймворк вообще никогда -- из-за рисков, глючной документации с плохим/отсутствующим/нерабочим английским, attitude issues и т.п.
Но вы продолжайте считать несогласных говноедами, а ваш фрейморк самым правильным, это так успокаивает.
Или Immer, например.
Но, вообще говоря, писатель обычно не просто так меняет данные, и вероятность, что он постоянно меняет данные на точно такие же, мала.
Я, вообще-то, спрашивал про голые JS проперти, без того чтобы вместо POJO втаскивать прокси на каждый объект в сторе и на его собаку, развесистый реактивный граф коллбэков (и системой, поощряющей делать его как можно развесистей), c потенциалом налететь на утечки, циклические зависимости и бесконечный цикл, N+1, чувствительность к порядку апдейтов, который мы не выбираем явно. Проблем, конечно, можно избежать -- но вы же требуете полной беззаботности со стороны девов, а сами её предложить не можете.
А ещё боремся за почетное звание «Дома высокой культуры и быта!» (с)
Правда в том, что борясь за одно, приходится жертвовать другим.
Или у вас есть фантазия, что вы будто бы прокурор, а я будто бы даю вам какие-то показания.
Я с первого коммента сказал, что иммутабельность -- не панацея, и что для получения гарантий нужна дисциплина со стороны писателя. Вы же, судя по вашей бурной реакции, почему-то предположили, что я топлю за иммутабельность как за серебрянную пулю и отчаянно бьюсь с вами.
Представляете, есть люди, которые занимаются разными вещами в разное время, и как-то время им чем-то приходится не пользоваться. Поэтому скорость забывания значение имеет.
Есть разные вещи, про которые я читал, но не пробовал (всего не перепробуешь), но степень их забывания почему-то разная.
Признаться, после чтения статей про атомы и проч я был заинтригован, и тайпскриптная часть была интересной. Поэтому я потратил некоторое время на изучение документации. Оно вроде как и не сильно сложно, но нет, мне не показалось очень мнемоничным. Т.е. когда читаешь доку, вроде понятна идея. Но, вернувшись через некоторое время, я понял, что практически ничего не запомнилось, и трудно по памяти восстановить, какая именно идея стояла за определённым синтаксисом. Т.е. ход "идея --> синтаксис" работает, а обратный ход "синтаксис --> идея" -- не очень.
У меня не сильно хорошая память, я, например, и вимом не пользуюсь поэтому -- слишком много клавиатурных жестов запоминать, потом мучительно вспоминать после пауз. Вдобавок, я фронтендом занимаюсь лишь эпизодически, поэтому паузы длинные. Так что я решил, что это не моя чашка чая. И, подозреваю, так решили многие (если не все).
ЗЫ. Я так же не люблю snake_case и yaml, и с большой неохотой пользуюсь всякими декораторами, атрибутами и проч, так как они создают паралельный язык, которым легко злоупотреблять (привет, ангуляр), получить проблемы с рефакторингом и проч. Но это личные загоны.
Это ответственность того, кто меняет данные. Обычно писателей мало, читателей много, поэтому забота о том, чтобы не создавать ложных псевдо-изменений ложится на писателей. Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Именно поэтому нужно избегать манипуляций, когда они не нужны. А не нужны они там, где ничего не поменялось. А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
У вас в эмбеде наверное нету развесистых деревьев состояний и их презентаций, как в пользовательском UI, вот вам и не нужно это всё. Вы с другой колокольни смотрите.
Оно читаемое -- сразу после момента когда прочитал документацию. Но через некоторое время, после работы с другими вещами, которые занимали мозг, большая часть знаний это птичьего языка улетучивается, и без заглядывания в доки опять ничего не понятно.
Да прямо завтра и начну. В самом-то деле, 35 лет код пишу, куда уже дальше откладывать?
Если хз, то подскажу более подходящий термин. и, соответственно, название склонности.
Take care.
LOL ещё 3 раза. Я ещё помню времена, когда в ПДД до недавнего времени не было даже определённости, что называть "обгоном", и до сих пор имеются неоднозначные формулировки, которые можно интерпретировать по-разному. И это только ПДД РФ, в то время как в мире имеются ПДД других стран.
Плюс имеются best practices, не прописанные в ПДД, и даже есть рекомендации плохих практик (например, рекомендация перестраиваться заранее перед сужением вместо "zip merge", что приводит к растягиванию пробок).
Поздравляю, вы один такой белый рыцарь, все остальные -- жадные ублюдки, после которых хоть потоп. /s
Что конкретного Вы уже сделали для достижения этой цели, кроме уговаривания других?
Ваш снисходительный совет специалистам "хорошенечко сесть, подумать и написать директивы" является настолько же бесполезным, насколько бесплатным. Проблема не в отсутствии статей и рекоменаций -- их написано тонны. Проблема в том, что панацей, серебрянных пуль и универсальных парадигм с гарантией успеха, не существует, как бы вам не хотелось.
Вы ошибаетесь насчёт "полностью".
Иммутабельность даёт гарантии, что объект, который ты получил, не
взорвётся у тебя в рукахостанется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флаговisModified, или перерисовывать весь UI на каждый чих.Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Как у любого решения, у этого есть своя цена, каждый сам должен решать, что выгоднее в его конкретном случае.
При правильном подходе новый объект создаётся не полным копированием всех данных, а путём копирования ссылок на неизменённые данные, плюс новые примитивы/ссылки в местах изменений. Т.е. копирование происходит только для части ссылок и части примитивов, но это достаточно дёшево, так как для них есть быстрые кучи/арены. Когда вы меняете строку "по месту", у вас точно так же есть шанс получить либо перераспределение памяти, либо её недоиспользование, поэтому строки в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.
И как появились ПДД, все их выучили наизусть, и все нарушения немедленно кончились и воцарилось благоденствие?
Как будто в "Комитете по доктринам" споров не будет, ага. И с решениями Комитета все будут единогласно согласны, конечно же.
Я вам своми вопросом "в никуда" как бы намекнул, что у вас в голове какая-то детская вера в мудрость Больших Дядь в Комитетах и в магию Незыблемых Директив. Та же благословенная OSI, с которой вы носитесь, нарушается только пыль стоит.
В реальном мире (а не в воображаемом вами) вначале само сообщество разработчиков набивает шишки на реальных задачах (что означает баги!), потом публикует статьи по этим набитым шишкам и по лучшим практикам того, как избегать их набивания. Потом приходят новые люди, которое либо грамотны, но остались неудовлетворены существующими решениями, либо тупо ничего из всего этого написанного этого не читала, но имеет мнение -- и начинает изобретать свои велосипеды, набивая новые шишки.
Вы не предлагаете никаких инженерных решений, решающих реальные проблемы. Вы предлагаете административное ограничение -- обязать всех писать только по директиве. Это никогда не работало, и работать не будет. В списке ["физические ограничения", "технические ограничения", "административные ограничения"], административные -- самые слабые, ибо легко нарушаются/обходятся. Они же -- самые заманчивые для тех, кто не умеет в технические.
Начинают?! LOL. Они начали когда вас ещё в проекте не было.
Просто люди не учат историю. И история не учит людей, ибо всякая старая глупость предстаёт перед ними в новом свете.
Откуда вы берётесь такие, любители доктрин?
В дополнение к сотворению календаря -- сотворение часов:
Где там HATEOAS?
Между тем это основная тактика тушения трудных пожаров, особенно при дефиците воды. Cкажем, при сильном возгорании деревянного дома (в который рискованно входить) эффективнее дать ему сгореть дотла, не давая загореться соседним -- причём это выгоднее даже пострадавшему, так как дом всё равно под снос и расчистку площадки под новый, а убрать пепел вместо вывоза кучи полуобгорелого мусора обойдётся намного дешевле. То же с горением батарей -- проще дать ей выгореть и не дать загореться остальному, чем тушить. Но если нужно тушить, то именно заливая большим количеством воды, не боясь сказок про литий или разряд через воду.