Ну точно не линейный график. Не должно быть ощущения связанности соседних характеристик. Столбцы могут смотреться хуже и теснее, но точно не будут дезинформировать и тянуть собой не существующую информацию.
Что-то так и не ясно что за что отвечает. Тот факт, что у человека активизируется зона распознавания лиц, когда он из видит во сне, не говорит вообще ни о чем. Это как сказать "учёные установили, что когда человек видит, он видит глазами". Очевидно.
А мне вот после 4х лет первого ангуляра (в продакшене, еще когда была бета) реакт показался гораздо более приятным. Именно приятным и увлекательным – думаю, из-за того, что основе программирования на с React лежит JS. Не html-шаблоны с директивами, не компоненты, а стандартные конструкции языка — с тем лишь отличием, что они могут возвращать html в качестве результата. Приятно потому что это насыщает работу чистым программированием, а не строительство конструкций в мире фреймворка.
Да ладно вам. Дело не в страдании, а в удивительном (и поучительном!) опыте превозмогания таких трудностей, которые кажутся непревозмогаемыми. Могу с уверенностью сказать, что Dark Souls делает человека крепче и лучше: учишься терпеть неудачи, учишься уважать противника, учишься подавлять эмоции и действовать с холодной головой. В общем-то ведь все как в жизни: все серьезные начинания кажутся непреодолимыми.
На форумах пишут, что смысла особо нет. Один знакомый имеет разочаровывающий опыт употребления МДМА с СИОЗС (и палки в колеса терапии) И вообще если вам показаны АД, то лучше поменьше баловаться с прочими психотропными.
Только вот написание велосипедов прокачивает, а npm install --save leftpad – нет. Как обычно, успех где-то посередине: в умении оценить свои способности и внешние требования, и принять решение о самостоятельной разработке, или использовании готового. Вариант "выясняешь, как авторы проекта справились с задачей" не подходит: все равно без практики ничего не запомнишь и не поймешь.
Я бы сказал так: нужно пользоваться любой возможностью писать свои решения (и быть ответственным за велосипеды), но работать в таких внешних условиях, когда просто физически не можешь себе это слишком часто позволить.
Интересно — как часто это "в лоб, как есть" приносит положительный результат? Если задуматься, то становится очевидно, что такого рода критика вообще не призвана улучшать чью-то деятельность, а преследует только цель подчеркнуть уровень критикующего. Покопаться немного глубже — и можно обнаружить клубок когнитивных искажений, распространенных в постсоветской культуре: оценочные суждения, привязка достоинства личности к достижениям (привет, карма!), завышенные ожидания от окружающего, пассивная жизненная позиция с претензией.
Ниже пишут про бесполезность одобрительных комментариев, но было бы очень хорошо, если бы какая-то часть комментариев и здесь, на хабре, была такая: выражающая поддержку человеческим стараниям и хоть какой-то проделанной работе.
Автору лучей добра и любви! ️ ️ ️
Да, на хабре этого особенно не хватает.
(Даже мои эмодзи с сердечками разметка вырезала)
С попапами в результате пришел к следующему подходу:
1) Попап — это не компонент, а стейт. Он не является частью текущей страницы.
2) Работа с попапом аналогична работе с удаленным сервисом: открыли с некоторыми параметрами, после закрытия получили результат работы.
Получилось что-то такое:
angular.module('app').config($popupProvider => {
$popupProvider.popup('login', {
controller: ($scope) => {
//в $scope.popup контроллер попапа, в $scope.popup.options - переданные при открытии данные.
// По идее, лучше бы инжектить, но руки не дошли.
},
template: `
<div class='popup__title'>Login</div>
<div class='popup__content'>...</div>
<div class='popup__buttons'>
<button ng-click="ctrl.login()">Login</button>
<button ng-click="$popup.close(false)">Cancel</button>
</div>
`
});
});
Вроде бы уже тысячу лет как известно, что хороший рецепт это: 1) пишем рабочий код, 2) делаем код правильным для дальнейшего масштабирования. Можно (и лучше) впихнуть на первое место тесты и делать все по ТДД, можно нет. Только правильный код пишут обычно молодые ребята, познакомившиеся с паттернами и рефакторингом, неизбежно скатываясь в оверинжиниринг. Только рабочий код, по-моему мнению, пишут какие-то говнари, в проект которых посторонним лучше не заглядывать вообще.
$scope.on('$destroy", function () {
map.removeMarker(marker);
});
Когда ngRepeat удалит элемент (и его скоуп), вызовется соответствующий колбэк. У вас же самописный монстр synchronize, который дублирует фактически реализацию ngRepeat.
Кстати, не понимаю, почему не вынесут код из ngRepeat в сервис — функция непростая, а следить глубоко за массивами приходится иногда, писать свое решение как-то глупо.
Внутри — может быть и одно и то же, но при написании библиотеки важно все же как это снаружи, для пользователя библиотеки.
В вашем случае описание элементов карты находится где-то в контроллере, в моем — во view, что правильнее, т.к. карта и ее элементы — это отображение. В моем подходе можно, например, применить фильтры для сериализации некой модели гео-объектов в удобный для директивы вид:
<ng-map-marker ng-repeat="geoObject in geoObjects" source="geoObject|serializeGeoObject">
Это, конечно, может быть медленнее в целом, но подход более чистый для разделения безнес-логики и вью-логики.
В свое время релизоаывал прослойку для гуглокарт. У меня была такая структура:
общая директива ng-map создавала общий scope и принимала общие конфиги для всех объектов карты, все нижеперечисленные директивы должны быть вложены внутрь данной.
ng-map-canvas для полотна карты
ng-map-marker для позиционирования маркера. Для нескольких маркеров можно использовать ng-repeat :)
ng-map-route и ng-map-route-waypoint (в сочетании с ng-repeat) для отрисовки маршрутов
ng-markers-cloud — оптимизированный вариант для показа большого количества маркеров, в ng-model можно передать массив для вывода. Из минусов — наблюдение за массивом ведется только по ссылке, изменение отдельных элементов не приведет к перерисовке.
ng-map-overlay — универсальная директива, годится как для отображения кастомных маркеров, так и для модальных окон на карте, всплывающих облачков, тултипов. Создавала оверлэй для карты, куда помещалось переданное внутри директивы html-содержимое со всеми преимуществами дата-байндинга.
Мне лично кажется, что такой подход — с описанием объектов карты в разметке более соответствует принципам фреймворка.
Ну точно не линейный график. Не должно быть ощущения связанности соседних характеристик. Столбцы могут смотреться хуже и теснее, но точно не будут дезинформировать и тянуть собой не существующую информацию.
Кажется, лучше не делать линейные графики если ось X не временная.
Что-то так и не ясно что за что отвечает. Тот факт, что у человека активизируется зона распознавания лиц, когда он из видит во сне, не говорит вообще ни о чем. Это как сказать "учёные установили, что когда человек видит, он видит глазами". Очевидно.
ну и как это противоречит утверждению "является одним из самых важных языков программирования на сегодняшний день"? :)
А вы выключите у себя JS в браузере и, думаю, поймете.
Да ладно вам. Дело не в страдании, а в удивительном (и поучительном!) опыте превозмогания таких трудностей, которые кажутся непревозмогаемыми. Могу с уверенностью сказать, что Dark Souls делает человека крепче и лучше: учишься терпеть неудачи, учишься уважать противника, учишься подавлять эмоции и действовать с холодной головой. В общем-то ведь все как в жизни: все серьезные начинания кажутся непреодолимыми.
Только вот написание велосипедов прокачивает, а
npm install --save leftpad– нет. Как обычно, успех где-то посередине: в умении оценить свои способности и внешние требования, и принять решение о самостоятельной разработке, или использовании готового. Вариант "выясняешь, как авторы проекта справились с задачей" не подходит: все равно без практики ничего не запомнишь и не поймешь.Я бы сказал так: нужно пользоваться любой возможностью писать свои решения (и быть ответственным за велосипеды), но работать в таких внешних условиях, когда просто физически не можешь себе это слишком часто позволить.
Интересно — как часто это "в лоб, как есть" приносит положительный результат? Если задуматься, то становится очевидно, что такого рода критика вообще не призвана улучшать чью-то деятельность, а преследует только цель подчеркнуть уровень критикующего. Покопаться немного глубже — и можно обнаружить клубок когнитивных искажений, распространенных в постсоветской культуре: оценочные суждения, привязка достоинства личности к достижениям (привет, карма!), завышенные ожидания от окружающего, пассивная жизненная позиция с претензией.
Ниже пишут про бесполезность одобрительных комментариев, но было бы очень хорошо, если бы какая-то часть комментариев и здесь, на хабре, была такая: выражающая поддержку человеческим стараниям и хоть какой-то проделанной работе.
Автору лучей добра и любви! ️ ️ ️
Да, на хабре этого особенно не хватает.
(Даже мои эмодзи с сердечками разметка вырезала)
Второй вариант хуже: нет поднятия, нет имени функции при отладке.
В фейсбуке на днях говорили по the grid:
Добро пожаловать в мир искусственного интеллекта, хехе.
С попапами в результате пришел к следующему подходу:
1) Попап — это не компонент, а стейт. Он не является частью текущей страницы.
2) Работа с попапом аналогична работе с удаленным сервисом: открыли с некоторыми параметрами, после закрытия получили результат работы.
Получилось что-то такое:
Далее, можем открыть попап в любом контроллере:
Открывшийся попап вставляется в дно body, каждый раз инстанцируя контроллер. При закрытии дестроится, попап удаляется и DOM.
Опыт перенять у секс-индустрии.
Когда ngRepeat удалит элемент (и его скоуп), вызовется соответствующий колбэк. У вас же самописный монстр synchronize, который дублирует фактически реализацию ngRepeat.
Кстати, не понимаю, почему не вынесут код из ngRepeat в сервис — функция непростая, а следить глубоко за массивами приходится иногда, писать свое решение как-то глупо.
В вашем случае описание элементов карты находится где-то в контроллере, в моем — во view, что правильнее, т.к. карта и ее элементы — это отображение. В моем подходе можно, например, применить фильтры для сериализации некой модели гео-объектов в удобный для директивы вид:
<ng-map-marker ng-repeat="geoObject in geoObjects" source="geoObject|serializeGeoObject">Это, конечно, может быть медленнее в целом, но подход более чистый для разделения безнес-логики и вью-логики.
ng-mapсоздавала общий scope и принимала общие конфиги для всех объектов карты, все нижеперечисленные директивы должны быть вложены внутрь данной.ng-map-canvasдля полотна картыng-map-markerдля позиционирования маркера. Для нескольких маркеров можно использовать ng-repeat :)ng-map-routeиng-map-route-waypoint(в сочетании с ng-repeat) для отрисовки маршрутовng-markers-cloud— оптимизированный вариант для показа большого количества маркеров, в ng-model можно передать массив для вывода. Из минусов — наблюдение за массивом ведется только по ссылке, изменение отдельных элементов не приведет к перерисовке.ng-map-overlay— универсальная директива, годится как для отображения кастомных маркеров, так и для модальных окон на карте, всплывающих облачков, тултипов. Создавала оверлэй для карты, куда помещалось переданное внутри директивы html-содержимое со всеми преимуществами дата-байндинга.Мне лично кажется, что такой подход — с описанием объектов карты в разметке более соответствует принципам фреймворка.