Ну да, не уточнил. Под «другое» я имел в виду, что это не способ как-то особенно писать код, это не какая-то библиотека сама по себе, просто паттерн. Действительно, близко к тому, о чем говорится по ссылке выше (A New Approach for Managing Redux Actions). Пропустил этот момент, думал сравнивается с либой из топика.
Лучше всего управлять потомками при помощи специальных методов — React.Children. Например пример ниже позволяет вернуть только потомков и не требует дополнительной обертки
return React.Children.only(this.props.children)
Это лишь способ указать, что children железно должен быть одним элементом в любом случае. Иначе React бросит исключение. Это никак не возможность вернуть несколько дочерних элементов напрямую, без оборачивающего элемента. Пример выше лишь проверит, что потомок один и вернет его.
Ну а кто с этим спорит — я про то, что и более поверхностного взгляда на статью достаточно, чтобы понять, что это стеб (для тех, кто использует эти инструменты, конечно же, хотя тема с твитом ну очень уж очевидная в любом случае).
Само собой :) Даже в команде Ember сидят не настолько прагматики, чтобы тащить Британнику ради одного определения. Но с чувством юмора у автора все круто — такое еще надо было придумать :D
На самом деле, забавно и круто (читал эту статью в оригинале). Кстати, автору тоннами сыплются комментарии по поводу того, что хоть где-то стоило упомянуть, что это стеб (ну, кроме Гая Фиери частично) — впрочем, может тогда не было бы так весело :)
JSX-лапша (с которой гневно плевался, когда первый раз увидел) — это как наркотик :) Начинаешь любить эту лапшу один в один в такой вот ситуации — просто понимаешь, что в том или ином виде она есть везде, а тут это оказывается на удивление удобно и без лишних сюрпризов, она просто работает и все.
TypeScript — поскольку это надмножество JavaScript — по сути, писать на React с TypeScript можно уже давно. Сам предпочитаю Babel (ES6/7) + FlowType (иногда типизация — требование команды заказчика), но сути дела особо не меняет. Честно, в большинстве случаев на практике не ощущаю необходимости в типизации вообще, я не использую IDE с IntelliSense и иже с ними. Но одно можно сказать точно — надо осваивать, это будет востребованная/продаваемая тема, в том числе благодаря мощно продвигаемому Angular 2.
У меня ровно противоположный опыт :) Angular был крайне популярен на западе, сейчас очень много проектов по переводу AngularJS 1 приложений на React (иногда еще серверный пререндеринг из коробки играет не последнюю роль). Впрочем, Angular 2 тоже фигурирует, но пока очень мало.
То, что основной/предпочтительный обычно один — соглашусь. Однако, от себя добавлю, что чтобы быть крутым фронтендером — освоить нужно бы оба. Изучение React поменяло то, как я пишу на Angular в свое время.
А какой профит принес сознательный отказ от React.js? (реально интересны причины, ибо сам работаю и с тем, и как раз профит был в скором освоении React-а).
Есть еще отличный https://github.com/tajo/react-portal, если нужен только «портал».
Впрочем, оба используют ReactDOM.unstable_renderComponentIntoSubtree, в целом похожи, а с react-overlays идут еще несколько ништяков в виде более высокоуровневых компонентов.
Да Redux — это вообще не модель, ни тонкая, ни какая-то еще (в терминах привычных реализаций MVC).
Да не, модным никто и не пытается казаться, и кто-то говорил что-то про «поганый мир ООП» (я так не считаю)? Я только о том, что не нужно все под одну гребенку MVC, потому что так вроде бы проще. Элементов больше, стыки между M, V и C без натяжки не сделать, да и незачем.
Дело в том, что React-компонент может выполнять все роли из MVC
Вот поэтому тут не стоит даже упоминать MVC, чтобы избежать любой путаницы.
Если лезть в детали — Store не меняет свое состояние сам, и не содержит сам по себе никаких методов работы с этими данными. Более того, там могут храниться как данные приложения (domain data), так и различные аспекты состояния UI. Redux — это «state container», а не модель. И не пытается быть последней. Редьюсеры меняют любое состояние, и отнюдь не обязательно связанное с бизнес-логикой приложения. С очень большой натяжкой можно назвать всю эту часть «моделью», и то только для тех, кто вот без MVC вообще не может понять что за что отвечает. Но, как по мне, это изначально неверный способ думать об архитектуре Redux-приложений.
Не согласен с утверждением. MVC все же определяет конкретные блоки. Кроме того, в статье «лейблы» M, V и C вешаются на вполне конкретные вещи, так что стоит рассматривать паттерн именно в контексте конкретной реализации (а их у MVC может быть полно).
Это лишь способ указать, что children железно должен быть одним элементом в любом случае. Иначе React бросит исключение. Это никак не возможность вернуть несколько дочерних элементов напрямую, без оборачивающего элемента. Пример выше лишь проверит, что потомок один и вернет его.
TypeScript — поскольку это надмножество JavaScript — по сути, писать на React с TypeScript можно уже давно. Сам предпочитаю Babel (ES6/7) + FlowType (иногда типизация — требование команды заказчика), но сути дела особо не меняет. Честно, в большинстве случаев на практике не ощущаю необходимости в типизации вообще, я не использую IDE с IntelliSense и иже с ними. Но одно можно сказать точно — надо осваивать, это будет востребованная/продаваемая тема, в том числе благодаря мощно продвигаемому Angular 2.
То, что основной/предпочтительный обычно один — соглашусь. Однако, от себя добавлю, что чтобы быть крутым фронтендером — освоить нужно бы оба. Изучение React поменяло то, как я пишу на Angular в свое время.
Впрочем, оба используют ReactDOM.unstable_renderComponentIntoSubtree, в целом похожи, а с react-overlays идут еще несколько ништяков в виде более высокоуровневых компонентов.
Да не, модным никто и не пытается казаться, и кто-то говорил что-то про «поганый мир ООП» (я так не считаю)? Я только о том, что не нужно все под одну гребенку MVC, потому что так вроде бы проще. Элементов больше, стыки между M, V и C без натяжки не сделать, да и незачем.
Если лезть в детали — Store не меняет свое состояние сам, и не содержит сам по себе никаких методов работы с этими данными. Более того, там могут храниться как данные приложения (domain data), так и различные аспекты состояния UI. Redux — это «state container», а не модель. И не пытается быть последней. Редьюсеры меняют любое состояние, и отнюдь не обязательно связанное с бизнес-логикой приложения. С очень большой натяжкой можно назвать всю эту часть «моделью», и то только для тех, кто вот без MVC вообще не может понять что за что отвечает. Но, как по мне, это изначально неверный способ думать об архитектуре Redux-приложений.