Простите, а вы уверены, что это Редакс, а не что-то похожее? Я не зря упомянул не только дерево (которое типизировать несложно, хоть и не очень красиво), но и connect (функция редакса) с компонентом
МобХ мне кажется значительно проще за счет отсутствия непонятно зачем нужных строковых констант, более удачных ключевых слов, отсутствию иммутабельности (поменять объект где-то в середине глубокого дерева для неподготовленного человека может оказаться непосильной задачей).
Простите, я крайне редко пишу импорты руками, обычно их вставляет IDE, потому мне сложно понять тот аргумент.
Может они плохи для редакс-приложений, где куча всего экспортится и нету основного импорта, но для подхода один файл — один класс они вполне ничего.
Все проблемы с ИДЕ, которые еще есть — должны решаться, я думаю, в самих ИДЕ.
Хотя я согласен, что они — не идеальные, но называть их худшим, что могло случиться, что их нужно забанить по-умолчанию и так далее — это уже слишком, мне кажется.
Типизация: покажите мне пример, где я из стора достаю данные, передаю в компонент через connect и оно проверяет типизацию в компайл-тайм. И вообще — я бы с удовольствием посмотрел на типизированный стор. Или как вы ваш action=>state=>state типизируете?
Код редюсеров растет за счет количества похожих редюсеров, а не за счет увеличения ответственности редюсеров
Вот только инкапсуляция протекает, если такие компоненты необходимо расширять
Я не видел тестов, которые проверяют реальную логику работы. Те тесты которые я видел — бесполезны. Я грешу на недо-фп и болезненную боязнь абстракций, в результате функции становится сложно тестировать. Все-таки простой объект легче покрыть тестами, чем функцию, которая возвращает функцию, которая возвращает функцию.
Мне сейчас очень нравится MobX. В сравнении с редаксом — как на мерс после жигулей пересел. Значительно ниже порог входа — всего три ключевых слова, которые необходимо понять, однонаправленный поток как основное преимущество флакса и никаких недостатков редакса. Код выглядит понятным, легко поддерживается, быстро работает. Один человек может писать слой MobX (модель), выдавать вменяемый и понятный API, а другой использует этот слой в Реакт-слое (view)
Например, потому что Редакс — отвратительная процедурная быдлокодерская поделка, поощряющая копипасту и плохой код, плохо типизируется статически, библиотечные компоненты делают дерево данных кривым, код редюсеров растет как на дрожжах, из-за чего сложность поддержки растет значительно быстрее, чем у более адекватных вещей, а как следствие — на нем крайне сложно поддерживать продукт в длинносрочной перспективе. Плюс у него еще иллюзия простоты, а на самом деле крутая кривая обучения, Как результат — код устаревает с ростом навыка команды слишком быстро, а из-за недо-фп и отрицания хипстерами типизации сложно адаптировать старый код в новом стиле. Я еще, если честно, никогда не видел адекватных юнит-тестов в проектах с ним, но, может кто-то сможет мне такие показать
Вполне возможно, что там есть оптимизации, которые не создают скрытый класс до того, Как закончится выполнение конструктора (или замыкание контекста в нем)
Даже если такого пока нету — Не стоит делать изменения в коде, рассчитанные на текущую версию одного из популярных браузеров — оптимизация может внезапно быть добавлена в следующей версии, а ваш хак перестать работать. Или быть изначально практически ненужным.
Обычно хороший код декомпозируется, потому в качестве колбека передается ссылка на метод или функцию и bind чаще всего использовать легче и лучше для кода, чем даже let.
Да и в IE только начиная с 11-й поддерживается, если верить mdn.
Ну, возможно вы и правы, тот дефолт, что есть сейчас в жс — Не очень.
Простите, а вы уверены, что это Редакс, а не что-то похожее? Я не зря упомянул не только дерево (которое типизировать несложно, хоть и не очень красиво), но и connect (функция редакса) с компонентом
Про ТриШейк, простите, не понял
Простите, я крайне редко пишу импорты руками, обычно их вставляет IDE, потому мне сложно понять тот аргумент.
Может они плохи для редакс-приложений, где куча всего экспортится и нету основного импорта, но для подхода один файл — один класс они вполне ничего.
Все проблемы с ИДЕ, которые еще есть — должны решаться, я думаю, в самих ИДЕ.
Хотя я согласен, что они — не идеальные, но называть их худшим, что могло случиться, что их нужно забанить по-умолчанию и так далее — это уже слишком, мне кажется.
Может, недостаток не в самом импорте, а в том, что он может быть неименованным?
А что плохого в одинаковых названиях?
Например, потому что Редакс — отвратительная процедурная быдлокодерская поделка, поощряющая копипасту и плохой код, плохо типизируется статически, библиотечные компоненты делают дерево данных кривым, код редюсеров растет как на дрожжах, из-за чего сложность поддержки растет значительно быстрее, чем у более адекватных вещей, а как следствие — на нем крайне сложно поддерживать продукт в длинносрочной перспективе. Плюс у него еще иллюзия простоты, а на самом деле крутая кривая обучения, Как результат — код устаревает с ростом навыка команды слишком быстро, а из-за недо-фп и отрицания хипстерами типизации сложно адаптировать старый код в новом стиле. Я еще, если честно, никогда не видел адекватных юнит-тестов в проектах с ним, но, может кто-то сможет мне такие показать
Аргументируйте
Вполне возможно, что там есть оптимизации, которые не создают скрытый класс до того, Как закончится выполнение конструктора (или замыкание контекста в нем)
Даже если такого пока нету — Не стоит делать изменения в коде, рассчитанные на текущую версию одного из популярных браузеров — оптимизация может внезапно быть добавлена в следующей версии, а ваш хак перестать работать. Или быть изначально практически ненужным.
Не распространяется на то, чего нет.
Вы видели неотрицательный комментарий про Гитлера, срочно помойте глаза с мылом и помолитесь на портрет Путина.
В данном случае это лишь пример того, что названное твоим именем насекомое — это честь, а не унижение.
Какой-то стремный сайт. Когда я ввел свой год рождения в автодополнении предложило отправить номер банковской карты
Да и в IE только начиная с 11-й поддерживается, если верить mdn.
2. Будут идти горизонтальные полоски слева направо