Зависит от восприятия. Можно понимать как немецкий почтальон докладывает, что у вас 4 непрочитанных сообщения. Развенулся спиной, и показал почтовый ящик
d.ts генерится компиляторм, а библиотеки не задумывающиеся о ТС продолжают о нем не задумываться.
Нагрузки вообще никакой нет. Если пользоваться нормальными обычными инструментами, то пользу от ТС зацениваешь уже через несколько часов после того, как начал на нем писать.
Звонок заключается в том, что вдруг видишь у себя Missed call и голосовое сообщение типа: «Ищете ли вы работу?». Штук 5 таких получил за предыдущие две недели
Redux действительно непросто использовать в средних и крупных проектах, особенно когда бизнес-аналитика часто меняет свои решения по поводу функционала дизайна и пр. Поэтому, все эти примеры из туду листов и генераторы бойлерплейтов не особо работают в таких проектах. Так же сложности добавляет тот факт, если работает над проектом не один человек, а 4-5-n. Тогда эти бесконечные гигабайты шаблонного кода с action_types, actions и reducers точно начнут сводить с ума, если с ними ничего не придумать.
Один из вариантов решения проблемы, который к слову работает в продакшне, среднего+ проекта, частично решает вышеописанные проблемы https://github.com/welljs/react-redux-mvc. Может показаться, что с паттерном mvc погорячился, но идея именно в том, чтобы довести фреймворк до состояния близкого к mvc
Принцип прост: компонента react (view) — тупо рисует то, что получила через props от Model. Model — обертка вокруг redux, это то место где формируется грубо говоря json-представление прикрепленной к ней вьюхи, Controller — связывает model и вью, а так же обрабатывает ui-события.
Структура проекта получает следующий вид
/classes - классы для работы с данными
/components - компоненты. тупые умные, не важно. компонуются по принципу - все что нужно компоненте, лежит в ее директории
/layouts - лэйауты - с сайдбаром, без сайдбара, логин, лэндинг ...
/pages - страницы, и компоненты принадлежащие конкретной странице. Также компонуются по принципу, все что нужно лежит в одной директории. Если компонента становится общей для нескольких страниц, обычно достаточно Ctrl+X -> Ctrl+V в папку с компонентами. Умная IDE пути в импортах сама исправит
/redux - экшны для получения данных не имеющих привязки к конкретной вьюхе, например user, agreements, partners
/utils - всякое
Из плюсов: сравнительно легко объяснить принцип работы, дебажить, тестировать, компоновать-перекомпоновывать, шарить компоненты и т.п.
Из минусов: все еще приходится писать немного шаблонного кода, есть небольшие недоделки и не полностью реализован весь замысел
Если кому станет интересно, буду рад почитать отзывы, а если вдруг даже появятся контрибуторы, тогда точно буду знать, что проект годный
На сколько мне известно, использование id или class влияет на поиск элемента в DOM и соответственно на производительность. Так как предполагается, что id уникален в пределах документа, то при поиске по id, браузер останавливает поиск как только находит нужный элемент, а при поиск по классу он производит поиск пока не проверит все элементы в DOM, даже если нужный элемент был единственный, и найден в самом начале. Поэтому использовать нужно и то и другое, в зависимости от ситуации.
Вот например: EmberConf 2015 — Видео плейлист с конференции EmberConf 2015.
Уже ясно что это видеоматериал, и если ты, в данный момент читаешь со смартфона, то не очень удобно будет его просматривать
P.S. Там написано, что это видео, не обратил внимания. Но идея все равно хорошая )
Предлагаю помогать автору писать комментарии к тем или иным статьям/библиотекам и т.п., на которые ведут ссылки. Многие ведь заходят и читают что там, и после этого вполне смогут оставить свое мнение в личку автору. Это снизит нагрузку с автора, а остальным читающим действительно легче будет ознакамливаться с материалом по комменту к ссылке.
Спасибо за минусы, приму их как знак внимания. Обосную тем кому все таки интересно. Во-первых плохой тон обращаться к свойствам напрямую — это одно из фундаментальных правил программирования. Например, тут или тут тут мнение авторитетов. Во-вторых, работать можно не только в одиночку — и когда работаешь в команде, то сложно отвечать и контролировать чужие действия, а если команда находится в разных городах, а то и часовых поясах, то еще сложнее. Поэтому если ты используешь чье-то свойство, то лучше избегать прямого обращения к нему, а пользоваться геттерами и сеттерами, потому-что «хозяин свойства» в любой момент может что-то изменить или зарефакторить и в этом случае, он не обязано спрашивать чье-то мнение. Сюда же можно добавить то, что даже когда сам начинаешь проект, то должен понимать, что статика может меняться много-много раз, и для того чтобы не править всё и везде, легче править в двух местах — в геттере и сеттере.
//где-нибудь в базовой вьюхе функция которая является и сеттером и геттером.
frg: function (name, el) {
!this.domElements && (this.domElements = {});
return el ? (this.domElements[name] = el, el) : this.domElements[name];
}
// Использование наследуемых вьюхах:
// в сеттер надо передать два параметра: название и сам элемент.
// сеттер так же возвращает закешированный элемент
this.frag('my-block', this.$('#my-block')).css({display: 'block'});
// геттер получает один аргумент и возвращает из кеша элемент
this.frag('my-block').css({display: 'block'});
Иногда статичное свойство может измениться, и тогда придется искать его, и править по всему проекту. А в случае с методом, придется изменить свойство только внутри метода, который его возвращает.
Поскольку мир IT настолько велик и разнообразен — то придумывать индивидуальные задачи порой очень трудно
Причем тут мир IT? Вы работаете в конкретной области, и ищите конкретного специалиста, который будет выполнять конкретные задачи. Придумать задачу, когда все конкретизировано проще паренной репы. Если вы засечете время, то заметите, что на придумывание задания, которое соответсвует этой конкретной работе, уйдет не более 15 минут, скорее даже меньше. Но это избавит от утомительных собеседований, которые на 80%-90% трата времени.
Но поскольку с данной библиотекой мне работать не приходилось, касательно нее я ничего спросить не мог
А зря, бегло глянув в код, можно понять как человек работает, и если код визуально понятный, то можно вникнуть и понять ход мысли программиста.
На мой взгляд функции на бумаге и тому подобное позволяет интервьюеру найти с вами общий язык
С чего вы взяли что вы находите общий язык? Вы часто интересуетесь о том, удобнее ли соискателю написать в IDE или на бумаге, и оба соглашаетесь в том, что на бумаге программировать куда удобнее?
В общем не думаю, что вопросы такого типа должны сильно смутить квалифицированного разработчика
Но лучше, наверное, спросить квалифицированного специалиста, не смущают ли его такие вопросы, а не думать за него.
Вы так и не согласились с тем, что как и другие специалисты, интервьюверы тоже бывают плохие и хорошие, подготовленные и не подготовленные. И как и других специалистов, плохих интервьюверов гораздо больше чем хороших.
P.S. У меня к соискателям еще одно требование: рассказать смешной анекдот или шутку. Но это так, чтобы понять, как в коллектив вольется )
Хочется отметить, что провальные собеседования не заслуга одних лишь соискателей. Если бы собеседующих можно было категоризировать как разработчиков, то бОльшая часть интервьюверов была бы джуниорами, а то и хуже. Скажу от имени более-менее квалифицированного специалиста, который был по обе стороны барикад: это оскорбительно, когда по дороге на интервью ты собираешься с мыслями о том, как проектировать системы, как оптимизировать узкие места, как граммотно организовать работу и как управлять командой разработчиков, приезжаешь, а тебя спрашивают: «что выполняет эта функция» — написанная на бумаге? Это очень оскорбительно, черт возьми! Собеседование и набор персонала — это ответсвенное задание, а большинство относятся к этому более чем легкомысленно. Неужели так трудно придумать задание из текущей работы? Да таких заданий можно напридумывать хоть для каждого претендента в отдельности. Надо только мозгой шевльнуть и тогда легко сможешь определить людей знакомых с нужным стеком технологий, с теми кто быстро осваивает новые технологии, с ходом мысли разработчиков и всем остальным, что необходимо для того чтобы взять на конкретную работу конкретного человека. При всем этом съэкономить время и нервы себе, и соискателю.
ES6 Module Transpiler is an experimental compiler that allows you to write your JavaScript using a subset of the ES6 module syntax, and compile it into AMD or CommonJS modules.
Как-то надо было срочно решать поставленную задачу, а много времени на изучение существующих решений не было. Самое популярное что было на слуху — Require.js, но с ним я споткнулся, что привело к написанию скорее не велосипеда, а наворотов к нему. На самом деле, у меня обертка над Require.
Кроме того, я отношусь у группе людей, которые любят изобретать велосипеды, чтобы быть в тонусе :--)