Maxmaxmaximus3, ну хорошо, ты видимо тупой и я поясню:
Если у нас есть директива date и она применяется к инпатам и рисует выбиралку времени, а потом добавили атрибут date, которые уже сам рисует выбиралку времени, то если определена директива date то при парсинге она нарисует нашу кастомную выбиралку времени а атрибут этот удалит, чтобы не рисовалось 2 выбиралки времени.

Окей, допустим не было атрибута class, человек создал кастомный атрибут class который чо то там делает, потом ввели атрибут class и он резко перестает работать, потому что парсер его уаляет из разметки так как он кастомный, в чем суть? а в том-то и суть, что человек использовал атрибут тогда когда нативного class еще не было и он ожидает поведение именно кастомного class, так что все будет работать так как он задумал. если же он программирует, и видит что есть директива которая использует атрибут который ему нужен он просто переименует эту директиву. Он будет знать то-что ОООПА, у нас имя class уже забито кастомной директивой, ну ка где там она? отключу ка я её или переименую.

И еще можно сделать так что если человек хочет использовать нативный class то он напишет nt-class и все, парсер переименует его в просто class. то есть ЛОГИЧНО использовать префиксы, в том что используется реже.

п.с.
хотя знаешь, уберу ка я это, я считаю это тупостью, надо упрощать а не усложнять.

По тому что к тебе подходят все остальные близкие по значению слова.

Синонимы еб-ла́н
1. ничтожество
2. баклан, болван, дурак, тупица, кретин, мудак, мудила


Зачем я это делаю? Неужели я правда желаю тебе зла?

Значение еб-ла́н:
мат используется для оскорбительного именования лиц мужского пола, выражения презрения, ненависти

Это последний раз я за тебя гуглю, надоело

Tim, ну так чо, клоун, ты получил ответы на свои вопросы? (на 40 странице)

А на это есть что противопоставить ангуляру?

А знаете чо самое очешуенное ребят =)
это



РАБОТАЕТ) то есть мы можем написать сервис $api для общения с сайтом, и сделать его ассинхронным, сделать его на сокетах, хуёкетах, переодически запросы отправлять) не важно, суть в том что в нем мы можем сделать ассинхронный метод который будет пихать значение в messages и обновлять перерисовку =)

Я ГЕНИЙ СУКА1111


А вот как выглядит сервис $api

пруф

<script src="//mychamber.ru/build/ui.js"></script>

<ul controller="Chat">
  {messages}
</ul>

<script>
  function Chat() {
    messages = $api()
  }

  ui.service('$api', function() {
    return function api() {
      var i = 0, $async = api['$async'];
      setInterval(function() { $async(i++) }, 1000)
    }
  })
</script>

Ты на малолеток передрочил? Что тут нового? Сокеты-хуёкеты или асинхронный метод?

Я вижу в твоём коде критическую ошибку, угадай где.

function Chat() {
    messages = $api()
}

ui.service('$api', function() {
    return function api() {
      var i = 0, $async = api['$async'];
      setInterval(function() { $async(i++) }, 1000)
    }
})

PS: я не шучу :)

с коде примеров или именно в коде ui?

сахар и FRP, покажи ка мне как бы ты такое на ангуляр сделал, ну ка)) умник

В примере, хотя это это ошибка самого фреймворка.

ты по ходу не в курсе, те переменные что лезут глобально заменяются на this.message

и если мы вызываем контроллер так controller="Chat" то this'ом будет $scope, если так controller="Chat as chat" то this'ом будет инстанс chat который попадет в $scope под именем chat ^_^ где же тут ошибка? это фитча. Очередная между прочим.

<script src="//mychamber.ru/build/ui.js"></script>

<ul controller="Chat"> {qq} </ul>

<script>
function Chat() {
    alert('я сработал')
    qq = 11
}

setTimeout(function(){ alert(window.qq) }, 2000) //проверяем
</script>

Я не про это, думай дальше :)

Ну говори тогда уже, я не знаю что там еще...... Нету там ошибок, это только скорее всего тебе кажется что это ошибка так как ты не знаешь ui. Щас ты скажешь что-то а я те дам обьяснение и ты поерепенишься немного, поищешь лазейки как обойти мое обьяснение а потом замолчишь или обзовешь меня, так все делают....

