неа, со свелтом не работал

Давно выработалась привычка перед маневром в сторону, смотреть не едет ли кто взади.

Ок

Понял, в случае с молом, применение конструкторов ограничено. Но по факту им является свойство-фабрика. TS-ом тут не проверить, относителная защита только то, что для одного класса не должно быть больше одной фабрики, в идеале

Я правильно понял описанный кейс?:

Например есть инпут, который везде в проекте используется. Его отрефакторили, что привело к добавлению нового свойства, которое нужно теперь изменить во всех местах использования этого инпута.

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

Выражение выше не нужно доказывать, я согласен с ним)

при переопределение тайпскрипт проверяет совместимость сигнатур функций

сама концепция предполагает наличие значений по умолчанию, например если тоже самое описывать на языке view.tree - то тут уже нельзя не указать значение по умолчанию

$hyoo_ballsort_game $mol_object
  tube_size 4
  Tube* $hype_ballsort_tube
    size <= tube_size

это равносильно
class $hyoo_ballsort_game extends $mol_object {
  tube_size() { return 4 }
  
  @$mol_mem_key
  Tube( index: number ) {
    const obj = $hype_ballsort_tube
    obj.size = () => this.tube_size()
    return obj
  }
} 

Если не возможно указать значение по умолчанию, то можно сделать так, чтобы разработчик сразу увидел

size() {
  throw new Error('Not implemented')
}

Конкретно в этом случае можно через конструктор передать начальное значение шаров

class $hype_ballsort_tube extends Object {
  constructor(public balls_default: Ball[] = []) {}
  
  @ $mol_mem
  balls(next?: $hype_ballsort_ball[]) {
    return next ?? this.balls_default()
  }
}

А код фабрики стал бы таким:

		@$mol_mem_key
		Tube( index: number ) {
			return new $hype_ballsort_tube(this.tube_size())
		}

Но в целом, в моле конструкторы используются только дли передачи значений по умолчанию, а инстанцируются объекты из свойств-фабрик $mol_mem_key и $mol_mem(если нужен singleton)

Фабрики используются потому что:
- свойства-фабрики ленивые, т.е. объекты создаются непосредственно при обращении к фабрике. Например это помогает для написания интеграционных тестов для приложения, в одном кейсе поднимется только та часть приложения которая непосредственно участвует в кейсе, а остальная часть не поднимется т.к. все ленивое
- свойства-фабрики управляют жизненым циклом подконтрольных объектов, т.е. если они понимают что они больше не нужны, они прибивают подконтрольные объекты и вызывают у них метод destructor в котором можно определить что нужно сделать при уничтожении. В целом это может работать и не течь без наличия garbage collector
- и они устанавливают для подконтрольных объектов глобально-уникальные идентификаторы, которые в том числе используются системой реактивности для отслеживания изменений

А конструкторы используются только для передачи значений по умолчаию из нереактивных источников, потому что если бы tube_size было мемоизированым изменяемым свойством:

@ $mol_mem
tube_size(next?: number) {
  return next ?? 4
}

То тогда вариант с получением его значения и передачей в конструктор был бы не желателен, т.к. если бы кто-то изменил значение в tube_size, это вело бы к устареванию фабрики Tube и повторной актуализацией с пересозданием всех подконтрольных объектов. В некоторых случаях мы бы получили нежелательное поведение.

В таком случае нужно было бы делать как вы написали ниже: `return new $hype_ballsort_tube(() => this.tube_size())`, чтобы небыло вызова tube_size в фабрике.

Но, я воспользовался общим "паттерном" настройки объекта, который описан в ссылках приведенных ниже.

код стайл это косметика

Если декларативное описание сложно прочитать, можно спросить у chatgpt

Минутка продаж

Если жалко брать большой реакт для маленького приложения, возьмите $mol

https://pavelzubkov.github.io/my_app

декларативное описание приложения https://github.com/PavelZubkov/my_app/blob/master/app.view.tree

логика к нему на ts
https://github.com/PavelZubkov/my_app/blob/master/app.view.ts

стили
https://github.com/PavelZubkov/my_app/blob/master/app.view.css.ts

Жалко что сейчас документации недостаточно, чтобы в $mol въехать. Если будете еще разбираться, лучше зайдите в чат https://t.me/mam_mol , хотя бы с проблемами там можно быстро разобраться.

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

ВАЖНО: Консоль должна быть открыта во время тестов! Иначе по причинам известным только одному создателю теста цифры не соответствуют действительности от слова совсем, это даже видно просто по времени выполнения.

