newhacke, у меня нет такой статистики и я думаю ни у кого нет. Лично мне mst показался чрезмерно громоздким и mobx вполне достаточно. Кто-то может считать по другому, или будут другие проекты где mst хорошо подойдет.
В любом случае - хотите их использовать - сначала нужно вникнуть в mobx. Там уже поймете надо вам mst или нет
тут нужен не пример, а разобраться в темах:
1. модули и испорт - экспорт. что такое commonjs и native ecmascript модуль, и выбрать какую форму вы хотите использовать, а то вы то так пишете то так.
2. прочитать зачем нужны классы сами по себе и зачем нужно наследование, когда оно применяется. А так же чем композиция отличается от наследования. Наследования у вас технически не дает ошибок но по логике приложения совершенно не правильно. CLI не является субклассом ParseFile
По тому коду что вы скинули - вам вообще класс ParseFile, не нужен, замените его на функцию, эту функцию импортируте и вызывайте напрямую.
вы по описанию не технического директора ищете а разового консультанта для написания плана разработки-поддержки.
Технический директор это не тот кто "рассчитает стоимость с последующей возможной работой в проекте" а "человек который будет отвечать за разработку-создание продукта и иметь право принимать решения касающиеся технической части проекта".
Сформулируйте кого вы ищете точнее - быстрее найдете.
SannX, от этого и зависят ваши ошибки и то как можно это исправить. Если вы подключаете бабель тегом, и компилите jsx на лету, добавляя type="text/babel", то надо смотреть что там бабель выдает в итоге в той строке где у вас импорт.
А вообще вы используете подход "чтобы по быстрому поиграться", который в самой документации не рекомендуют использовать, не стоит от него ждать что все заработает сразу. Вот вы прогирались - теперь время делать все по нормальному.
Если выбрали его - будьте готовы к тому что надо сидеть и разбираться. что там происходит с импортом, как бабель это все компилит, может ли react-csv-reader работать как нативный модуль в браузере, или нет и прочие мелочи.
Если вы ждете готовый ответ на это-вряд ли вам его кто-то даст.
Лучший вариант, сделать сборку как общепринято, с бандлером и избавить себя от ненужных проблем.
beem7, Хорошо, я уже понял что вы думаете по три дня, никак не коммуницируя с командой, и потом выдаете какой-то гиганский кусок кода в котором никто не в состоянии разобраться.
Я только никак не могу понять почему вы считаете это за положительное качество. Как по мне - одни минусы.
Мало того что думаете долго, так потом еще и выдаете что-то в никто не может разобраться. Тут варианта два - или у вас набирают уборщиц на ревью, которые ни в зуб ногой в программировании, или ваш код настолько говнокод что для других разработчиков стоит огромных трудов в него вникнуть. И что-то мне подсказывает что второй вариант реальнее.
А за позицию "мой код не могут понять потому что все в команде тупые, один я тут способен думать", я бы уволил не на 3-й день а на первый. Даже если ваш код вдруг реально хорош.
wOneBvll, если прислушивается, тогда есть шанс - расспросите его, что для него важно, какие моменты, скорость разработки, интеграция с бекендом, SEO и так далее и просто сравните по этим параметрам возможные решения.
Может там кода будет 1000 строчек и действительно нет смысла огород городить (что вряд ли)
Чтобы набраться аргументов - прочитайте разные филосовские статьи про реакт и вью - хотя бы прямо в доках, там много написано про мотивацию, про то какие плюсы дают фреймворки и так далее.
beem7,
Я вполне могу понять что вы видите свой "перфекционизм" как крутое качество и определенное превосходство которых нет у "обычных" людей, но вот только почему-то именно "обычные" люди делают крутые продукты, качественнее, быстрее, и продуманнее,
а "перфекционисты" обычно балластом идут, сидя в думах об идеале. Их хорошо ставить на рутину, вперед такие люди ничего не двигают.
можете мне примеры не придумывать, я тоже бывший "перфекционист".
Если вы всю жизнь делаете табуретки, то возможно эта "особенность" и норм - лет через 10 ваши фантазии об идеальном мире догонят реальность и табуретки начнуть у вас получаться вполне неплохо.
В программировании такое точно не подходит - тут надо уметь делать хорошо сразу и быстро.
Рутины, в которой перфекционизм как-то помогает становится все меньше и меньше. Времена когда программные системы разрабатывались 5 лет и потом еще сопровождались 15 проходят.
CryNet, вряд ли я смогу рассказать лучше и доступнее чем статья на эту тему в доках реакта. Дам даже видос с докладом есть на эту тему, описана мотивация их введения и прочее.
насчет запомнить - в 90% случаев - это будут useState и useEffect. Вот, вы уже запомнили.
Из собственной практики - заметно меньше кода, проще интеграция с внешними библиотеками, все концепты упрощаются не теряя в функциональности. Переиспользование кода лучше. Типизация лучше - в большинстве случаев TS выводит все типы правильно автоматом, меньше писать явных типов руками, а тайпчекинг при этом работает лучше.
из минусов - код с хуками легче превращается в лапшекашу в неумелых руках чем код на классах.
8XL, Спасибо за рекомендацию. А вам я рекомендую перечитать вопрос, мой ответ и постараться понять о чем шла речь на самом деле. И поменьше попыток показаться умнее, это чаще всего приводит к обратному эффекту.
В любом случае - хотите их использовать - сначала нужно вникнуть в mobx. Там уже поймете надо вам mst или нет