Angular
Comments 27
0
Вот блин, а я мучился с именованными router-outlets

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>
0
Хороший пример того, что Angular2 переусложнен*, вот аналог на alight.

отражение содержимого декларации компонента в его DOM c помощью специального тега… list-navigator-item-outlet, list-navigator-item-сontext, list-navigator-item...
Я просто взял содержимое элемента (itemTpl = element.innerHTML) и вывел в его списке.
+2

Ангуляр 2 это действительно непростой инструмент, но для сложных задач должен быть выбран советующий инструмент. Тут можно привести аналогию – лопата и экскаватор. Лопату освоить просто, экскаватор сложнее. Но сколько можно выкопать лопатой, а сколько экскаватором за один и тот же отрезок времени? Другое дело, что если нужна одна небольшая ямка в труднодоступном месте и при ограниченном бюджете, то экскаватор вообще не вариант. Я использую второй ангуляр в достаточно крупном проекте (те самые тысячи страниц =) ) уже в течении года + до этого пол года на “Proof of concept” (начинали еще с альфы), и могу сказать, что этот фреймворк просто великолепен как комплексное решение, но я вполне понимаю недоумение людей впервые смотрящих на “Hello World” – тут действительно ангуляр 2 кажется переусложненным.


По поводу вашего примера на alight хочу выразить вам благодарность – действительно интересно как одни и те же задачи решаются с использованием разных инструментов. К сожалению, я не знаком с alight поэтому не могу оценить простоту, но по поводу использования innerHTML у меня есть подозрение, что будет сложно добавить интерактив к шаблону будет непросто (могу ошибаться).


Вот вариант на Ангуляр 2 с кнопкой “Archive” клик на которую обрабатывается родительской страницей. Потребовался лишь минимум изменений.

+2
Не соглашусь с аналогией. Вообще путь Ангуляра 2 непонятен, вот 1-я версия родилась из реального использования и конкретных потребностей. А в ангуляр 2 понапихали все что только можно, все хиптерские кейворды, да они пофиксили косяки первой версии, но и привнесли других, новых проблем, при этом они сами его не используют, это больше похоже на исследовательский (академический) проект.
не могу оценить простоту
Можно сравнить хотя бы объем, 8 строк нативного js — само приложение и 20 строк на компонент.
Потребовался лишь минимум изменений.
Аналогично
0
Вообще путь Ангуляра 2 непонятен

Путь очень прост, angular это самодостаточный фреймворк с набором тулов. Все.
Вам не нужно думать какой использовать роутер, как работать с бекэндом, как работать с формами и, наконец, как собрать приложение. Все идет из коробки.
Просто берете его и пишите код для Бизнеса.

в ангуляр 2 понапихали все что только можно

Тоже спорно. По моему мнению понапихали то что нужно. Плюс в том что вы можете не использовать некоторые части если они вам не нужны (например можно не использовать роутер или формы). Второй момент — почти каждый элемент можно тюнить.
Единственное чего не хватает это интегрированного moment.js (но это всетаки проблема не angular, а JS).

Я все это к тому, что angular это не мелкая штука, действительно нужно потратить какое-то время чтобы в нем разбраться (плюс еще нужно освоить Typescript + RxJS).
0
Я использую второй ангуляр в достаточно крупном проекте (те самые тысячи страниц =) ) уже в течении года + до этого пол года на “Proof of concept” (начинали еще с альфы), и могу сказать, что этот фреймворк просто великолепен как комплексное решение
А можете привести пример места, где он значительно помог как движок? И какая его часть/части. На всякий случай уточню — помог именно как комплексное решение, которое недостижимо при использовании отдельных аналогов его компонент.
0
На всякий случай уточню — помог именно как комплексное решение, которое недостижимо при использовании отдельных аналогов его компонент.

Не совсем корретный вопрос, если вы говорите, что angular — это комплексное решение, то решение, собранное из нескольких компонент тоже является комплекным. Просто поставщик этого ренения не Google, а вы.

И конечно же вы можете ваше приложение вообще не используя фреймфорки и библиотеки. Я утрирую конечно, но думаю идея понятна.

У нас в команде путь с angular был примерно такой (все .net разработчики):
1. Прикольно.
2. Чет сложно.
3. Зря выбрали angular.
4.…
5. Ох он мощьный.
6. Когдаже они добавят поддежку TS 2.1, хочется acync/await.
+1
если вы говорите, что angular — это комплексное решение
Ну да, кривовато получилось, надо было в кавычки взять. На самом деле это просто цитата:
фреймворк просто великолепен как комплексное решение

