Comments 27
Вот блин, а я мучился с именованными router-outlets
router
layout
router
children: [
{ path: '', component: headerComponent, outlet: 'header' },
{ path: '', component: contentComponent },
{ path: '', component: headerComponent, outlet: 'footer' },
]
layout
<section>
<router-outlet name="header"></router-outlet>
<router-outlet></router-outlet>
<router-outlet name="footer"></router-outlet>
</section>
Хороший пример того, что Angular2 переусложнен*, вот аналог на alight.
отражение содержимого декларации компонента в его DOM c помощью специального тега… list-navigator-item-outlet, list-navigator-item-сontext, list-navigator-item...Я просто взял содержимое элемента
(itemTpl = element.innerHTML) и вывел в его списке.
Ангуляр 2 это действительно непростой инструмент, но для сложных задач должен быть выбран советующий инструмент. Тут можно привести аналогию – лопата и экскаватор. Лопату освоить просто, экскаватор сложнее. Но сколько можно выкопать лопатой, а сколько экскаватором за один и тот же отрезок времени? Другое дело, что если нужна одна небольшая ямка в труднодоступном месте и при ограниченном бюджете, то экскаватор вообще не вариант. Я использую второй ангуляр в достаточно крупном проекте (те самые тысячи страниц =) ) уже в течении года + до этого пол года на “Proof of concept” (начинали еще с альфы), и могу сказать, что этот фреймворк просто великолепен как комплексное решение, но я вполне понимаю недоумение людей впервые смотрящих на “Hello World” – тут действительно ангуляр 2 кажется переусложненным.
По поводу вашего примера на alight хочу выразить вам благодарность – действительно интересно как одни и те же задачи решаются с использованием разных инструментов. К сожалению, я не знаком с alight поэтому не могу оценить простоту, но по поводу использования innerHTML у меня есть подозрение, что будет сложно добавить интерактив к шаблону будет непросто (могу ошибаться).
Вот вариант на Ангуляр 2 с кнопкой “Archive” клик на которую обрабатывается родительской страницей. Потребовался лишь минимум изменений.
Не соглашусь с аналогией. Вообще путь Ангуляра 2 непонятен, вот 1-я версия родилась из реального использования и конкретных потребностей. А в ангуляр 2 понапихали все что только можно, все хиптерские кейворды, да они пофиксили косяки первой версии, но и привнесли других, новых проблем, при этом они сами его не используют, это больше похоже на исследовательский (академический) проект.
не могу оценить простотуМожно сравнить хотя бы объем, 8 строк нативного js — само приложение и 20 строк на компонент.
Потребовался лишь минимум изменений.Аналогично
Я использую второй ангуляр в достаточно крупном проекте (те самые тысячи страниц =) ) уже в течении года + до этого пол года на “Proof of concept” (начинали еще с альфы), и могу сказать, что этот фреймворк просто великолепен как комплексное решениеА можете привести пример места, где он значительно помог как движок? И какая его часть/части. На всякий случай уточню — помог именно как комплексное решение, которое недостижимо при использовании отдельных аналогов его компонент.
Бык это ж классика:
Заголовок спойлера
если вы говорите, что angular — это комплексное решениеНу да, кривовато получилось, надо было в кавычки взять. На самом деле это просто цитата:
фреймворк просто великолепен как комплексное решение
Ну и вопрос был не про кривую изучения, излишнюю переусложненность и прочее. Вопрос был про реальные кейсы (кстати, вы тоже можете рассказать), когда ng2 (независимо от того, кто за ним стоит и кто поддерживает) сильно помог. Пока-что все доводы, что я слышал, это «ну, это большой движок, все в одном флаконе, поддерживает гугл, лень собирать из библиотек». Чем же он так хорош? Расскажите, мне действительно интересно.
UPD: Мне, как человеку, использующему большую часть времени реакт (не кидайтесь камнями, я мирно тут :) ), достаточно дико видеть такое месиво ради расширения шаблона переиспользуемого компонента. Но, все-равно, интересно, что я выиграю с ng2.
Ну понятно, что-то подобное мне и представлялось.
Да, у нас весь стэк вокруг реакта, но есть проект на первом ангуляре, вот думаем, что с ним делать, переводить на привычный стэк (т.е. с нуля), либо ng2. Но, что-то мне подсказывает, что второе — это то же самое с нуля. Только попутно собирая все неизвестные подводные камни.
Пару слов по поводу решающих моментов:
1. У нас тоже TS/TSX
2. Ну, думается мне, это больше философия, и ангуляр, как и многие другие движки, разделяющие шаблоны и логику, тут не причем.
3. DI и отдельных реализаций много
По поводу «стандартизации» все так. Но это плюс всех монолитов. Другое дело, что в экосистеме реакта присутствуют достаточно устоявшийся выбор, роутинг, компоненты, темизация, формы… Так что, я бы не стал углубляться в поиск преимуществ монолита на хорошей поддержке. А людей, как показывает практика, можно найти в обоих лагерях.
Однако, вопрос, все же, все-равно не о том. Я постоянно слышу, что ng2 — это сложное решение для сложных проблем. И хотелось бы услышать про эти сложные случаи, когда именно внутренняя инфраструктура ng2, какие-то его компоненты, архитектура, помогли решить эти сложные проблемы. Чтобы, раз — попытаться построить аналогию на своем стэке (а пока-что за неимением представления об этих случаях она строится на ура), два — попытаться, взвесив все за и против, иметь представление, что к чему.
Да, у нас весь стэк вокруг реакта, но есть проект на первом ангуляре, вот думаем, что с ним делать, переводить на привычный стэк (т.е. с нуля), либо ng2. Но, что-то мне подсказывает, что второе — это то же самое с нуля. Только попутно собирая все неизвестные подводные камни.
Пару слов по поводу решающих моментов:
1. У нас тоже TS/TSX
2. Ну, думается мне, это больше философия, и ангуляр, как и многие другие движки, разделяющие шаблоны и логику, тут не причем.
3. DI и отдельных реализаций много
По поводу «стандартизации» все так. Но это плюс всех монолитов. Другое дело, что в экосистеме реакта присутствуют достаточно устоявшийся выбор, роутинг, компоненты, темизация, формы… Так что, я бы не стал углубляться в поиск преимуществ монолита на хорошей поддержке. А людей, как показывает практика, можно найти в обоих лагерях.
Однако, вопрос, все же, все-равно не о том. Я постоянно слышу, что ng2 — это сложное решение для сложных проблем. И хотелось бы услышать про эти сложные случаи, когда именно внутренняя инфраструктура ng2, какие-то его компоненты, архитектура, помогли решить эти сложные проблемы. Чтобы, раз — попытаться построить аналогию на своем стэке (а пока-что за неимением представления об этих случаях она строится на ура), два — попытаться, взвесив все за и против, иметь представление, что к чему.
Хм, так ведь неважно на что вы будете переводить, вам все равно придется все с нуля писать. Я слабо верю что там можно A1 в A2 мигрировать без тотального переписывания и кучи грабель.Ну, иделология и архитектура (по большей части) сохраняются.
Я не думаю, что React проще Angular. Вы же все равно осваивали «экосистему React». Да и решают они одни и те же задачи.Я к этому и клоню. Просто, видя во что превращается кастомизация внутреннего шаблона компонента, невольно задаешься вопросом: «зачем-то же это все тут накручено?».
Собственно эта статья и объясняет это, хотябы частичноНе совсем с вами согласен. Статья показывает, как накрутить. А зачем все это было придумано разработчиками движка не объясняет (да и не должна).
как эту задачу решить используя React.Мы уже ее решили. позволю себе не повторять изначальный пример точь в точь, а только отразить суть.
Кастомизацию мы делаем примерно вот так несколькими способами:
class Widget extends React.Component {
state = {}
render() {
const {settingsMode} = this.state;
const {settings, children} = this.props;
return (
<div className="widget">
<div className="widget--header">
<button onClick={this.onButtonClick}>
{settingsMode ? 'OK' : 'Settings'}
</button>
</div>
<div className="widget--body">
{settingsMode && (
<div>
Settings: {settings}
</div>
)}
{!settingsMode && children}
</div>
</div>
);
}
onButtonClick = () => {
this.setState({
settingsMode: !this.state.settingsMode
});
}
}
class ListNavigator extends React.Component {
state = {}
render() {
const {items, Item} = this.props;
return (
<div className="navigator">
{items.map((item, i) => <Item key={i} {...item}/>)}
</div>
);
}
}
//can be a class with its own state and access to context
const SeparateItem = ({id, name}) => (
<div>
Separate: {id}: {name}
</div>
);
const items = [
{
id: 123,
name: 'Foo',
},
{
id: 234,
name: 'Bar'
}
];
class App extends React.Component {
render() {
const settings = (
<div>settings</div>
);
return (
<div>
<Widget settings={settings}>
<div>
Large widget body
</div>
</Widget>
As separate component
<ListNavigator items={items} Item={SeparateItem}/>
As a method
<ListNavigator items={items} Item={this.renderItem}/>
</div>
);
}
renderItem = item => {
return (
<div>
<span>{item.id}</span>
<span>{item.name}</span>
</div>
);
}
}
Вся соль в том, что для кастомизации достаточно передать элемент в компонент (в случае с виджетом) или новую функцию/класс (в случае со списком).
Мне такое решение кажется максимально простым и максимально гибким, так как, если Item достаточно самостоятельный компонент, то ему самое место в отдельной функции или классе, если он со стейтом. Если он завязан на какой-то контекст, можно его сделать методом. Опять же, если внутри сложного компонента происходят какие-то вычисления перед рендерингом, можно вместо айтема передать функцию фабрику.
Большая часть интерфейса строится на обычных функциях. Там где нужен стейт используются обычные классы.
В ангуляре мы тоже, по сути, передаём «функцию» в компонент:
<template> компилируется в TemplateRef у которого есть метод createEmbeddedView(context: C)
Хотя соглашусь, в React это выглядит изящнее
Все ждал когда про Реакт вспомнят =)
Реальные кейсы где Angular 2 выигрывает это скорее экономические и политические, нежели чисто технические.
Например, поиск новых разработчиков: если человек знает Angular 2, то можно сразу в бой, поскольку все проекты на Ангуляре 2 похожи, но если он знает React, то далеко не факт, что он сможет сходу начать работу (на проекте с React разумеется).
Кроме того, надежда на то, что создатели Ангуляра не бросят разработку (поддержку) в среднем выше чем для многих других решений. Первый ангуляр до сих пор обновляют.
но если он знает React, то далеко не факт, что он сможет сходу начать работу (на проекте с React разумеется).У вас есть пример? Пока-что никаких проблем не было. А вот с первым ангуляром были. Но только из-за того, что в этом проекте лютейшее легаси из говна и палок в силу излишней гибкости движка.
Кроме того, надежда на то, что создатели Ангуляра не бросят разработку (поддержку) в среднем выше чем для многих других решений. Первый ангуляр до сих пор обновляют.У гугла очень специфичное отношение к поддержке собственных продуктов и решений. Уверенности, что ng им в один момент не надоест вообще никакой. Другое дело, что его 100% не бросит сообщество. Та же история и с фейсбуком, вообще не понятно, что там будет дальше. Но всегда есть сообщество.
UPD
Все ждал когда про Реакт вспомнят =)И хотелось бы, чтобы это не выходило за рамки мирного обсуждения :)
Смотрю я на все это безобразие, на жуткий dsl, на ворох всяких символов, маркеров, скобок, на груду разных сущностей, компонентов, директив, какие-то еще безумных декораторов, на кучу разных классов, селекторов, каких-то рефов, контекстов… Слезы наворачиваются, ей богу.
0x1000000 исходники затёрлись… Восстановите?
Глядя на это вспомнилась технология xml/xsl, котрая работала 15 лет назад в ИЕ.
Там все тоже самое — можно сделать шаблоны для собственного тега с обработкой вложенных в свой тег дочерних элементов.
Годная вещь была, немного сложноватая на старте.
Однако, проблема таже самая, что и до сих пор — js код никак не привязан к элементам браузера и приходилось придумывать лисапеды по навешиванию событий на сгенерированный html, чтобы в итоге работать с тегом как с объектом.
Когда нибудь web components сделают переворот в разработке. Когда-нибудь. А пока 15 лет потрачены на непонятно кому нужные новые стандарты и языковую вкусовщину, которая почему перекомпилируется в древний js.
Там все тоже самое — можно сделать шаблоны для собственного тега с обработкой вложенных в свой тег дочерних элементов.
Годная вещь была, немного сложноватая на старте.
Однако, проблема таже самая, что и до сих пор — js код никак не привязан к элементам браузера и приходилось придумывать лисапеды по навешиванию событий на сгенерированный html, чтобы в итоге работать с тегом как с объектом.
Когда нибудь web components сделают переворот в разработке. Когда-нибудь. А пока 15 лет потрачены на непонятно кому нужные новые стандарты и языковую вкусовщину, которая почему перекомпилируется в древний js.
Я попробую угадать, автор наверное серверный разработчик или энтерпрайз джава девелопер :)
Sign up to leave a comment.
Создаем шаблонизируемые переиспользуемые компоненты в Angular 2