А есть аргументы в пользу того, что при открытой консоли цифры не соответствуют действительности, а не при закрытой, или в пользу того что они в обоих случаях не соответствуют дествительности?

С вставка console.log и замер скорости вывода на глаз - слабый и странный аргумент, т.к. глаз не славится точностью, а один прогон занимает миллисекунды. К тому же не ясно, как коррелирует количество запускав одного прогона и кода целиком вместе с импортом(который ассинхронный)

Достаточно открыть примеры кода на $mol, чтобы убедиться, что кто-то в здравом уме не будет это использовать.

Ну, спасибо (

надо позволять переопределять КАЖДЫЙ кусочек любого компонента, чтобы в дальнейшем компонент не подлежал дальнейшей разработке. И конечно же отказаться от любого вида модульности в JavaScript (CommonJS, ESModules). Все должны использовать глобальные имена в модулях, ведь импорт нужного имени в локальный скоуп модуля это гораздо сложнее, чем писать каждый раз при использовании полный путь вида $mol_plot_ruler_vert.

Как пример, нужно обязательно переопределить base64 encode, но не написать реализацию. https://github.com/hyoo-ru/mam_mol/blob/d190555a186c4936a43d914864c5e58850ca0e92/base64/encode/encode.ts

Эти утверждения ложные. Без базового понимания МАМ/$mol, тут не понятно что к чему.

base64 encode там не переопределяется, это пользовательская функция. Тут можете подробнее разобраться в МАМ, так получится дать более качественную обратную связь/критику.

С документацией есть проблемы, да.

Прежде чем принимать на веру хоть слово из этой статьи

А еще, не стоит оценивать бенчмарки по красивым картиночкам и результатам, которые сам автор интерпретирует как ему удобно.

Зачем принимать слова на веру из этой статьи? Методика измерений описана, можно самостоятельно оценить, если она ошибочна можно предложить исправления/дополнения или свою, или ничего не делать

рекомендую изучить "ауру" которая сложилась вокруг автора и результатов его трудов.

Ага, надо читать и пользоваться трудами только от популярных авторов

Если интересно, почему я пишу этот комментарий, то это потому, что автор пытается замерять одну часть в каждом СТМ и в effector. 

Выглядит так, что вы оскорблены тем, что эффектор на последнем месте. Чтобы это скомпенсировать, вы предлагаете взглянуть на другие части, выходящие за рамки статьи.

Другой момент — удобство разработки.

DX не тема статьи, согласен с его большой важностью. По поводу того, что бенчи мало показательны, ваша мысь понятна. А у вас есть идеи/решения как сравнить DX разных фреймворков/библиотек?

`Ну а быстродействие Озона при поиске каждый может проверить, включив троттлинг "Slow 3G" в девтулз. Ну нет там никаких пол-минуты, ну что я поделаю.`

проверил) примерно через 15 секунд картинки на товарах прогрузились, а индикатор "загрузки" на табе уже шестую минуту крутится

Когда-то размышлял на тему кастомизации, получилась такая картинка.

Место расширения -> в месте определения -> добавления кода: имеется ввиду случай, когда нужно изменить существующий компонент, что-то в него добавив

Аспекты расширения -> компоновка: этот пункт про иерархию вложенности компонентов

Стратегия расширяемости ->...-> DSL: компоненты в определенных терминах, описывается на отдельном декларативном языке, из которого генерируется более низкоуровневое представление, отвечающее требуемым возможностям по расширению, добавлению поведения/оформления

Стратегия расширяемости ->...-> Вручную: это как в пункте выше, но требуемое более низкоуровневое представлении пишется руками

Лет десять назад интересовался темой, но понял, что куда лучше научится действовать более осознано/обдуманно/менее_автоматически в жизни.

В одной модульной системе на js, вместо импортов используются FQN-имена, выглядит как $path_to_module.

Имя сущности соответствует(почти) пути до нее, чтобы ей воспользоваться просто пишется имя. И конечно можно положить в переменную, чтобы 100500 раз не писать длинное имя, если необходимо, тогда выглядит как импорт в начале файла.

"как бы мне покороче записать операцию присваивания"

Все-таки там цель не в укорачивании записии операции присванивания.
И самой концепции "вызов без аргументов - геттер, вызов с аргументом - сеттер", уже много лет - https://api.jquery.com/val/

которые вы можете писать на любом языке программирования

Там через докер работает, если каких-то из коробки не будет, можно будет добваить, емнип