Подчеркивания позволяют повысить читаемость — проще увидеть количество аргументов, которые пропущены.
Ломать обратную совместимость в случае с жс — очень плохая идея, поэтому ввели специальный режим strict.
func(); // func объявлена, но не имеет значения, поэтому ошибка "func не является функцией"
var func = function func() {
console.log("Всё в порядке");
};
Все верно. В JS есть два типа декларирования переменной: variable (динамический тип) и function. Оба объявления hoist-ятся наверх в первом проходе компилятора (когда объявляются переменные). Function не может быть undefined, поэтому она сразу же регистрируется.
Думаю, так будет понятнее:
func1();
func2();
function func1(){};
var func2 = function(){};
превращается за счет hoist в
function func1(){};
var func2;
func1();
func2();
func2 = function(){};
До ES6 было широко известно, что с помощью оператора typeof можно безопасно узнать, объявлен ли идентификатор, даже если ему не присвоено значение:
if (typeof Symbol !== "undefined") { // Symbol доступен }
if (Symbol !== "undefined") { // Этот код выкинет исключение, если Symbol не объявлен}
Бред. Так никогда не писали.
Начнем с того, что нам нужно узнать, объявлена ли переменная, чтобы с ней можно было работать. В функциях нам это не надо, потому что мы сами их и объявляем, а если и надо — можно воспользоваться блоком try-catch, это крайне редкий кейс.
Если мы работаем в глобальном пространстве — нужно пользоваться 'Symbol' in global<window, например> или .hasOwnProperty()
Typeof дает возможность быстро провериться, но его использование почти всегда скорее мешает, его нужно использовать в двух случаях:
1. определение типа для простых типов (для создания функций с несколькими интерфейсами)
2. быстрая проверка типа объекта при создании API: a instanceof Object не работает, если a взят из айфрейма.
С массивами все тоже очень забавно. Давайте-ка я попробую объяснить, как оно работает.
z = new Array(10);
z[10] = 5;
Object.keys(z)
["10"]
Статья забавная, в общем. Вроде бы и глубокая, а низлежащих механизмов жс-а не затронуто ваще ни разу.
Интернет-магазин можно сделать практически «на коленке» — сейчас есть сервисы, которые обеспечивают складирование, доставку, (вроде даже) закупку — при желании всем можно управлять с ноутбука из любой точки мира. Главное угадать с тем, что продавать.
На самом деле давно уже хочу что-то такое устроить сам, даже в качестве эксперимента, только опять же — сам не знаю, что перепродать такое) в жизни не был коммерсантом.
На самом деле угадали с версией 2 и 3. Как мне товарищи объяснили — работа состоит в поддержке приложений для каких-то недоустройств — например, чудо-машина, которая была предоставлена заказчиком, потому что он смог ее добыть по дешевке, и на ней крутится нетскейп на криворукой сборке дремучего линукса с кривыми интерфейсами, и эти товарищи мейнтейнят пять лет как веб-приложение, которое разрабатывалось в адской спешке, и теперь им постоянно выдвигают новые требования, а времени хотя бы причесать все это нет. До сих пор помню фразу: «Ну вы же понимаете, бизнес требует».
При этом небольшие части этого тестового я встречал где-то еще, судя по всему — его сделали копипастой.
Да если бы перфекционизм… Просто «я пишу как м*%№к». Ошибки, которые могут привести к утечкам памяти, устаревшие методы, которые вообще-то заменены на нормальные лет пять как, создание массивов и объектов через раз через конструктор, неочевидные конструкции, избыточное усложнение, возможность бесконечных циклов. Все те вещи, которые через месяц разработки тебе же самому аукаются так, что если даже не приходится это чинить — скорость разработки падает раза в два.
Про
> Периодически опрашиваем актор — получаем копию его текущего state и передаём в react который рисует пользователю страничку
Не кажется ли, что реактивный подход был бы лучше?
Ну, в половине примеров были сделаны ошибки, которые в доброй половине стайлгайдов по джаваскрипту описаны как «Никогда так не делайте, б*?%ть!».
Сходу все детали не вспомню, это год назад было.
Я сам время от времени провожу собеседования — нормальный технический интервьюер при виде вот такого вот этогосамого за голову схватится, он не даст такие вопросы, ему стыдно должно от этого теста стать, я надеюсь.
>> а вы точно хотите на +0 == -0 получать true?
> да :)
Это ваше дело, я просто уточнил, как я и писал. Кстати, == по перфомансу еще и медленнее чем ===
> В моём понимании [head, tail...] — это просто список, а не объект и я никогда не переопределю для него поле length, в моём понимании length тут вообще не поле а метод (хотя судя по тому как он «вызывается» — это не так)
> {key: value} — для меня не объект а просто map, хэш-таблица с парами key — value где key и value — любые js-данные, и поэтому я никогда не буду что-то там делать с прототипами
Вы же планируете работать c DOM API? или Node.js APIs? Или вы делаете чистые функции на JS просто так? Все куда более неоднозначно, чем кажется.
if type_a == type_b
switch type_a
when "[object Undefined]" then a == b #можно сразу возвращать true
when "[object Boolean]" then a == b
when "[object Number]" then a == b # а вы точно хотите на +0 == -0 получать true? это не сарказм, это кривая система неточного равенства.
when "[object String]" then a == b
when "[object Function]" then a.toString() == b.toString() #не учитывается возможность существования функторов; не учитывается возможность оверлоада .toString, не учитываются нативные и binded-функции, которые возвращают function () { [native code] }
when "[object Null]" then a == b #можно сразу возвращать true
when "[object Array]" #не сравниваете свойства у массива. Да, в JS массив тоже объект и может иметь свойства.
len_a = a.length
len_b = b.length
if len_a == len_b
[0..len_a].every (n) -> equal(a[n], b[n])
else
false
when "[object Object]"
keys_a = Object.keys(a).sort() #не учитывается возможность существования defined Properties, сравнение прототипов
keys_b = Object.keys(b).sort()
if equal(keys_a, keys_b)
keys_a.every (k) -> equal(a[k], b[k])
else
false
Не пишите на «чисто функциональном» стиле на JS. Он не предназначен для этого, вы не сможете получить именно то, чего хотите, без иммутабельности.
бывает и хуже. Был в одном петербуржском интеграторе, что на Лесной, на собеседовании, дали листочек какой-то с вопросами про джаваскрипт. 22 вопроса в духе «взгляните на код, как улучшить/починить». Не ответил верно ни на один. Банально не было места — все остававшееся (да, его было немного) белое пространство было исписано текстами в духе «за такие строки в приличном месте руки ломают». Думаю, я не один такой товарищ был, который после тестового понял, насколько отвратителен рабочий процесс и в общем-то на интервью остался, конечно, но просто из интереса, посмотреть, кто ж эти идиоты, которые такие вопросы написали.
а я и не говорю, что они идеальны, я говорю что они работают себе и работают. Нужно другое поведение, другой инструментарий — делается другая тулза. Не зря ж есть и sed, и awk, и еще куча всяких удовольствий жизни. Когда «разработчик осознает свои ошибки» он делает новый инструмент, а не ломает старый, а все кто хотят из этих мелких кирпичиков собирают что им надо. Я именно об этом говорю. Просто, как я и писал, фреймворки имеют, гхм, склонность терять совместимость с старыми интерфейсами.
Просто подтекст немного другой. И примешивается, к сожалению, культурный контекст.
Увы, для нас такая вещь — «Шубы! Распродажа! Цены — просто сказка!» — вполне себе реальность, и добавляет приторность.
Дополнительно — определенный артикль The подсознательно добавляет «серьезности». Поиграйте на языке — A tale и The tale. Почувствуйте, как «Зэ» как якорем цепляется за мыслеформы и вырисовывает последующий рисунок звуков.
Звуки очень сильно влияют на эмоциональность, в The Tale можно услышать явные «Зет» и «Эл» — Зет-эйл. Это как высокие и нижние частоты: Зет рисует детали (минорный, высокий, «острый», но тяжелый тон), Эл создает фон (мягкий, фоновый, реверберирующий). В «Сказка» — шипящее Ск и ноюще-зудящее ЗЗЗЗк. Раньше при произношении был акцент на двух Кааааа — «Папа, расскажи скааааазкуууу», и зк проглатывалась, но орущая реклама, которая выкручивает высокие частоты погромче, вкупе с дряными колонками «заточили» в нашем восприятии это ЗЗЗЗк, которое жутко раздражает.
Красивым переводом было бы «Легенда», но это название уже занято. Смотрите, тут есть отличные акценты-звуки — вступительный Ль дает отличный фон, а немного зудящий Н отлично «проглатывается» идущим за ним Д. Нд — чуть-чуть прозвучало ноющего и тут же пропало.
Но согласитесь, Легенда — отлично звучит. Можно другие варианты взять, например, «Эпос», который тоже неплохо звучит.
Но тут надо смотреть сочетание звучания названия и содержимого.
Если что — я не специалист, просто увлекаюсь вот всем этим.
Винстон плох тем, что смешивает собственно логгинг и вывод (читай, транспорты винстона). Пока ты делаешь приложение на ноде — да, винстон это круто, удобно, чувствуешь себя хипстером. Когда приходишь в более-менее серьезный проект (а я последний год кручусь в той или иной степени в энтерпрайз-левел проектах) — там стек из джавы, сей, руби и нода там появилась порой по очень странным причинам. И крутится все это на двадцати энвайроментах с разной степенью ограничений безопасности. И все логи сыпятся в какой-нибудь elasticsearch или splunk, из них всех надо вытаскивать данные… И заморачиваться с транспортами под каждый энв в условиях такого зоопарка — гемморой. Проще переложить эту работу на админов и следовать соглашению — приложение пишет в STDOUT, а окружение дальше само занимается вопросом логов.
Ах, если бы это были единственные банки, в которых у меня карточки… у меня половины российских банков пластик уже есть, кажется. Надо будет как-нибудь избавиться. Или наоборот, полный набор собрать.
А вообще — половина пунктов от, пожалуй, непонимания.
Тут — разработчики изначальной спецификации не подумали о том, что разработчики будут так делать.
Сейчас это используется примерно так:
Подчеркивания позволяют повысить читаемость — проще увидеть количество аргументов, которые пропущены.
Ломать обратную совместимость в случае с жс — очень плохая идея, поэтому ввели специальный режим strict.
Все верно. В JS есть два типа декларирования переменной: variable (динамический тип) и function. Оба объявления hoist-ятся наверх в первом проходе компилятора (когда объявляются переменные). Function не может быть undefined, поэтому она сразу же регистрируется.
Думаю, так будет понятнее:
превращается за счет hoist в
Бред. Так никогда не писали.
Начнем с того, что нам нужно узнать, объявлена ли переменная, чтобы с ней можно было работать. В функциях нам это не надо, потому что мы сами их и объявляем, а если и надо — можно воспользоваться блоком try-catch, это крайне редкий кейс.
Если мы работаем в глобальном пространстве — нужно пользоваться 'Symbol' in global<window, например> или .hasOwnProperty()
Typeof дает возможность быстро провериться, но его использование почти всегда скорее мешает, его нужно использовать в двух случаях:
1. определение типа для простых типов (для создания функций с несколькими интерфейсами)
2. быстрая проверка типа объекта при создании API: a instanceof Object не работает, если a взят из айфрейма.
С массивами все тоже очень забавно. Давайте-ка я попробую объяснить, как оно работает.
Статья забавная, в общем. Вроде бы и глубокая, а низлежащих механизмов жс-а не затронуто ваще ни разу.
На самом деле давно уже хочу что-то такое устроить сам, даже в качестве эксперимента, только опять же — сам не знаю, что перепродать такое) в жизни не был коммерсантом.
При этом небольшие части этого тестового я встречал где-то еще, судя по всему — его сделали копипастой.
Про
> Периодически опрашиваем актор — получаем копию его текущего state и передаём в react который рисует пользователю страничку
Не кажется ли, что реактивный подход был бы лучше?
Сходу все детали не вспомню, это год назад было.
Я сам время от времени провожу собеседования — нормальный технический интервьюер при виде вот такого вот этогосамого за голову схватится, он не даст такие вопросы, ему стыдно должно от этого теста стать, я надеюсь.
> да :)
Это ваше дело, я просто уточнил, как я и писал. Кстати, == по перфомансу еще и медленнее чем ===
> В моём понимании [head, tail...] — это просто список, а не объект и я никогда не переопределю для него поле length, в моём понимании length тут вообще не поле а метод (хотя судя по тому как он «вызывается» — это не так)
> {key: value} — для меня не объект а просто map, хэш-таблица с парами key — value где key и value — любые js-данные, и поэтому я никогда не буду что-то там делать с прототипами
Вы же планируете работать c DOM API? или Node.js APIs? Или вы делаете чистые функции на JS просто так? Все куда более неоднозначно, чем кажется.
Не пишите на «чисто функциональном» стиле на JS. Он не предназначен для этого, вы не сможете получить именно то, чего хотите, без иммутабельности.
Увы, для нас такая вещь — «Шубы! Распродажа! Цены — просто сказка!» — вполне себе реальность, и добавляет приторность.
Дополнительно — определенный артикль The подсознательно добавляет «серьезности». Поиграйте на языке — A tale и The tale. Почувствуйте, как «Зэ» как якорем цепляется за мыслеформы и вырисовывает последующий рисунок звуков.
Звуки очень сильно влияют на эмоциональность, в The Tale можно услышать явные «Зет» и «Эл» — Зет-эйл. Это как высокие и нижние частоты: Зет рисует детали (минорный, высокий, «острый», но тяжелый тон), Эл создает фон (мягкий, фоновый, реверберирующий). В «Сказка» — шипящее Ск и ноюще-зудящее ЗЗЗЗк. Раньше при произношении был акцент на двух Кааааа — «Папа, расскажи скааааазкуууу», и зк проглатывалась, но орущая реклама, которая выкручивает высокие частоты погромче, вкупе с дряными колонками «заточили» в нашем восприятии это ЗЗЗЗк, которое жутко раздражает.
Красивым переводом было бы «Легенда», но это название уже занято. Смотрите, тут есть отличные акценты-звуки — вступительный Ль дает отличный фон, а немного зудящий Н отлично «проглатывается» идущим за ним Д. Нд — чуть-чуть прозвучало ноющего и тут же пропало.
Но согласитесь, Легенда — отлично звучит. Можно другие варианты взять, например, «Эпос», который тоже неплохо звучит.
Но тут надо смотреть сочетание звучания названия и содержимого.
Если что — я не специалист, просто увлекаюсь вот всем этим.