IN
есть возможность это очень скользкая формулирока) проект относительно небольшой, но с большими планами на развитие
Ну тогда по-другому: лид понимает выгоды переделки, и есть ресурсы порефакторить без серьёзного ущерба для сроков
Size: a a a
2020 April 09
I
я на такой позиции, что могу протащить. А лично сам уверен что это окупится уже на дистанции меньше чем пол года
IN
у MobX я вижу 2 проблемы:
- огромный бандл
- если что-то пошло не так, то фиг отладишь
- огромный бандл
- если что-то пошло не так, то фиг отладишь
Надо приспособиться, и выработать нормальный подход, и странных глюков почти не будет.
С бандлом - да. Можно бы и поменьше.
С бандлом - да. Можно бы и поменьше.
I
нет времени на надо приспосабливаться)
I
реатом тем и подкупает что приспосабливаться почти не надо, а легче значительно становится
IN
я на такой позиции, что могу протащить. А лично сам уверен что это окупится уже на дистанции меньше чем пол года
Скорее всего, окупится. У нас на проекте только вот начали использовать, и я уже вижу, что окупается.
IN
реатом тем и подкупает что приспосабливаться почти не надо, а легче значительно становится
Подкупает. Но для него прикольно бы ещё написать (или найти, если они есть) решения как в MobX - чтобы сделал класс с декораторами @action, переменными и методами, которые изменяешь и вызываешь - а атомы и экшены создаются сами. Вот тогда и MobX можно будет выбросить. И это будет лучше MobX, потому что есть Redux DevTools, где всю кухню можно увидеть
I
не люблю использовать то, чего нет в JS.
I
Артём насколько я знаю такого же мнения
I
но что мешает тебе самому это реализовать и послать PR
I
по идее там ничего такого вроде
IN
не люблю использовать то, чего нет в JS.
Декораторы есть и будут (уже их столько юзают, что никто от них не посмеет отказаться). А я и хочу сделать @reatom/<MobX>, просто не добрался ещё
I
ну один раз уже сломали декораторы, не факт что не повторится
IN
ну один раз уже сломали декораторы, не факт что не повторится
В typescript - норм, в babel - да, увы.
I
у нас ни бабеля, ни тайпскрипта)
I
точнее TS есть, но он исплючительно как тайпчекер
I
а сборка через ClosureCompiler
I
а в целом проблема декораторов в том, что они не могут изменить сигнатуру
IN
а в целом проблема декораторов в том, что они не могут изменить сигнатуру
Да. И они подменяют реальный тип другим. Это кстати, тот же самый вопрос, что и useAction вместо dispatch. Но в MobX-подходе, на мой взгляд, декораторы допустимы. Хотя можно и без них. Я ещё помозгую на эту тему.
Если делать в стиле реатома, то должен быть какой-то хитрый declareController, который берёт класс/объект и делает из него набор атомов/экшенов, доступных через объект пропертями и методами.
Если делать в стиле реатома, то должен быть какой-то хитрый declareController, который берёт класс/объект и делает из него набор атомов/экшенов, доступных через объект пропертями и методами.
Pf
там Мишель, кстати, от декораторов то собирается избавляться 😕
https://github.com/mobxjs/mobx/issues/2325
https://github.com/mobxjs/mobx/issues/2325