Утечка исходников в банке: безразличие или так задумано?

Не сходят. API так не работает. Минификация это заборчик по колено в чистом поле — бессмысленно. Только на размер загружаемых джээсников влияет.

Утечка исходников в банке: безразличие или так задумано?

А если не будет, то что?

Что в этом коде может быть такого опасного?

Observable – удобный state-manager

Это все понятно, я, разумеется, сам запускал и одно и другое, но это не ответ.

Тут разница чисто визуальная. Mobx явно подписался на less, который в свою очередь неявно подписан на a и b.

Observable просто явно подписывается на a и b. И в одном и в другом случае при каждом изменении a и b вызывается оригинальный getter less и пересчитывается значение. Соотвественно, если в less будут тяжелые вычисления – они выполнятся и там и там.

Observable – удобный state-manager

Ну штош...

Решил разобраться в этом и немного не понимаю в чем соль, или что я упустил.

function bigWork() {
  console.log('a iam doing a big work')
}

class Mobx {
  a = 1;
  b = 2;

  constructor() {
    makeAutoObservable(this)
  }

  get less() {
    console.log('invoke less')
    bigWork()
    return this.a < this.b;
  }

  incB() {
    this.b++;
  }
}

const foo = new Mobx();

autorun(() => {
  console.log("less in autorun", foo.less);
});

let count = 0
setInterval(() => {
  if (count < 4) {
    foo.incB()
    ++count
  }
}, 2000)

// invoke less
// a iam doing a big work
// less in autorun true

// invoke less
// a iam doing a big work

// invoke less
// a iam doing a big work

// invoke less
// a iam doing a big work

// ...

Что мы тут имеем. less под капотом превращается в свойство а не геттер, его значение = значение гетера в изначальном состоянии.

Дальше мы подписываемся на изменения свойств который геттер читает, и при их изменении дергаем оригинальный гетер а результат присваиваем свойству less. Таким образом, мы получаем computed.

И вот тут я поломался, потому что не понимаю зачем. Оригинальный геттер все равно вызывается при изменении свойств которые он читает. Из этого следует, что если в нем будут сложные вычисления (bigWork) – мы их не избежим.
Предположим, что сложные вычисления зависят от значения computed

autorun(() => {
  if (foo.less) {
    bigWork()
  }
});

Что в таком случае:

В mobx autorun вызовется один раз и мы вызовем bigWork()

В observable autorun будет вызван несколько раз (на каждое изменение foo.b), но bigWork() будет вызван один раз, так как foo.less не изменился.

Вы итоге получаем, что и в mobx и в observable геттер будет вызываться на каждое изменение a или b. Autorun будет вызываться разное количество раз, но от этого ничего не меняется.

Я что-то упустил?

Observable – удобный state-manager

Разговор глухого с немым. Не вижу в твоем коде ни деструктора, ни высвобождения ресурсов.

Observable – удобный state-manager

Выяснил почему не сталкивался с этим. Я использую preact, в нем такой проблемы нет https://codesandbox.io/p/sandbox/7wkxdv

Observable – удобный state-manager

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

То есть это свой урезанный mobx? С тем же публичным API. Вопрос: зачем?

Вы себе тут противоречите. Если Observable предлагает тот же API, то почему на ваш взгляд он «урезанный»? Я с этим утверждением не согласен. Observable предлагает тот же API при существенно меньшем размере. Он немного производительнее и чуть чуть удобнее (не нужно писать runInAction).

Где сравнение, чем это удобнее, например effector, mobx, redux, reatom.

Прежде чем написать этот пост, я посмотрел похожие на хабре, и пришел к выводу что такое сравнение не пройдет модерацию, или у местного сообщества считается неуместным, поэтому сравнение не приводил. Но это же просто сделать самостоятельно, на том же каунтере. Вот зустанд, redux, effector.

Хотя бы про производительность бы.

Есть ссылка в статье. Производительнее редакса, мобх и зустанд. По потреблению памяти еще и jotai с recoil.

Поэтому, раз тут про удобство! Было бы удобно, если бы был стейт менеджер, которыц покрывает весь спектр задач, а не только кусочек!

Например, роутер, форм library, fetching?

Можете привести пример такого, например на мобх? На мой взгляд, стейт менеджер не швейцарский нож, который как известно плохо делает все. Роутингом должен заниматься роутер, фетчингом fetch. Если приведете пример конкретной задачи, я с удовольствием отвечу.