{"draftJsState":{"blocks":[{"data":{"image":{"id":"659bc193438ebb098779e9db"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"bbmsi"},{"data":{},"depth":0,"entityRanges":[{"key":0,"length":22,"offset":10}],"inlineStyleRanges":[],"text":"Источник: Nuances of Programming","type":"unstyled","key":"90f8m"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Поговорим о принципах SOLID с точки зрения приложений React. Я прекрасно понимаю, что статей на эту тему уже достаточно много, и знаю это потому, что прочитал большинство из них. Должен сказать, что не согласен с тем, как подается информация в таких материалах (иначе я бы, конечно, не стал публиковать эту статью). Проблема, на мой взгляд, заключается в том, что авторы рассказывают только о том, как прекрасны принципы SOLID, не упоминая об их возможных изъянах и подводных камнях. Никто не задается вопросом: а применимы ли вообще принципы SOLID в React-приложениях? Именно это мы и обсудим, так что читайте дальше.","type":"unstyled","key":"7g1l1"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Глава S: Single Responsibility Principle (принцип единой ответственности)","type":"header-three","key":"a983d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":66,"offset":123,"style":"BOLD"}],"text":"Самый первый принцип максимально прост для понимания: компонент должен иметь единую ответственность, или, другими словами, должна быть только одна причина для существования этого компонента.","type":"unstyled","key":"aqe2k"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Однако если переключиться из режима потребления в режим мышления, то можно сразу же заметить одну проблему. Учитывая то, что любой нелистовой компонент в приложении является корнем поддерева, существует вероятность того, что почти наверняка некоторые из компонентов будут иметь более одной ответственности: у компонента пять дочерних компонентов, и он контролирует состояние трех из них. Таким образом, корневой компонент App в значительной степени нарушает этот принцип!","type":"unstyled","key":"dbicr"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Так что же делать? Как применять принцип единой ответственности? Если внимательно присмотреться, то можно обнаружить две группы компонентов: те, которые легко спроектировать с учетом принципа единой ответственности; и другие, своего рода оркестранты, на которых лежит большая ответственность (или контроль). Вы можете называть их умными/глупыми компонентами, контейнерными/презентационными — не имеет значения, лишь бы вы понимали суть этого разделения.","type":"unstyled","key":"34tc"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":24,"offset":18,"style":"BOLD"},{"length":21,"offset":44,"style":"BOLD"}],"text":"Я буду называть их Менеджерами (Managers) и Работниками (Workers). Считаю, что, введя простой набор правил, можно заставить все компоненты приложения соблюдать принцип единой ответственности. Дадим определение этим правилам.","type":"unstyled","key":"dlt88"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Менеджеры никогда не должны выполнять работу за Работников, другими словами, их единственной обязанностью является контроль и композиция Работников (или других Менеджеров).","type":"ordered-list-item","key":"bedpo"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Работники не должны быть в курсе бизнес-логики и должны делегировать задания только другим Работникам, а не Менеджерам.","type":"ordered-list-item","key":"adq07"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Обдумаем эти два правила. Что означает фраза “Менеджеры никогда не должны выполнять работу за Работников”? Это значит, что Менеджеры никогда не должны иметь собственного JSX-содержимого. Все, что они возвращают, должно состоять только из Работников и/или других Менеджеров, или, говоря еще проще, у них не должно быть собственных HTML-элементов. Как следствие, у них не будет и CSS, поскольку стилизовать будет нечего. Можно с уверенностью сказать, что Менеджеры представляют собой (java)script-часть приложения — они несут всю бизнес-логику и управляют большинством пользовательских взаимодействий.","type":"unstyled","key":"a1lh5"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"А как насчет Работников, которые “не должны быть в курсе бизнес-логики”? Тут все обстоит как раз наоборот. Работники несут на себе все содержимое и стили (HTML- и CSS-части приложения). Они практически не используют JavaScript, прибегая к нему только для поддержки своего изолированного существования.","type":"unstyled","key":"6e5k6"},{"data":{"image":{"id":"659bc224865a591d8bc79ae7"}},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"","type":"atomic:image","key":"4scbj"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Должен заметить, что в отношении стилизации есть довольно существенная оговорка (слишком существенная, чтобы отвлекаться на нее).","type":"unstyled","key":"apfmf"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Тот факт, что Работники не могут делегировать задания Менеджерам, также не означает, что Менеджеры не могут быть дочерними элементами Работников в дереве компонентов. Мы поговорим об этом в последней главе.","type":"unstyled","key":"a6igk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Глава O: Open/Closed Principle (принцип открытости/закрытости)","type":"header-three","key":"fpkdv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":68,"offset":34,"style":"BOLD"}],"text":"Этот принцип определяется просто: компонент должен быть открыт для расширений и закрыт для модификаций. Однако понять разницу между расширением и модификацией не так просто. С точки зрения самого компонента любое расширение является модификацией. Поэтому можно сделать вывод, что этот принцип опирается исключительно на точку зрения внешнего потребителя компонента:","type":"unstyled","key":"2io5c"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":129,"offset":0,"style":"ITALIC"}],"text":"“Мне все равно, что вы будете делать с компонентом до тех пор, пока это не требует от меня изменения способа его использования!”.","type":"blockquote","key":"3v3qh"},{"data":{},"depth":0,"entityRanges":[{"key":1,"length":22,"offset":75}],"inlineStyleRanges":[],"text":"Возможно, это вам знакомо. Это потому, что данный принцип является основой обратной совместимости, и он встречается буквально повсюду. Веб-API и тренды в проектировании всегда будут развиваться, и вы должны постоянно быть готовыми к эволюции компонентов, а в процессе этой эволюции, в свою очередь, всегда нужно* принимать во внимание интересы существующих потребителей. Рассмотрим принцип открытости/закрытости на простом практическом примере.","type":"unstyled","key":"25jac"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Перед вами поставили задачу создать компонент Button, который при наличии соответствующего условия будет отображать иконку, и вы ее выполнили:","type":"unstyled","key":"f60fd"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"interface ButtonProps\n extends React.PropsWithChildren,\n React.HTMLAttributes {\n icon?: React.ReactNode;\n}\n\nexport const Button: React.FunctionComponent = ({\n children,\n icon,\n ...props\n}) => {\n return (\n \n );\n};","type":"blockquote","key":"f5nb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":35,"offset":52,"style":"ITALIC"}],"text":"Через некоторое время дизайнер по продукту говорит: “Нам нужна кнопка с иконкой справа”. Каковы будут ваши действия? Сделайте паузу и подумайте, как бы вы поступили.","type":"unstyled","key":"cqtco"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Добиться такого поведения можно несколькими способами, например введя новое свойство iconPlacement со значением по умолчанию left/start, которое будет управлять положением иконки. Если потребителей будет все устраивать, то я не буду возражать против этого, но лично я бы ввел два новых свойства и одно устаревшее:","type":"unstyled","key":"a8trg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"interface ButtonProps\n extends React.PropsWithChildren,\n React.HTMLAttributes {\n /**\n * @deprecated Используйте вместо этого`iconStart`\n */\n icon?: React.ReactNode;\n iconStart?: React.ReactNode;\n iconEnd?: React.ReactNode;\n}\n\nexport const Button: React.FunctionComponent = ({\n children,\n icon,\n iconStart = icon, // Возврат к `icon`, если не предоставлено\n iconEnd,\n ...props\n}) => {\n return (\n \n );\n};","type":"blockquote","key":"3qfqo"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Надеюсь, вы теперь лучше понимаете, что такое принцип открытости/закрытости и как его реализовать в React-приложении. Обратите внимание, что этот принцип не является идеальным решением (ремарка: идеала вообще не существует). Расширения неизбежно приводят к появлению больших файлов и в какой-то момент становятся контрпродуктивными. Иногда лучше пойти по пути расширения компонентов и создания их подтипов:","type":"unstyled","key":"67lt9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"import { Button, ButtonProps } from './Button';\n\ninterface IconButtonProps extends Omit {\n iconStart?: React.ReactNode;\n iconEnd?: React.ReactNode;\n}\n\nexport const IconButton: React.FunctionComponent = ({\n children,\n iconStart,\n iconEnd,\n ...props\n}) => {\n return (\n \n );\n};","type":"blockquote","key":"5ip5e"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Заметили потенциальную проблему в этом компоненте? Если нет, не волнуйтесь — мы поговорим об этом в следующей главе.","type":"unstyled","key":"8qmav"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Глава L: Liskov Substitution Principle (принцип подстановки Лисков)","type":"header-three","key":"d9qei"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":63,"offset":50,"style":"BOLD"}],"text":"Принцип подстановки Лисков основан на ковариации: вы должны быть в состоянии заменить любой супертип его подтипом. Для тех, кто не изучал информатику в школе, это название может показаться несколько странным. Если я расширяю тип A, создавая новый тип B, то нелогично называть тип B подтипом A, а A — супертипом B, но так оно и есть: помните, что деревья в информатике растут вниз.","type":"unstyled","key":"9j65n"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Так какую же ошибку я допустил в приведенном выше компоненте IconButton? IconButton расширяет компонент Button, другими словами, является подкомпонентом Button. Теперь у меня к вам два вопроса. Насчет первого вы, наверное, уже догадались, а вот второй будет посложнее.","type":"unstyled","key":"f5l4d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Можно ли заменить все вхождения компонента Button на его подтип IconButton?","type":"ordered-list-item","key":"8lk8v"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Целесообразно ли делать такую замену?","type":"ordered-list-item","key":"2m6hk"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Ответ на первый вопрос: нет. Опустив свойство icon компонента Button, я фактически нарушил принцип подстановки Лисков. Компонент IconButton — скорее “ребенок-сирота”, а не классический подтип Button. Оба типа являются независимыми и незамещаемыми или, используя модный технический жаргон, инвариантами относительно друг друга.","type":"unstyled","key":"2u0ql"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":23,"style":"BOLD"}],"text":"Ответ на второй вопрос тот же: нет. Почему? Потому что в мои планы никогда не входило создание подтипа, или, другими словами, IconButton не должен был заменять Button.","type":"unstyled","key":"4d0mi"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Это отличный пример композиции и наследования в программировании: принцип подстановки Лисков основан на наследовании, а React — на композиции (мы удостоверимся в этом позже). Тот факт, что React основан на композиции, не означает, что в нем нет места наследованию. Если вы посмотрите на компонент Button, приведенный выше, то заметите, что я намеренно сделал его подтипом HTMLButtonElement, включив две важные функции:","type":"unstyled","key":"jut4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":31,"offset":0,"style":"BOLD"}],"text":"extends React.PropsWithChildren принимает содержимое;","type":"unordered-list-item","key":"c8dht"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":47,"offset":0,"style":"BOLD"}],"text":"extends React.HTMLAttributes принимает атрибуты.","type":"unordered-list-item","key":"1q9s3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Поскольку компонент Button соблюдает принцип подстановки Лисков**, я могу просто взять и спокойно заменить им все вхождения HTML-элемента button в приложении, что и было задумано.","type":"unstyled","key":"c9gds"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Так почему же не заставить IconButton соблюдать принцип подстановки Лисков? Это, конечно, возможно, но очень скоро код превратится в кашу с запутанными компонентами и целым набором вещей, которые могут доставить немало хлопот.","type":"unstyled","key":"eklb0"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":97,"offset":187,"style":"ITALIC"}],"text":"Если вы находитесь на ранней стадии разработки приложений на React, я бы просто посоветовал игнорировать этот принцип. Если вы уверенный React-разработчик, то всегда начинайте с вопроса: предназначен ли этот компонент для замены базового компонента или элемента, который он расширяет? Если да, то убедитесь, что вы соблюдаете принцип подстановки Лисков, правильно передавая свойства, дочерние элементы, атрибуты и ref. Если нет, не делайте этого.","type":"unstyled","key":"ac5vh"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Глава I: Interface Segregation Principle (принцип разделения интерфейсов)","type":"header-three","key":"b9mgv"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":65,"offset":201,"style":"BOLD"}],"text":"Если бы мне пришлось выбирать один из принципов SOLID, которому можно слепо следовать, не задавая вопросов, то это, несомненно, был бы принцип разделения интерфейсов. Его суть заключается в следующем: компонент не должен зависеть от свойств, которые он не использует.","type":"unstyled","key":"1udks"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"На первый взгляд этот принцип может показаться до странности простым: зачем кому-то внедрять свойства, которые компонент не использует? Если мы используем правильную конфигурацию линтера, то даже не сможем нарочно сделать это. В чем же загвоздка?","type":"unstyled","key":"981qg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Загвоздка заключается в рекурсивном характере этого принципа. Рассмотрим следующий компонент:","type":"unstyled","key":"bdvt8"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"import Image, { type ImageProps } from 'next/image';\n\nimport { type User } from './types';\n\ninterface UserAvatarProps extends ImageProps {\n user: User;\n}\n\nexport const UserAvatar: React.FunctionComponent = ({\n user,\n ...props\n}) => {\n return {user.name}

;\n};","type":"blockquote","key":"5ppte"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":11,"offset":140,"style":"BOLD"}],"text":"Сначала кажется, что здесь нет неиспользуемых свойств. Мы используем user, и это единственное свойство, которое у нас есть. Однако тип User рекурсивно перетаскивает в компонент кучу неиспользуемых свойств, таких как email, id и т. д. Все это компоненту совершенно не нужно, и здесь нарушается принцип разделения интерфейсов. Тут полезно вспомнить наше обсуждение компонентов, названных Работниками (они не должны быть в курсе бизнес-логики). Более того, можно утверждать, что они вообще не должны знать ничего внешнего (но это не всегда возможно).","type":"unstyled","key":"5kd67"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Исправим ситуацию.","type":"unstyled","key":"c0brp"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"import Image, { type ImageProps } from 'next/image';\n\ninterface AvatarProps extends ImageProps {\n imageUrl: string;\n altText: string;\n}\n\nexport const Avatar: React.FunctionComponent = ({\n imageUrl,\n altText,\n ...props\n}) => {\n return {altText}

;\n};","type":"blockquote","key":"2jb6f"},{"data":{},"depth":0,"entityRanges":[{"key":2,"length":8,"offset":82}],"inlineStyleRanges":[],"text":"Проанализируем изменения. Самое главное, что мы сделали, — это удалили импорт в строке 3 в первом примере. Тем самым мы фактически отделили UserAvatar от интерфейса User, что, в свою очередь, значительно повысило возможность повторного использования нашего компонента. Более того, мы даже убрали из именования упоминание о “User” — теперь аватары могут быть и у домашних питомцев.","type":"unstyled","key":"c0efs"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Глава D: Dependency Inversion Principle (принцип инверсии зависимостей)","type":"header-three","key":"7v869"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"В заключительной главе расскажем о единственном и неповторимом крестном отце композиции в React, принципе всех принципов — принципе инверсии зависимостей. Официальная дефиниция этого принципа несколько сложна для понимания, особенно на первый взгляд. Кроме того, это единственный SOLID-принцип, который имеет двухчастное определение:","type":"unstyled","key":"bmp18"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":153,"offset":0,"style":"ITALIC"}],"text":"A. Модули высокого уровня не должны ничего импортировать из модулей низкого уровня. И те, и другие должны зависеть от абстракций (например, интерфейсов).","type":"blockquote","key":"f4iag"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":106,"offset":0,"style":"ITALIC"}],"text":"B. Абстракции не должны зависеть от деталей. Детали (конкретные реализации) должны зависеть от абстракций.","type":"blockquote","key":"27pak"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Если вам кажется, что звучит тяжеловесно, то вам не кажется — так оно и есть. Принцип инверсии зависимостей, как вы могли заметить, вполне заслуживает отдельной статьи. Если говорить о React, у меня есть для вас две новости — хорошая и плохая.","type":"unstyled","key":"ehom4"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":57,"offset":9,"style":"BOLD"}],"text":"Хорошая: вы используете принцип инверсии зависимостей по умолчанию, даже не замечая этого.","type":"unstyled","key":"dqr0a"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":34,"offset":53,"style":"BOLD"}],"text":"Плохая: вы используете принцип инверсии зависимостей по умолчанию, даже не замечая его.","type":"unstyled","key":"9ood9"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":3,"offset":259,"style":"BOLD"}],"text":"Итак, давайте разбираться с этим, безусловно, самым мощным принципом SOLID, лежащим в основе всего React. Начнем с названия: что такое зависимость? Это внешний код (модуль, пакет, функция, хук, компонент и т. д.), который я использую в компоненте. Есть ровно два способа появления этой зависимости “на моей территории”:","type":"unstyled","key":"8d5m3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":6,"offset":0,"style":"BOLD"}],"text":"импорт: я импортирую ее из соответствующего модуля;","type":"unordered-list-item","key":"eh6t3"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":9,"offset":0,"style":"BOLD"}],"text":"внедрение: она передается мне в качестве параметра (или свойства).","type":"unordered-list-item","key":"sm3i"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":18,"offset":15,"style":"BOLD"}],"text":"Импорт — это прямая зависимость, которую я практически не контролирую. Если эта зависимость изменит свое поведение, у меня будут проблемы.","type":"unstyled","key":"dbeos"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":20,"offset":18,"style":"BOLD"}],"text":"Внедрение — это обратная зависимость: хотя я и завишу от того, что мне передается, я контролирую то, что может быть передано, с помощью абстракции — интерфейса свойств.","type":"unstyled","key":"23m73"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Обратите внимание на то, как тесно переплетается принцип инверсии зависимостей с принципом единой ответственности и принципом разделения интерфейсов. Помните, в нашем примере UserAvatar мы говорили о том, что компонент не должен быть в курсе бизнес-логики (быть Работником), а также о том, что мы не должны передавать свойства/информацию, которая не нужна компоненту. Принцип инверсии зависимостей добавляет третью причину, почему этот компонент плох, — мы создаем прямую зависимость, или, другими словами, абстракция (AvatarProps) зависит от деталей (User).","type":"unstyled","key":"27t7d"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Второе и самое важное, что необходимо отметить, — это то, что инверсия зависимостей не ограничивается только передачей функций в компонентах. Буквально все примеры, посвященные этому принципу в React, касаются исключительно обработчиков событий, обходя вниманием самую главную задачу принципа инверсии зависимостей.","type":"unstyled","key":"8e4cb"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Еще раз перепишем компонент Button и посмотрим, сможете ли вы это заметить:","type":"unstyled","key":"8nnak"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"interface ButtonProps\n extends React.PropsWithChildren,\n React.HTMLAttributes {\n variant?: 'solid' | 'outlined' | 'blank';\n onClick: React.MouseEventHandler;\n}\n\nexport const Button: React.FunctionComponent = ({\n children,\n variant = 'blank',\n onClick,\n ...props\n}) => {\n const className = resolveClassName(variant);\n return (\n \n );\n};","type":"blockquote","key":"a1c4j"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Итак, onClick — самый очевидный пример: он не может быть встроенным, иначе нарушится принцип единой ответственности, и его нельзя импортировать напрямую, так как нарушится принцип инверсии зависимостей. Видите ли вы здесь другие примеры внедрения зависимостей? А как насчет children? Передаются ли они в качестве свойств? Да. Я контролирую их тип? Да. И вот кульминация этой главы:","type":"unstyled","key":"2mqkc"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[{"length":124,"offset":0,"style":"ITALIC"}],"text":"Всякий раз, когда вы говорите о паттерне композиции в React, вы говорите о принципе инверсии зависимостей. Это одно и то же.","type":"blockquote","key":"9otbg"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"Именно такое положение вещей позволяет Работникам из первой главы находиться выше в дереве компонентов по сравнению с Менеджерами — их зависимость инвертируется, и они фактически становятся контейнерами***, не зная, что именно они содержат, и, следовательно, не нарушая принцип единой ответственности.","type":"unstyled","key":"83pcs"},{"data":{},"depth":0,"entityRanges":[{"key":3,"length":20,"offset":151}],"inlineStyleRanges":[{"length":3,"offset":58,"style":"ITALIC"}],"text":"Теперь вернемся к моему обещанию из главы L показать, что все в React является композицией. То, как мы передаем children в React, — не что иное, как синтаксический сахар. Посмотрите внимательно на эти компоненты и на то, как они используются:","type":"unstyled","key":"6ehja"},{"data":{},"depth":0,"entityRanges":[],"inlineStyleRanges":[],"text":"interface AProps extends React.PropsWithChildren {}\n\ninterface BProps {\n childNodes?: React.ReactNode | undefined;\n}\n\nexport const A = ({ children }: AProps) => {\n return

{children}

;\n};\n\nexport const B = ({ childNodes }: BProps) => {\n return

{childNodes}