Modin

По поводу мобилок хороший аргумент, по поводу кита не совсем согласен. На проекте может быть штук 7 разных шрифтов, это значит неизбежно появление small, superSmall, extraSmall и тд.

Всё пытаюсь понять чем же запись p fontSize=15 более ужасна и менее понятна, чем Title size="small"

Как мне кажется, минус в виде замедления скорости разработки, весьма существенный, с точки зрения бизнеса.

Вот у меня есть вопрос. Сможет ли typescript защитить от неконсистентных данных пришедших с сервера? Можно хоть до посинения типизировать свой код, но однажды с бэка прийдёт строка вместо массива и весь "строготипизированный код" рассыпется как карточный домик. Так и какой тогда смысл от этого полурешения?

Eslint, типы Typescript, Prettier, настройка husky, Storybook и регрессионное тестирование.

Как это говно никуда не денется? Его станет меньше. Куда меньше. Чем больше таких рамок, тем лучше бизнесу. Быстрее фичи, меньше тех. долга, меньше рефакторинга.

Redux-saga-reselect, максимально переиспользуемые компоненты, бесконечные контейнеры-обертки, короче ясно-понятно путешественник из 2016))

Если вы фигачите загрузку данных и прочий бизнес в компонентах, то ваш код очень сильно пахнет, не зависимо от реакта. И callback-hell был еще задолго до того, как ФП стало набирать популярность: в nodejs, например.

Ах да, и модалки которые в редаксе делаются императивно dispatch(showModal(modalName)) было очень больно делать декларативно. Есть вроде чистый компонент таблицы какой-нибудь и давай его пачкать стейтом isVisible итд.

import React from 'react';
import ReactDOM from 'react-dom';

const confirmRoot = document.createElement('div');
const body = document.querySelector('body');
body.appendChild(confirmRoot);

const customConfirm = DialogContent =>
  new Promise(res => {
    const giveAnswer = answer => {
      ReactDOM.unmountComponentAtNode(confirmRoot);
      res(answer);
    };
    ReactDOM.render(<DialogContent giveAnswer={giveAnswer} />, confirmRoot);
  });

export default customConfirm;

customConfirm(Component)/await customConfirm(Component)

Можно тезисно про mobx, чем не устроил и если если переезжать, то на что?

1000 переиспользуемых компонентов

В то время как в Redux у вас есть установленная церемония настройки вещей, MobX менее самоуверен.

Пока какой-то крупный проект не изъявит желание перейти на svetle и его опыт не окажется положительным, надежды на svetle как на конкурента тройки крайне малы, ИМХО.

Можно выводы, стоит ли игра свеч? Насколько быстрее стало рендериться приложение?

Большинство проектов и библиотек работают с Redux — проще интергрироваться при необходимости.

Redux создает каждый раз новый экземпляр stor'a — поэтому можно отследить в reduxDevTools историю изменений stor'а.

Redux — функциональщина которая понятно как работает, mobx — какая то магия.

Во-первых, при наличии таких операций как getUser, элементы хранить надо в Map, а не в массиве.

Во-вторых, если fetchList — единственная мутирующая операция, то имеет смысл использовать observable.ref вместо observable.

В-третьих, откуда вы взяли этот паттерн с оборачиванием Promise в другой Promise?! Зачем вообще внешний Promise нужен?

В-четвертых, action не действует на асинхронные продолжения. Конкретно в приведенном вами коде декоратор action бессмысленный.

Анду/реду;

Оффлайн мод; Лоадинг стейты; Централизованная обработка ошибок;

Канкарент модификации состояний (реализация полноценной асинхронной работы с приложением с участием нескольких пользователей);

Почему — я выше подробно расписал. Голый MobX вы можете сравнить, скажем, с голым Svelte, с react hooks, с knockout и пр.

А текущая статья это как 99% статей про Svelte где вам показывают 2+2 и спрашивают, а чего это вы все ещё не пишете на Svelte? :)

Если реакт использовать для чисто серверного рендеринга где все страницы рендерится на сервере

class Users {
   @observable list = [];
   @action getUser = (id) =>{
       return this.usersList.filter(user => return {user.id == id})
   }
   @action fetchList = () => {
       return new Promise((resolve, reject) => 
                api.get('someUrl')
                    .then(res=> {
                          this.list = res.data;
                          resolve()
                     })
                   .catch(e => reject(e))
       )
   }
}

try {
    await Users.fetchList();
    Users.getUser(id);
} catch(e){
    console.log(e)
}