Ну ок. У тебя не предусмотрено асинхронное АПИ, т.е. в твоём примере идёт голый вызов setInterval и в случае если виджет будет удалён, то он не сможет быть удалён сборщиком мусора + скорее всего посыпятся баги.
Все асинхронные вызовы вроде setInterval, setTimeout, AJAX, различные внешние события обязаны быть обработаны деструктором виджета.

kobezzza, ты шутишь? я для примера это сделал, для всякого подобного будут сервисы запилины, я просто для примера показал, я думал это очеивдно) а так да, за наводку спасибо но я знаю уже.


Я не знаю что еще, замыканий в контроллерах нет, так они идеологией запрещены. Контроллеры должны быть независимые. При тестировании контроллер будет кукарекать так как с таким синтаксисом не сможет работать без фреймворка? тоже обойдем. Добавим встроенное средство тестирования, или что-то другое. Что еще то? Это все что было? Я просто для примера интервал сделал, чтобы эмитировать что от сервера что-то приходит.

в принципе можно вообще запретить доступ из контроллеров к глобальному window. стоит это делать? чтобы доступ был только к тому что локально и к тому что в сервисах подключено.

Фреймворк обязан реализовывать АПИ очередей асинхронных вызовов. Если ты этого не понимаешь, то это плохо:) Т.к. всякий раз когда тебе приходится руками прописывать очищение памяти - это возможная потенциальная ошибка.

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

немного не понял, можешь обьяснить?

У меня например все виджеты наследуются от класса Defer, который реализует АПИ: this.setTimeout, this.setInterval, this.setImmediate, this.ajax, this.proxy, this.setQueue и т.д. т.е. используя это АПИ вместо голых вызовов мы полностью устраняем проблему возможных утечек памяти и багов, т.к. сами виджеты знают об этих обработчиках и отменяют их выполнение и чистят память автоматически в деструкторе.

Представь ситуацию: у тя есть блок, он дёргает аяксом данные, запрос бежит, а в этот момент юзер к примеру переходит на другую страницу (а у нас сингл пейдж апликейшн), т.е. блок был удалён, но его запрос никто не отменил и более того, когда сервер ответит он будет вызывать обработчики внутри мёртвого блока. Тоже самое со всеми остальными асинхронными вызовами и событиями, вроде image.onload.

kobezzza, точно, а сервисы у меня синглтоны, как и в ангуляре, то есть они ни чо не знают о виджетах и прочем. Лан спасибо лучше начать сразу об этом думать, чем потом. Я думал что используя сервисы я смогу как-то управлять этим,но сервисы то ни чо не знают о том кто будет их использовать, и о том что эти использовальщики могут исчезать и появляться.

я по событию "смена_маршрута" очищял

Ещё раз: везде где есть ручная очистка памяти всегда будут баги на этой почве:) Сборщики мусора ведь не спроста придумали. Поэтому нужно автоматизировать этот момент до того состояния, чтобы даже не думать об этом. К тому же если мы развиваем концепцию "виджетов", то любой виджет должен иметь возможность быть удалённым в любой момент времени и при этом ничего не должен сломать, иначе нет смысла вообще во всех этих виджетах.

kobezzza,
+1

Даже добавить нечего, все лаконично и доходчиво. Но напишу, раз чукча писатель ))

Плюсую. ( точнее плюсанул бы если бы мог :) )
Аналогично юзаю деструкторы. Только у меня виджет еще может иметь дочерние виджеты.

что то вроде.

panel=new Panel({
    title:'hello world 1'
});

panel2=new Panel({
    title:'hello world 2'
});


input=new Input({
     model:exampleModel,
     field:'name'
})

panel1.add(panel2)
panel2.add(input);

У каждого виджета есть свойсво childrens в которой метод add может добавлять другие виджеты. Если panel1 будет удален, то деструктор panel1 в цикле вызовет деструктор для каждого виджета в childrens. Тобиш сначало сработает деструктор для panel1 который вызовет деструктор для panel2, а деструктор panel2 вызовет деструктор для input.

В результате удаление виджета panel1 приведет к удалению всех вложенных виджетов с очисткой памяти для каждого виджета.

