Осталось только осознать, что DevOps это про культуру взаимодействия Dev, Ops, и прочих; для достижения общих целей. А не эти ваши иаки и cicd, которые задолго до DevOps существовали
Ровно как и в любом MVC веб-фремворке — вьюха рендерится через контроллер, но вот в чем прикол, когда у вас вся логика представления лежит в контроллере (VM), ну или компоненте, если брать в расчет сущности из Angular 2, то нам не важно какой темплейт отдать контроллеру/компоненту, это может быть xml, html, json и так далее. Как Вы правильно заметили, подход автора на data- атрибутах уложил состояния в DOM, что и является самой главной ошибкой. Да и вообще разделять логику на два экрана это моветон.
Потрясающая статья. Ещё раз убедился что пора вспоминать чему учился в университете, а то вот так сидишь, учишь 3-й яп или новый framework, а матрицы уже забыл. Недавно ужаснулся, когда осознал что забыл как решать СЛАУ и квадратные уравнения...
Ну вот. Сами себя скомпроментировали)
А вообще, одно дело структура и порядок, а другое дело когда читаешь код и видишь мысль, весь путь ее развития, и как одна эта мысль пронизывает все листинги. Может и правда, опыт и порядок сделали свое дело, но это не отменяет того что код приятно читать. Удачи Вам в новой для Вас сфере)
Даже не знаю как ответить. Нужно самому много раз учавствовать в код ревью чтобы начать чувствовать как написан очередной документ. Даже на хабре часто встречаются листинги с "магическими строками" и объявление переменных посреди логики. У вас я вижу четкую структуру. Каждая сущность оформлена в едином стиле, это, на самом деле, удивляет с учетом упомянутого "чукча не программист". Я последнее время часто занимаюсь ревью кода, который потом отправляется в мастер и в большинстве случаев приходится оставлять комментарии по исправлению стилистических ошибок не смотря на наличие код стайла. У Вас я не нашел к чему придраться, есть некоторые моменты которые я бы сделал по другому, но это. опять же. дело вкуса.
Это почти тоже самое что я написал выше. И я не вижу тут причины уносить toggleClass в контроллер, тем самым разрушая чистую архитектуру. В приложении, над которым я сейчас работаю, более 600 вотчеров на странице (ангуляр 1) и это нагружает двух-ядерный процессор ровно на 2%. Более того, как вы указали, каждый компонент имеет свой ChageDetector, который будет вызываться только если мы что то сделали внутри компонента, например использовали метод через ngClick, а это уже практически равноценно по нагрузке прямому jQuery-стайл коду. Так почему я не должен использовать ngClass и свойство isExpanded?
1) дергается только при изменении скоупа одного уровня или выше
2) можно использовать свойство вместо метода
3) в новом ангуляре вместо дайджеста используется другое решение, которое похоже на дайджест из первого только в N*10 раз быстрее судя по их бенчмаркам, так что не критично
Вы не правы. Компонент — это самостоятельная часть целого, как компонент для приготовления блюда в кулинарии или компонент устройства для его сбора. Что подразумевает под собой компонент внутри системы — дело исключительно контекстное, но компонент не может состоять из двух фундаментальных сущностей. Мы можем сказать, например, что вьюха это компонент MVC, такой же равноценный как и контроллер или модель, часть целого.
Так вот, в Вашем примере логика вьюхи, в данном случае название класса и принцип по котором он устанавливается/снимается с элемента, уехала в компонент (контроллер). Контроллер, в свою очередь, в js приложениях используется как VM и он не манипулирует вьюхой на прямую а является ее модельным представлением, то есть наличие класса active определяется свойством active или isActive. Мало того что это дает возможность сохранять состояния компонентов через сессию, так еще позволяет разделить работу между двумя людьми — верстальщиком и программистом.
Не знаю какой там у Вас опыт, но хороший вкус, судя по коду, явно присутствует, а этим не каждый программист с большим стажем похвастаться может. Спасибо за статью и за милые картинки))
Отвечу Вам в Вашем стиле:
Призыв изучать архитектуру, сам по себе, хорош, но отрицание фреймворков это регресс. Ваши велосипеды, ни что иное, как машина времени, которая везет только в прошлое. Я и, я надеюсь, многие хорошие программисты, придерживаются принципа: «эта задача уже была решена до меня, мне следует уделить все внимание на те задачи, решения для которых еще нет или они, решения, не совершенны.» Готовые решения могут и должны использоваться, в том числе огромное количество модулей и расширений для фреймворков. Естественно, не все то хорошо, что блестит, и в модулях и расширениях тоже надо разбираться, чтобы не поставить что-то уродливое, но это справедливо абсолютно для любого чужого решения.
В статье есть явная подмена понятий:
например реализуя MVP в рамках небольшого компонента просто мысленно разделять, что эти методы – это контроллер, эти свойства – модель и т.д…
Что это вообще значит? Модель и VM — разные вещи, если Вы, конечно, имели ввиду VM, когда говорили о модели, если же нет, то почему модель это только состояние? Более того, тот же VM имеет методы для представления, а уж совмещение контроллеров и VM для меня дикость, это что за паттерн? MVVMC? Методы — контроллеры, совершенный абсурд. Я понимаю что речь про JavaScript, но не все то контроллер что имеет методы. И боже упоси писать методы только для контроллера, я не представляю как потом разбирать этот бардак.
Итого:
Я понимаю, что для реализации пары формочек обратной связи можно обойтись чем то вроде:
function Feedback() {
var name;
var email;
var request;
}
// методы feedback.
а потом привязать этот объект к HTML форме через контроллер, но для чего-то серьезного стоит выбрать инструмент и пользоваться им. Для каждого винтика своя отвертка, ну вы должны понимать что именно я имею ввиду. Совсем не правильно молиться на ангуляр, но отрицать его существование ради несколько проектов, где он проявит себя отлично, просто глупо.
Серебрянной пули нет, а в мире кроме нечисти существует и много других существ, для которых нужно свое, уникальное оружие, если Вы, конечно, понимаете метафору.
У меня расширения для браузера, в котором настроен SOCKS Host tor сети + установленный tor клиент, через который это все работает, по сути переключение сводится к выбору прокси прямо в хроме, так что вопрос удобства спорный )
Осталось только осознать, что DevOps это про культуру взаимодействия Dev, Ops, и прочих; для достижения общих целей. А не эти ваши иаки и cicd, которые задолго до DevOps существовали
А вообще, одно дело структура и порядок, а другое дело когда читаешь код и видишь мысль, весь путь ее развития, и как одна эта мысль пронизывает все листинги. Может и правда, опыт и порядок сделали свое дело, но это не отменяет того что код приятно читать. Удачи Вам в новой для Вас сфере)
2) можно использовать свойство вместо метода
3) в новом ангуляре вместо дайджеста используется другое решение, которое похоже на дайджест из первого только в N*10 раз быстрее судя по их бенчмаркам, так что не критично
Так вот, в Вашем примере логика вьюхи, в данном случае название класса и принцип по котором он устанавливается/снимается с элемента, уехала в компонент (контроллер). Контроллер, в свою очередь, в js приложениях используется как VM и он не манипулирует вьюхой на прямую а является ее модельным представлением, то есть наличие класса active определяется свойством active или isActive. Мало того что это дает возможность сохранять состояния компонентов через сессию, так еще позволяет разделить работу между двумя людьми — верстальщиком и программистом.
и про визу воссоединения с семьей ничего не знаете?
Призыв изучать архитектуру, сам по себе, хорош, но отрицание фреймворков это регресс. Ваши велосипеды, ни что иное, как машина времени, которая везет только в прошлое. Я и, я надеюсь, многие хорошие программисты, придерживаются принципа: «эта задача уже была решена до меня, мне следует уделить все внимание на те задачи, решения для которых еще нет или они, решения, не совершенны.» Готовые решения могут и должны использоваться, в том числе огромное количество модулей и расширений для фреймворков. Естественно, не все то хорошо, что блестит, и в модулях и расширениях тоже надо разбираться, чтобы не поставить что-то уродливое, но это справедливо абсолютно для любого чужого решения.
В статье есть явная подмена понятий:
Что это вообще значит? Модель и VM — разные вещи, если Вы, конечно, имели ввиду VM, когда говорили о модели, если же нет, то почему модель это только состояние? Более того, тот же VM имеет методы для представления, а уж совмещение контроллеров и VM для меня дикость, это что за паттерн? MVVMC? Методы — контроллеры, совершенный абсурд. Я понимаю что речь про JavaScript, но не все то контроллер что имеет методы. И боже упоси писать методы только для контроллера, я не представляю как потом разбирать этот бардак.
Итого:
Я понимаю, что для реализации пары формочек обратной связи можно обойтись чем то вроде:
а потом привязать этот объект к HTML форме через контроллер, но для чего-то серьезного стоит выбрать инструмент и пользоваться им. Для каждого винтика своя отвертка, ну вы должны понимать что именно я имею ввиду. Совсем не правильно молиться на ангуляр, но отрицать его существование ради несколько проектов, где он проявит себя отлично, просто глупо.
Серебрянной пули нет, а в мире кроме нечисти существует и много других существ, для которых нужно свое, уникальное оружие, если Вы, конечно, понимаете метафору.