Не следует: возвращать новые массивы или новые объекты из mapStateToProps. Если объект подлежит возврату, убедитесь, что он не будет изменен в дальнейшем. Это может привести к повторной визуализации всего компонента и поддерева при малейшем изменении этого объекта. 

Do: mapstateToProps должен возвращать только примитивы и массивы, полученные непосредственно из состояния (не создавайте новый массив из mapStateToProps, при необходимости создайте селектор, который кэширует результирующий массив в результате вычисления аргументов). Массивы, которые будут повторяться позже, должны содержать строковый идентификатор отображаемого элемента. Элемент списка отвечает за поиск информации о глобальном состоянии с использованием идентификатора, переданного из реквизита.

Делайте: При создании собственного перехватчика убедитесь, что возвращаемый массив также запомнен. Предварительная оптимизация не приветствуется, но почему бы не создать что-то наиболее оптимальным способом, который только возможен, это не требует значительных усилий и способствует обучению других инженеров, работающих над кодом. Повышайте квалификацию команды!

Делайте: при построении большого объекта располагайте ключи в алфавитном порядке. Объекты, вероятно, будут увеличиваться в размерах, и поиск свойства может занять очень много времени. Особенно в магазине, убедитесь, что переходники расположены в алфавитном порядке.

Не делайте этого: создавайте редукторы, специфичные для создаваемой вами страницы/экрана. Подумайте, как это можно масштабировать на другие страницы/экраны. Проконсультируйтесь с командой, чтобы увидеть возможные будущие варианты использования страниц/экранов, которые вы создаете.

Сделайте: обязательно обеспечьте взаимодействие с внешними API с помощью специально созданного API. Если в будущем услугу потребуется заменить, это можно будет сделать с помощью специального API. Вспомните, например, Багснэга. Оберните этого малыша в специальный API на тот случай, если вы захотите использовать Sentry в будущем.

Делайте: В том же духе. Пожалуйста, стандартизируйте способ обработки ошибок на серверной части, а также на внешнем интерфейсе. Каждое действие в приложении должно быть заключено в блок try/catch, а блок catch отправляет отчеты в инструмент отчетов об ошибках. Ваше приложение также должно обернуть все приложение границей ошибки. Я считаю, что существует правильный способ установить правильный шаблон. Шаблон, способный отловить все ошибки и сообщить значимую информацию.

Сделайте: используйте инструмент, обеспечивающий качество кода, например Sonar. Это сэкономит много времени при проверке кода только потому, что кто-то решил использовать if ... else вместо if ... return. . Мелкие детали, которые заставляют разработчика быть менее креативным и просто следовать тому, что говорят стандарты качества кода. Кодовую базу, которая досконально учитывает даже эти детали, легко кодировать с первого дня.

Заключение

Это все мнения, которые у меня есть на данный момент. Имея кодовую базу, которая применяет шаблоны, люди могут подключиться и взять фрагмент кода из другого места кодовой базы, вставить его, немного изменить формулировку и вуаля, у вас есть функция, которая соответствует производственным стандартам во всех возможных отношениях. Есть мнения, но действительно существует наиболее эффективный способ ведения дел, по крайней мере, на момент написания. Могут появиться и другие подходы, но наиболее производительный способ написания кода на момент написания — единственный способ написания кода. Легче сказать, чем сделать, пока вы не столкнетесь с монстром сроков.