Управление состоянием приложения с RxJS/Immer как простая альтернатива Redux/MobX

В redux проблему бойлерплейта (а как я понял с ним автор и борется) легко можно решит библиотекой от самих же создателей redux redux-toolkit, которая под капотом как раз использует Immer, позволяя в редьюсерах работать как-бы в mutable way
Вот пример

const counterSlice = createSlice({
  name: 'counter',
  initialState: 0,
  reducers: {
    increment: state => state + 1,
    decrement: state => state - 1
  }
})
const store = configureStore({
  reducer: counterSlice.reducer
})
document.getElementById('increment').addEventListener('click', () => {
  store.dispatch(counterSlice.actions.increment())
})

Ссылочка на документацию

Как проходит собеседование Junior фронтенд-разработчика

Всё, разобрался. Думал что executor промиса отработать должен после вызова than/catch (подобно потокам rxjs), но оказалось что отрабатывает он сразу при создании промиса.

Как проходит собеседование Junior фронтенд-разработчика

Почему во втором примере вывод

1
2!
5
3
4

а не

1
5
2
3
4

Почему вызов промиса a.then(...) обработался синхронно?

Почему контекст не является «инструментом для управления состоянием»

Вот прям как раз недавно была статья про то, что context + useReducer не лучшая идея для управления состоянием.

JS и его запретные тайны

Объясните пожалуйста почему в примере

function a() {
  this.counter = 1;
  function b() {
    this.counter = 2;
  }
  b();
  console.log(this.counter);
}

const b = {a: a};
b.a();

выводится 1 а не 2? Почему функция b принимает контекст window а не контекст текущего вызова функции b.a()?

Почему это антипаттерн?

ИМХО меняете шило на мыло как по мне. Как минимум, вы могли бы иметь index.js файл для компонентов, в котором бы экспортился законнекченный к стору компонент, и соответственно когда вам нужна связь с хранилищем вы юзаете его, когда нет — используете напрямую Component.js. Своим подходом вы создаёте жёсткую связь (что является антипаттерном в программировании в принципе, вспоминаем high cohesion и low coupling) между компонентами.
Ну и плюс в вашем подходе нужно разбираться, у него могут быть свои подводные камни, а с redux уже всё всем понятно и всё известно. Так что как по мне, не стоит изобретать велосипед в очередной раз.

The Clean Architecture на TypeScript и React. Часть 1: Основы

А в чём собственно сложность тестирования? Если мы например берём redux, то там всё достаточно просто. Это ж просто чистые функции.

И ещё интересно, где в такой архитектуре хранилище? В бекендах хранилищем обычно выступает БД. Вам же всяко информацию где-то надо хранить (надеюсь не предполагается этого делать в моделях). И тут приходим к тому что всё равно нужно что-то типа redux (единый источник правды), иначе будут проблемы с неконсистеными состояниями и всем тем что react сообщество успешно побороло 4+ лет назад

Мне кажется, даже размер команды, и размер приложения это ещё не повод выбирать именно чистую архитектуру. Как вариант, приложение можно разбить на несколько разных модулей (lerna/monorepo), контролируя тем самым их размер. И это будет тоже довольно просто поддерживать и расширять.

The Clean Architecture на TypeScript и React. Часть 1: Основы

Ну не знаю…
Пилю средне-большие проекты на react-redux и никаких архитектурных проблем не встречал. Как по мне это overengeenring, т.к. в основном все правила бизнес логики должны быть реализованы на бекенде. А ради валидации формы пилить такой огород классов и связей…
ИМХО на бекенд/native приложения это ложится гораздо лучше.

Пишем современный маршрутизатор на JavaScript

Сохраняется контекст если передать метод по ссылке.
Обычное такое используют в обработчиках событий. Конкретно тут, да, это можно считать лишним.