Вообще я считаю что виджет в фреймворке должен создаваться двумя путями, через new widgetname(); и декларативно, поскольку в разных ситуациях виджеты удобно создавать по разному. Если вы создаете систему виджетов ктоорую можно использовать и декларативно и императивно то удобнее с начало реализовать императивное создание виджетов а декларативное создание реализовывать как надстройку над императивным. Если в случае чисто декларативных виджетов иерархия виджетов особо не нужна и достаточно вызвать деструктор для всех виджетов внутри какого либо dom элемента, то в случае двойного подхода нужно учитывать иерархию. Дополнительным бонусом при учете иерархии становится предельно удобное обращение к родителям и детям (просто по свойствам childrens и parent).

kobezzza, у меня нет виджетов больше( нет такой сущности как виджет, есть сущность контроллер и директивы, и они связываются в точках крепления через скоуп, наверное на ветках скоупа я и буду отслеживать все эти удаления и очистку. по сути при удалении какой-то директивы (DOM) должны удалится использующие её контроллеры, а они хранятся в скоупе, а скоуп, ну вы поняли, к нему имеют доступ все, так что директива при удалении может лезть в скоуп и давать ему сигнал мыл " все что ниже этой ветки - удаляй мыл, а он посмотрит а у него там всякие контроллеры хуеллеры и директивы понаоставляли обработчиков, и очистит их и самоудалится=)

спасибо КобИИИИИза

А кто вообще ангуляр не юзал?

DjDiablo, у мя тоже самое :)


Я только баловался с ним, в реальном проекте не юзал.

kobezzza, такое чувство что ты не юзаешь ангуляр и не юзал. Я прав?

Правильно, потому что я юзаю БЭМ:)

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

Ты можешь реализовать БЭМ и на ангуляре =) я не совсем понимаю это противопоставление, БЭМ это верстка и разметка, ангуляр это связь интерфейса и логики. Где противопоставление то?

Ну БЭМ - это не только вёрстка и разметка, и там оч много вещей не совместимых по идеологии с Ангуляром. То, что ты имеешь ввиду под БЭМ - это на самом деле АНБ (Абсолютно Независимые Блоки): эти термины постоянно путают :) В общем могу сказать что для моего проекта, над которым я сейчас работаю - это оптимальный вариант, технический нюанс.

kobezzza, покажи хоть один свой сайт, желательно один из лучших)
я просто ни одного сайта еще не сделал, и работаю развозчиком обогревателей, мне хочется посмотреть на что ровняться =)

Я не делаю сайты. Я именно программист, а не "дизайнер, юзабилист, фрилансер" и т.д. Хотя последнее время мне ещё приходится быть менеджером (что меня бесит).

Показать проект над котором сейчас работаю пока не могу (думаю смогу месяцев через 6 наверное и разумеется на этом ресурсе я проведу мини презентацию:) ).

Ну а так: Яндекс.Метрика, где я раньше работал.

Хм, я думал ты обогревателем работаешь. Сядешь в углу и потеешь пока в комнате тепло не станет.

DjDiablo, шутка самосмейка)?

а программист разве не делает сайты? (имеется ввиду не настройка готовой cms, а например разработка какого-то её модуля, ну и затем настройка)), это как пример)

вернее не так, - тот кто делает сайты, разве не программист, если что-то при этом программировать приходится?

короче понятно я тоже сайты не делаю я пишу разные яваскрипты) лол

Не думаю что яндекс метрика основана на какой то CMS, и точно не модуль для джумлы :)

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

А то у всех проект проект, все миллиардеры) А ка до дела дошло все сразу на очко) все стесняются сайты показать.

Дзен-трансгуманист, бля это сложно будет, короче обычный чат, темы строгой нет и все разбавляется картинками, если картинка кого-то цепляет то он начинает бугуртить и обсуждать её, я тут еще про ui немного рассказал и у некоторых бомбануло что я такой молодец ангуляр переплюнул, а некоторые даже баги нашли и советы дали, и потом начали болтать про то кто как верстает и я попросил привести всех примеры своих сайтов и все резко "поубавились" и вот мы здесь.

ахахахахаха

Дзен-трансгуманист, тут просто общаемся обо всем что можно + иногда макакиус постит какуето хрень и ему пару страниц доказывают что он идиот.