Если проект становится большим, это вовсе не означает, что State Manager надо превращать в коробку для хранения всего. Есть глобальное состояние приложения (его много не бывает), есть локальное состояние. На MobX у вас есть возможность создавать нормальное локальное состояние без проблем. Хотя в последнее время я больше тяготею к хукам, у MobX есть свои плюсы. А вот для чего мне Redux тогда я не понимаю. Думаю, его используют в основном не потому, что он нужен, а потому, что "все используют". Карго-культ)
Скорее всего, проблема в разработчиках, а не в MobX. Лучше расскажите, в чём именно заключается проблема и покажите на примере. У вас есть View (JSX) и ViewModel. Также, могут быть какие-то модели и сервисы на MobX (если нужна реактивность).
Вы сами сколько стартапов запустили? Если нисколько, то советы не имеет смысла. Если хотя бы 1, то советы могут иметь смысл, но они вряд ли на что-то повлияют, т. к. факторов, почему стартап взлетел или не взлетел, может быть огромное множество (и должно повезти, чтобы это множество факторов сошлось). И вряд ли они будут даже близко похожи на ваши предложения, т. к. причина, по которой не взлетел стартап, может быть абсолютно нетривиальной. У каждого свой путь и если бы была работающая инструкция о том, как сделать стартап, ей бы уже давно воспользовались и у нас было бы 100% успешных стартапов. Но в реальности у каждого будет свой путь, свой опыт.
Если вы не хотите даже понять, почему такой код считается плохим, как вы будете прогрессировать? Огромный кусок на 2K с лишнем строк, сплошные if-else-if-else, смазанные switch-case, огромные функции, все в перемешку. Если пытаться тут что-то улучшать, в какой-то момент вся эта конструкция развалится.
Не перекладывайте ответственность за архитектуру на MobX, пожалуйста. Если вы решили все запихнуть в один класс, это, извините, ваша вина, т. к. всегда есть возможность разделить модель на более мелкие модели и отделить модель от модели отображения. У самого была такая проблема, но когда начал рефакторить и делить по слоям, все стало значительно лучше. Да, с первого раза не всегда получается, это нормально и не повод винить в этом то, что плохо изучено.
Кстати, насколько пет-проект раздулся-то?
И чего заминусовали человека? Все правильно — есть инструмент решения проблемы, есть архитектура. MobX в принципе не ограничивает выбор архитектуры. Не MobX плохой, а разработчик просто не сумел его приготовить.
Переоценка значимости частных случаев
Можно, если интересовался этим и практиковался. И не важно, есть при этом корочка, или ее нет.
Процентное отношение не зависит от количества людей
Правильно для того, кто не способен написать функциональный компонент грамотно
Проблема не в хуках, а в прослойке между монитором и креслом. Если делать все правильно, у вас не будет 100 строк в функциональном компоненте.
Про атрибуты на дочерний шаблон - в точку)
Если проект становится большим, это вовсе не означает, что State Manager надо превращать в коробку для хранения всего. Есть глобальное состояние приложения (его много не бывает), есть локальное состояние. На MobX у вас есть возможность создавать нормальное локальное состояние без проблем. Хотя в последнее время я больше тяготею к хукам, у MobX есть свои плюсы. А вот для чего мне Redux тогда я не понимаю. Думаю, его используют в основном не потому, что он нужен, а потому, что "все используют". Карго-культ)
Зачем 100, если можно 0?)
Почему если React, то сразу значит "+Redux"? Вовсе необязательно :)
Скорее всего, проблема в разработчиках, а не в MobX. Лучше расскажите, в чём именно заключается проблема и покажите на примере. У вас есть View (JSX) и ViewModel. Также, могут быть какие-то модели и сервисы на MobX (если нужна реактивность).
Вы сами сколько стартапов запустили? Если нисколько, то советы не имеет смысла. Если хотя бы 1, то советы могут иметь смысл, но они вряд ли на что-то повлияют, т. к. факторов, почему стартап взлетел или не взлетел, может быть огромное множество (и должно повезти, чтобы это множество факторов сошлось). И вряд ли они будут даже близко похожи на ваши предложения, т. к. причина, по которой не взлетел стартап, может быть абсолютно нетривиальной. У каждого свой путь и если бы была работающая инструкция о том, как сделать стартап, ей бы уже давно воспользовались и у нас было бы 100% успешных стартапов. Но в реальности у каждого будет свой путь, свой опыт.
Это так не работает) Чтобы гарантировать что-то, надо в любом случае в рантайме проверять
Тем не менее, Typescript не является "серебряной пулей" и на самом деле даёт иллюзию типо-безопасности. При этом, конечно, плюсов у него много.
Как и Xiaomi. Наверняка и там есть настройка для отдельных приложений, где можно отключить эту убивалку фоновых процессов))
По поводу интервальных напоминаний — сам недавно искал такое. Теперь нашел :))
Правда, уже не нужно, но если что, буду знать)
Если вы не хотите даже понять, почему такой код считается плохим, как вы будете прогрессировать? Огромный кусок на 2K с лишнем строк, сплошные if-else-if-else, смазанные switch-case, огромные функции, все в перемешку. Если пытаться тут что-то улучшать, в какой-то момент вся эта конструкция развалится.
Практически невозможно
Кстати, насколько пет-проект раздулся-то?