Запланированный срач в комментариях, чтоб скрыть лживую суть статьи. Запланированное устаревание - это важный атрибут капиталистической системы. Без него капитализм Работать не будет. Ликвидация капитализма началась, а значит и запланированное устаревание исчезнет. Рациональный расход ресурсов должен быть превыше всего…
Примеры не вполне корректные: когда мы получили false из метода this.push — это означает, что данные не были успешно записаны/считанны. В реальном коде лучше преостанавливать ход выполнения кода на этом месте, очистить буфер, и лишь потом продолжать выполнение кода. В противном случае, мы рискуем написать код, который не выполняет свое предназначение (застряет на каком-то месте и не записывает/считывает все необходимые данные).
Да уж, инженеры Apple явно идут на поводу у тупых менеджеров, которые ничего не слышали об элементарной логике. Не думал, что когда-то скажу такое, но даже в Microsoft дела обстоят лучше. Идеал, конечно Linux, где все просто и логично.
У меня другая проблема: я хочу зафиксировать изображение на одном мониторе, при этом на втором переключаться между рабочими областями. На мой взгляд, это один из наиболее частых сценариев использования двух и более мониторов. К сожалению, пока решения не нашел
Пробую создать локально такой же пример — у меня нет разницы между memo и не memo… Возможно, я что-то неверно понимаю. Можете скинуть информацию на более развернутое объяснение, как это должно работать?
Да, согласен. Пожалуй, react-scripts — это самое слабое место ReactJS. Я до сих пор не понимаю, как можно тащить столь отвратительный код такое долгое время. Полно есть альтернативных вариантов с нормальной архитектурой. Надеюсь, что это исправят в скором времени. Я и сам готов заняться этой задачей, если буду уверен, что обновление примут…
Однако, что касается самих решений, тут React чуточку впереди. Библиотек больше и среднее качество их лучше. По крайней мере для тех задач, с которыми я успе столкнуться на обоих фреймворках
Меня немного подергивать начинает, когда начинают писать про некий абстрактный «бизнес», который почему-то должен решать. Бред это. Не должен. Бизнес для людей. Интерес к разработке, — тоже для людей. Если разработчику не нравится его работа — он не сможет сделать ее хорошо. Так что, бизнес что угодно может решать, если разработчикам будет неинтересно работать с технологиями, которые продиктует бизнес — загнется такой бизнес.
Вы пишите о разных вариантах решения задач. Вы знаете ответы. У вас их много. Не знаю, как у вас, у меня с компонентами-классами не всегда хотя бы одно решение находилось, а с хуками их много, — это ли не прекрасно?
У меня линтер отлавливает неверные зависимости.
Все проблемы, о которых вы пишите были и раньше, просто вы их не замечали под капотом. Он просто ждали своей очереди…
По сравнению с React Vue все еще слабоват. Те задачи, которые давно решены для React и Angular, все еще открыты для Vue. Наличие разных вариантов возможности разработки на Vue заставляет тратить время на выбор вариантов. В этом плане круче всех Angular. React что-то среднее в этом плане
Очевиднее в каком смысле? Возможно, очевиднее с точки зрения внутренней реализации. Но мне в момент разработки не очень важна внутренняя реализация, мне важна наглядность. Как по мне, hooks нагляднее и лаконичнее. Все мы любим простой понятный лаконичный код. Хуки позволяют добиваться этого с меньшим количеством усилий.
Преимущество одной точки входа в том, что все реакт компоненты могут быть связаны при необходимости общим глобальным состоянием, что очень удобно, как верно заметил Ваш оппонент
Старался написать что-то новое, но, скорее, склонен с вами согласиться, чем оспаривать очень близкие к истине вещи. Хоть я и искренне считаю hooks лучше компонентов-классов.
Да, интересные мысли. Тоже об этом задумывался. Но тогда Angular и Vue выполняют похожие задачи.
Я в последнем приложении (оно вполне себе большое) начал повсеместно использовать hooks, — и это моей команде дало возможность проще переиспользовать повторяющиеся куски кода (ранее для этих целей мы использовали HOC, что было гораздо менее наглядно и понятно). Покрывать тестами hooks, проще чем HOC-и. Опять же, все это субъективно.
По поводу заговора, тоже согласен. Он вполне может быть. Хотя я больше верю в благие намерения, не компаний, но разработчиков.
Речь о том, что в подавляющем большинстве случаев две React точки входа в приложении можно заменить одной. По моему, сугубо субъективному мнению, именно так и нужно поступать. Согласование двух React точек входа сложнее потому, что нужно согласовывать:
1. Обе React точки входа между собой
2. Первую React точку входа с приложением
3. Вторую React точку вохода с приложением
Для каждой из этих 3х задач придется писать свои велосипеды.
Если оставить всего одну точку входа React в проложении, то согласовывать нужно будет только одну эту точку с приложением — и все. Причем это решение будет очень близким к конкретному куску документации React.
Я трижды решал эту задачу разными способами. Лучшее решение (последнее) — это одна точка входа.
Да, верно, их кто-то написал. Как правило хорошие библиотеки получаются у тех, кто попробовал все существующие и понял, как сделать лучше. Хорошая библиотека редко получится у человека, который ничего не пробовал, ничем готовым не пользовался и с первого раза создал шедевр.
Запланированный срач в комментариях, чтоб скрыть лживую суть статьи. Запланированное устаревание - это важный атрибут капиталистической системы. Без него капитализм Работать не будет. Ликвидация капитализма началась, а значит и запланированное устаревание исчезнет. Рациональный расход ресурсов должен быть превыше всего…
Однако, что касается самих решений, тут React чуточку впереди. Библиотек больше и среднее качество их лучше. По крайней мере для тех задач, с которыми я успе столкнуться на обоих фреймворках
У меня линтер отлавливает неверные зависимости.
Все проблемы, о которых вы пишите были и раньше, просто вы их не замечали под капотом. Он просто ждали своей очереди…
Преимущество одной точки входа в том, что все реакт компоненты могут быть связаны при необходимости общим глобальным состоянием, что очень удобно, как верно заметил Ваш оппонент
Я в последнем приложении (оно вполне себе большое) начал повсеместно использовать hooks, — и это моей команде дало возможность проще переиспользовать повторяющиеся куски кода (ранее для этих целей мы использовали HOC, что было гораздо менее наглядно и понятно). Покрывать тестами hooks, проще чем HOC-и. Опять же, все это субъективно.
По поводу заговора, тоже согласен. Он вполне может быть. Хотя я больше верю в благие намерения, не компаний, но разработчиков.
1. Обе React точки входа между собой
2. Первую React точку входа с приложением
3. Вторую React точку вохода с приложением
Для каждой из этих 3х задач придется писать свои велосипеды.
Если оставить всего одну точку входа React в проложении, то согласовывать нужно будет только одну эту точку с приложением — и все. Причем это решение будет очень близким к конкретному куску документации React.
Я трижды решал эту задачу разными способами. Лучшее решение (последнее) — это одна точка входа.