Ну и вопрос был не про кривую изучения, излишнюю переусложненность и прочее. Вопрос был про реальные кейсы (кстати, вы тоже можете рассказать), когда ng2 (независимо от того, кто за ним стоит и кто поддерживает) сильно помог. Пока-что все доводы, что я слышал, это «ну, это большой движок, все в одном флаконе, поддерживает гугл, лень собирать из библиотек». Чем же он так хорош? Расскажите, мне действительно интересно.

UPD: Мне, как человеку, использующему большую часть времени реакт (не кидайтесь камнями, я мирно тут :) ), достаточно дико видеть такое месиво ради расширения шаблона переиспользуемого компонента. Но, все-равно, интересно, что я выиграю с ng2.
0
Есил вы эксперт React'a, а еще лучше если у вас вся команда свободно работает с React и у вас есть набор бибилотек которые вы используете совместно с React (те у вас есть свое «комплексное решение»), то ничем вам angular не поможет. Условно конечно, но это как спрашивать: «Я эксперт по JavaEE, чем мне поможет ASP.NET/RoR».

Попробую перечислить некоторые моменты которые для меня были решающими при выборе angular vs React:
1. Typescript
2. Разделение разметки(templates) и кода компонента
3. DI
Но кого волнует что мне нравиться, а что нет?
ну, это большой движок, все в одном флаконе

Вот это на самом деле и есть ключевой момент. А с ростом популярности angular он станет еще важнее.
Т.е. стандартизация. Если посмотреть на C#, Java, Ruby, то у каждого языка есть 1) стандартная библиотека, 2) один-два фреймворка для разработки веб-приложений. Опустим остальное, мы же про веб говорим. Другими словами проще нанять человека в команду.
0
Ну понятно, что-то подобное мне и представлялось.
Да, у нас весь стэк вокруг реакта, но есть проект на первом ангуляре, вот думаем, что с ним делать, переводить на привычный стэк (т.е. с нуля), либо ng2. Но, что-то мне подсказывает, что второе — это то же самое с нуля. Только попутно собирая все неизвестные подводные камни.

Пару слов по поводу решающих моментов:
1. У нас тоже TS/TSX
2. Ну, думается мне, это больше философия, и ангуляр, как и многие другие движки, разделяющие шаблоны и логику, тут не причем.
3. DI и отдельных реализаций много

По поводу «стандартизации» все так. Но это плюс всех монолитов. Другое дело, что в экосистеме реакта присутствуют достаточно устоявшийся выбор, роутинг, компоненты, темизация, формы… Так что, я бы не стал углубляться в поиск преимуществ монолита на хорошей поддержке. А людей, как показывает практика, можно найти в обоих лагерях.

Однако, вопрос, все же, все-равно не о том. Я постоянно слышу, что ng2 — это сложное решение для сложных проблем. И хотелось бы услышать про эти сложные случаи, когда именно внутренняя инфраструктура ng2, какие-то его компоненты, архитектура, помогли решить эти сложные проблемы. Чтобы, раз — попытаться построить аналогию на своем стэке (а пока-что за неимением представления об этих случаях она строится на ура), два — попытаться, взвесив все за и против, иметь представление, что к чему.
0
Да, у нас весь стэк вокруг реакта, но есть проект на первом ангуляре, вот думаем, что с ним делать, переводить на привычный стэк (т.е. с нуля), либо ng2.

Хм, так ведь неважно на что вы будете переводить, вам все равно придется все с нуля писать. Я слабо верю что там можно A1 в A2 мигрировать без тотального переписывания и кучи грабель.

Другое дело, что в экосистеме реакта присутствуют достаточно устоявшийся выбор, роутинг, компоненты, темизация, формы…

Ну тогда по сути и разницы нет.

Я постоянно слышу, что ng2 — это сложное решение для сложных проблем.

Я не думаю, что React проще Angular. Вы же все равно осваивали «экосистему React». Да и решают они одни и те же задачи.
Да и вообще, я вижу React/Angular как JavaEE/ASP.NET или BMV/Mersedes.
0
Хм, так ведь неважно на что вы будете переводить, вам все равно придется все с нуля писать. Я слабо верю что там можно A1 в A2 мигрировать без тотального переписывания и кучи грабель.
Ну, иделология и архитектура (по большей части) сохраняются.

