Не, там дело не в роутере. С роутером как раз все в порядке — они ui.router используют.
У Ионика своя система управления стеком навигации, потому что, например, в приложении с табами для каждого таба будет отдельный стек навигации и просто браузерная история тут не подходит.
В ионике без костылей пока невозможно сделать нормальную навигацию вверх по предполагаемому стеку иерархии вьюх, если приложение инициируется на вложенном стейте. Очевидный пример — открытие приложения по тапу на push-уведомлении.
Допустим, нам надо перейти в диалог, а из него выйти в список диалогов, из которого можно выйти на дашборд. Когда мы начинаем с дашборда и идем вглубь по стеку, все хорошо. Ионик нам покажет кнопочку «Назад», потому что он следит, откуда и куда мы переходим. Но вдруг мы открылись сразу на диалоге! Ионик ни ухом ни рылом, стек навигации пустой. Казалось бы — чего проще: если стек пустой, по кнопке «Назад» идти на некий стейт по-умолчанию. «Гладко было на бумаге, да забыли про овраги» — системная, иониковская кнопка «Назад» показывается только при наличии в стеке навигации «предыдущей» вьюхи, и при пустом стеке она не покажется, даже если ее «форсить» с помощью $ionicNavBarDelegate.showBackButton. Ок, давайте сделаем свою кнопку «Назад» — можно. Только вот системная имеет свои хитрые стили и анимации. Например, умеет под платформы сама подстраиваться.
Открывал им feature, но они решили, что и так хорошо.
Вторая интересная история — с картинками. Как они пишут (и что подтверждают полевые испытания), установка src для img на iPhone 6 вызывает лаг 50-200ms. А у них скролл запилен на JS. А трэд общий. Что происходит при списке из 30 элементов с картинками — можно себе представить.
Пытаются решить двумя способами: загружая картинки через WebWorker и устанавливая вместо ссылки сразу base64, и используя нативный overflow-scroll вместо реализации на JS. С первым вариантом все еще есть вопросы, потому что с base64 все равно есть лаг, хоть и поменьше. Нативный скролл пока только для Android, потому что прикрутили (слава богу) Crosswalk, а iOS нужные события пока не поддерживает.
История с картинками становится еще хуже, когда хочется использовать картинки в элементах collection-repeat (это список, который переиспользует элементы DOM при скролле). Картинки лагают, список дергается как эпилептик.
Более того, раз элементы переиспользуются, картинки выкидываются из кеша браузера и при повторном появлении элемента с ранее отображавшейся картинкой, грузятся заново. Поэтому в случае с collection-repeat только base64.
А использовать его охота уже при величине списка элементов в 100.
Ну и всякое по мелочи, но может быть это мой 4s уже старичок. В десктопном браузере все «как по маслу», как же иначе.
Будем надеяться, что до релиза решат вопрос хотя-бы с картинками. А в целом мне он нравится, наверное, потому что я давно с ангуляром кувыркаюсь.
Fesor, а ты не встречал гайдов как приготовить эту альфу с webpack-ом?
И обязательно ли связываться с traceur'ом чтобы всю эту кухню запустить или они его используют потому что гугл?
А то я тоже последнее время на бабеле с webpack, хотелось бы как-то в этой среде все это запустить для «попробовать».
main-bower-files выдает файлы из пакетов, уже отсортированных согласно дереву зависимостей («dependencies» в bower.json пакета).
Но еще один просто огромный плюс main-bower-files это то, что он может использовать секцию «overrides» в bower.json, чтобы переопределить описание установленного пакета.
Вот пример:
Предположим, что пакет some-another-package использует jquery, но в зависимостях у него он не прописан.
Тогда при обработке main-bower-files его файлы могут выпасть перед файлами jquery и будет у нас красная консоль.
Мы принудительно указываем ему зависимость от jquery и также можем указать разные файлы пакета для разных версий сборки (версию сборки можно указать при вызове mainBowerFiles() в скрипте.
И исходя из всего вышенаписанного открывается еще одна невиданная доселе возможность: указать в качестве зависимости любой файл из git-репозитория, впоследстии описав его зависимости, после чего он будет обработан mainBowerFiles() и включен в проект в правильном месте. Вот «живой» пример:
Пара вещей, которые меня немного, ну скажем, удивили (?)
Я, когда пришел в ангуляр, сам некоторое время делал глобальный конфиг, схему роутов и все это заталкивал в один module.config()
Но через какое-то время пришло озарение, что этот config можно в любом месте делать. Он же как queue, просто добавляются новые шаги в конфигурирование модуля. С тех пор все конфигурации рядом с объектами, которым они принадлежат. Вот пример (правда это из свежего проекта, там 6to5 и ui.router но сути не меняет):
Т.е. у нас во всех отношениях обособленный кусок приложения. Теперь мы вольны подключить объявленый модуль в основное приложение и у нас волшебным образом появится нужный роут. Само собой, модули, объявляющие родительские стейты, тоже должны быть подключены, но это уже вотчина ui.router.
Второе это
mainQuestSvc.submitAnswer().get({ token: vm.userToken, taskNumberString: vm.taskId, answer: vm.answer }, function (result) {
if (result) {
if (result.isAnswerRight) {
...
mainQuestSvc.Statistics().get({ token: vm.userToken }, function (result) {
if (result && result.ok === "OK") {
vm.watched = result.watched;
vm.done = result.done;
} else {
alert('error');
}
});
...
}
});
В официальном канале проекта на гиттере народ пишет, что вовсю использует. Некоторые даже получают прирост производительности.
Пишут, что as stable as node v 0.12
Никак не могу найти информацию о стабильности.
Ранее на главной странице проекта была отметка о статусе проекта, сейчас ее нет. Можно ли считать текущую версию стабильной?
God-object в виде Yii, Rails «впишите тут свой фреймвора» вас также не устраивает?
Совершенно уродский синтаксис директив, с чем связан высокий порог входа для написания директив
В чем он уродский? Или вы не разобравшись с compile, pre-link, post-link, scope transclusion, directive controller, controller require решили забить и обозвать его уродским?
А еще и не все понимают сам DI
Что там можно «не понять»?! Это дело одной недели.
Вам надо было просто написать «Ой, все», всего два слова, а смысла столько же.
Что случится, когда сервер перестанет вывозить N одновременно подключенных клиентов? Нужно будет добавить еще один websocket-сервер.
А взаимодействовать между собой они будут через Redis. Что-то мне подсказывает, что сервер WebSocket уткнется в свой потолок гораздо раньше, чем Redis.
Там чуть сложнее, вот пример ключей, которые он хранит:
1) "/clients"
5) "/channels/time"
7) "/clients/j6hb00g9ta8d8y8b9o48hmi4b2br0bh/channels"
9) "/channels/user/registered"
Т.е. общий пул соединений (клиентов), каналы, на которые подписан конкретный клиент, и очереди для каждого используемого канала.
Клиент-клиент как раз нет, количество каналов будет равно количеству клиентов.
Публикуете в канал /user/:id, на который подписывается пользователь с :id, в сообщении присылаете id пользователя-отправителя.
Ну и огромный плюс faye — он не ограничен одним websocket.
У Ионика своя система управления стеком навигации, потому что, например, в приложении с табами для каждого таба будет отдельный стек навигации и просто браузерная история тут не подходит.
Допустим, нам надо перейти в диалог, а из него выйти в список диалогов, из которого можно выйти на дашборд. Когда мы начинаем с дашборда и идем вглубь по стеку, все хорошо. Ионик нам покажет кнопочку «Назад», потому что он следит, откуда и куда мы переходим. Но вдруг мы открылись сразу на диалоге! Ионик ни ухом ни рылом, стек навигации пустой. Казалось бы — чего проще: если стек пустой, по кнопке «Назад» идти на некий стейт по-умолчанию. «Гладко было на бумаге, да забыли про овраги» — системная, иониковская кнопка «Назад» показывается только при наличии в стеке навигации «предыдущей» вьюхи, и при пустом стеке она не покажется, даже если ее «форсить» с помощью $ionicNavBarDelegate.showBackButton. Ок, давайте сделаем свою кнопку «Назад» — можно. Только вот системная имеет свои хитрые стили и анимации. Например, умеет под платформы сама подстраиваться.
Открывал им feature, но они решили, что и так хорошо.
Вторая интересная история — с картинками. Как они пишут (и что подтверждают полевые испытания), установка src для img на iPhone 6 вызывает лаг 50-200ms. А у них скролл запилен на JS. А трэд общий. Что происходит при списке из 30 элементов с картинками — можно себе представить.
Пытаются решить двумя способами: загружая картинки через WebWorker и устанавливая вместо ссылки сразу base64, и используя нативный overflow-scroll вместо реализации на JS. С первым вариантом все еще есть вопросы, потому что с base64 все равно есть лаг, хоть и поменьше. Нативный скролл пока только для Android, потому что прикрутили (слава богу) Crosswalk, а iOS нужные события пока не поддерживает.
История с картинками становится еще хуже, когда хочется использовать картинки в элементах collection-repeat (это список, который переиспользует элементы DOM при скролле). Картинки лагают, список дергается как эпилептик.
Более того, раз элементы переиспользуются, картинки выкидываются из кеша браузера и при повторном появлении элемента с ранее отображавшейся картинкой, грузятся заново. Поэтому в случае с collection-repeat только base64.
А использовать его охота уже при величине списка элементов в 100.
Ну и всякое по мелочи, но может быть это мой 4s уже старичок. В десктопном браузере все «как по маслу», как же иначе.
Будем надеяться, что до релиза решат вопрос хотя-бы с картинками. А в целом мне он нравится, наверное, потому что я давно с ангуляром кувыркаюсь.
Ладно, попробую на досуге, может чего выйдет.
И обязательно ли связываться с traceur'ом чтобы всю эту кухню запустить или они его используют потому что гугл?
А то я тоже последнее время на бабеле с webpack, хотелось бы как-то в этой среде все это запустить для «попробовать».
Но еще один просто огромный плюс main-bower-files это то, что он может использовать секцию «overrides» в bower.json, чтобы переопределить описание установленного пакета.
Вот пример:
Предположим, что пакет some-another-package использует jquery, но в зависимостях у него он не прописан.
Тогда при обработке main-bower-files его файлы могут выпасть перед файлами jquery и будет у нас красная консоль.
Мы принудительно указываем ему зависимость от jquery и также можем указать разные файлы пакета для разных версий сборки (версию сборки можно указать при вызове mainBowerFiles() в скрипте.
И исходя из всего вышенаписанного открывается еще одна невиданная доселе возможность: указать в качестве зависимости любой файл из git-репозитория, впоследстии описав его зависимости, после чего он будет обработан mainBowerFiles() и включен в проект в правильном месте. Вот «живой» пример:
Само собой, это грязный трюк — завтра реп могут благополучно грохнуть, но иногда он выручает просто безмерно.
Я, когда пришел в ангуляр, сам некоторое время делал глобальный конфиг, схему роутов и все это заталкивал в один module.config()
Но через какое-то время пришло озарение, что этот config можно в любом месте делать. Он же как queue, просто добавляются новые шаги в конфигурирование модуля. С тех пор все конфигурации рядом с объектами, которым они принадлежат. Вот пример (правда это из свежего проекта, там 6to5 и ui.router но сути не меняет):
Т.е. у нас во всех отношениях обособленный кусок приложения. Теперь мы вольны подключить объявленый модуль в основное приложение и у нас волшебным образом появится нужный роут. Само собой, модули, объявляющие родительские стейты, тоже должны быть подключены, но это уже вотчина ui.router.
Второе это
Такое, да в контроллере, да без промисов…
Пишут, что as stable as node v 0.12
Ранее на главной странице проекта была отметка о статусе проекта, сейчас ее нет. Можно ли считать текущую версию стабильной?
God-object в виде Yii, Rails «впишите тут свой фреймвора» вас также не устраивает?
В чем он уродский? Или вы не разобравшись с compile, pre-link, post-link, scope transclusion, directive controller, controller require решили забить и обозвать его уродским?
Что там можно «не понять»?! Это дело одной недели.
Вам надо было просто написать «Ой, все», всего два слова, а смысла столько же.
А взаимодействовать между собой они будут через Redis. Что-то мне подсказывает, что сервер WebSocket уткнется в свой потолок гораздо раньше, чем Redis.
1) "/clients"
5) "/channels/time"
7) "/clients/j6hb00g9ta8d8y8b9o48hmi4b2br0bh/channels"
9) "/channels/user/registered"
Т.е. общий пул соединений (клиентов), каналы, на которые подписан конкретный клиент, и очереди для каждого используемого канала.
Публикуете в канал /user/:id, на который подписывается пользователь с :id, в сообщении присылаете id пользователя-отправителя.
Ну и огромный плюс faye — он не ограничен одним websocket.