Рассматривая создание типа родительского компонента «менеджер», который может принимать произвольное количество дочерних элементов, которое может отображаться как null (не более дюжины или около того макс., Возможно, меньше, поэтому масштабирование не требуется), определите который будет рендериться и является наиболее важным для рендеринга, а затем просто рендерит тот. Так, например, если компонент был объявлен следующим образом:
<ChildManager>
<ChildA priority={1} [...someOtherProps]/>
<ChildB priority={3} [...someOtherProps]/>
<ChildC priority={2} [...someOtherProps]/>
</ChildManager>
, где ChildB будет отображаться как ноль из-за некоторой логики внутреннего компонента, он будет просто отображать ChildC, поскольку он имеет самое высокое значение приоритета.
Я получил базовую версию этой работы, хотя решение, которое у меня есть, выглядит довольно анти-шаблонным / хакерским. По сути, у меня каждый дочерний элемент изначально отображается как null, но я вызываю общую опору iWillRender callback с тем, что он будет отображать и каков этот приоритет. Затем менеджер собирает эти обратные вызовы и использует их, чтобы определить, какой дочерний элемент должен отображаться.
Единственный другой подход, который я могу придумать, состоит в том, чтобы ChildManager содержал все условную логику рендеринга и связанные данные для каждого возможного потомка, который кажется намного более беспорядочным и менее расширяемым, если будущие дети должны быть добавленным Мне бы хотелось более чистое решение, в котором можно скопировать некоторый дочерний шаблон, чтобы быстро создать новый дочерний компонент, который снова связывается с менеджером. Возможно, компонент более высокого порядка, который оборачивает каждого дочернего элемента и обрабатывает там логику, хотя я не знаю, как это могло бы быть связано с менеджером более высокого уровня, который определяет, какой из них затем следует визуализировать?