Я не думаю, что React проще Angular. Вы же все равно осваивали «экосистему React». Да и решают они одни и те же задачи.
Я к этому и клоню. Просто, видя во что превращается кастомизация внутреннего шаблона компонента, невольно задаешься вопросом: «зачем-то же это все тут накручено?».
0
зачем-то же это все тут накручено?

Собственно эта статья и объясняет это, хотябы частично. Вы же со своей экспертизой можете прикинуть как эту задачу решить используя React.
+1
Собственно эта статья и объясняет это, хотябы частично
Не совсем с вами согласен. Статья показывает, как накрутить. А зачем все это было придумано разработчиками движка не объясняет (да и не должна).

как эту задачу решить используя 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 достаточно самостоятельный компонент, то ему самое место в отдельной функции или классе, если он со стейтом. Если он завязан на какой-то контекст, можно его сделать методом. Опять же, если внутри сложного компонента происходят какие-то вычисления перед рендерингом, можно вместо айтема передать функцию фабрику.

Большая часть интерфейса строится на обычных функциях. Там где нужен стейт используются обычные классы.
0

В ангуляре мы тоже, по сути, передаём «функцию» в компонент:


<template> компилируется в TemplateRef у которого есть метод createEmbeddedView(context: C)


Хотя соглашусь, в React это выглядит изящнее


0

Все ждал когда про Реакт вспомнят =)


Реальные кейсы где Angular 2 выигрывает это скорее экономические и политические, нежели чисто технические.


Например, поиск новых разработчиков: если человек знает Angular 2, то можно сразу в бой, поскольку все проекты на Ангуляре 2 похожи, но если он знает React, то далеко не факт, что он сможет сходу начать работу (на проекте с React разумеется).


Кроме того, надежда на то, что создатели Ангуляра не бросят разработку (поддержку) в среднем выше чем для многих других решений. Первый ангуляр до сих пор обновляют.


0
но если он знает React, то далеко не факт, что он сможет сходу начать работу (на проекте с React разумеется).
У вас есть пример? Пока-что никаких проблем не было. А вот с первым ангуляром были. Но только из-за того, что в этом проекте лютейшее легаси из говна и палок в силу излишней гибкости движка.
Кроме того, надежда на то, что создатели Ангуляра не бросят разработку (поддержку) в среднем выше чем для многих других решений. Первый ангуляр до сих пор обновляют.
У гугла очень специфичное отношение к поддержке собственных продуктов и решений. Уверенности, что ng им в один момент не надоест вообще никакой. Другое дело, что его 100% не бросит сообщество. Та же история и с фейсбуком, вообще не понятно, что там будет дальше. Но всегда есть сообщество.

UPD
Все ждал когда про Реакт вспомнят =)
И хотелось бы, чтобы это не выходило за рамки мирного обсуждения :)
0
Смотрю я на все это безобразие, на жуткий dsl, на ворох всяких символов, маркеров, скобок, на груду разных сущностей, компонентов, директив, какие-то еще безумных декораторов, на кучу разных классов, селекторов, каких-то рефов, контекстов… Слезы наворачиваются, ей богу.
0
Это какая-то бага Plunker — перестал работать в «embed» режиме. Поменял все ссылки на «edit» режим. Спасибо, что сообщили.
0
Глядя на это вспомнилась технология xml/xsl, котрая работала 15 лет назад в ИЕ.
Там все тоже самое — можно сделать шаблоны для собственного тега с обработкой вложенных в свой тег дочерних элементов.
Годная вещь была, немного сложноватая на старте.
Однако, проблема таже самая, что и до сих пор — js код никак не привязан к элементам браузера и приходилось придумывать лисапеды по навешиванию событий на сгенерированный html, чтобы в итоге работать с тегом как с объектом.

Когда нибудь web components сделают переворот в разработке. Когда-нибудь. А пока 15 лет потрачены на непонятно кому нужные новые стандарты и языковую вкусовщину, которая почему перекомпилируется в древний js.
0
Сам 10 лет назад делал веб приложения на XSLT – вполне работоспособный вариант (сайт до сих пор работает :) ). Там правда была задача уменьшить размер загружаемых на клиента данных, поскольку интернет в те времена не был так быстр.
0

Я попробую угадать, автор наверное серверный разработчик или энтерпрайз джава девелопер :)

Only those users with full accounts are able to leave comments., please.