React Page рекомендует рекомендацию поддерживать логику на высоком уровне

Question

Я читал довольно много вещей, которые недавно пытались выучить реакцию и лучшие практики, и я неоднократно сталкивался с предложениями, говорящими: «Постарайтесь сохранить свою логику так высоко в цепочке, как возможное".

Я не понимаю, почему это предложение . Я понимаю, что это немного упрощает код, но я не вижу, как это обязательно будет хорошей практикой для проектов, которые становятся большими и сложными. Я также понимаю, что идеология, стоящая за реагированием, - «dom - медленный javascript быстро», и что переписывание shadow-DOM и «diff'ing» делает повторный рендеринг в DOM быстрее, но это просто кажется огромной тратой вычислительной техники время. Когда проект становится более интерактивным и более динамичным, похоже, что он перекомпонует то, что потенциально может быть длинным списком, скажем, более 1000 предметов, и будет тратить процессор вместо того, чтобы просто проверять (добавлять, перемещать, удалять и т. Д. .), что резко сократило бы CPU.

Есть ли причина, по которой подход к алгоритму Facebook рекомендуется использовать?

Answer 1

Я не уверен, что совет обязательно направлена ​​на людей, строящих очень большие и сложные приложения, которые сами по себе, хотя это не плохой совет, и я лично до сих пор считаю, что это хорошая идея, чтобы централизовать государственной манипуляции логики (например, флюс или другие аналогичные шаблоны «за пределами реакции»). Я думаю, что совет направлен прежде всего на людях, новых Реагировать, чтобы побудить их разработать способ мышления о написании идиоматического Реагировать код:

1. государство от высших компонентов уровня просачивания в ребенок через реквизит.
2. Компоненты нижнего уровня влияют на данные путем вызова обратных вызовов, передаваемых через реквизиты.
3. Модель декларативного программирования Embrace React и позволяйте виртуальному DOM заботиться как можно больше.
4. Не имеют логики, зависящей от бизнес-домена, во всей иерархии компонентов; попробуйте переместить его в верхнюю часть.
5. Аналогичным образом, не должно быть состояний, связанных с бизнес-доменами, по всей иерархии компонентов; держите его к вершине (или, как я уже упоминал, вне Реагирования целиком).

В моем опыте, следуя этим советам творит чудеса для создания кодовую легче понять и поддаются изменению, особенно как кодовая растет в размерах и сложности.

Но, как и любой другой совет или «лучшая практика», это не значит, что вы не должны анализировать его критически. Если у вас есть список из 1000 элементов, и производительность становится проблемой, тогда, конечно, переместите эту логику в лучшее место, реализуйте кеширование или переходите к API более низкого уровня. Но я все еще думаю, что совет хорош вообще - Я бы делал только те вещи, если бы производительность действительно была проблема. Слишком многие люди забывают остальную часть цитаты:

Мы должны забыть о небольших эффективности, скажем, около 97% времени: преждевременная оптимизация есть корень всех зол. Однако мы не должны упускать наши возможности в этих критических 3%.