Области видимости в JavaScript

[norlin]

К слову, для IIFE рекомендуется помещать "исполняющие" скобки внутрь скобок самого выражения, а не снаружи.

Т.е.

// плохо
(function bar () {
  console.log('in function bar');
})()

// хорошо
(function bar () {
  console.log('in function bar');
}())

Казалось бы, разницы быть не должно, но Кроукфорд рекомендует именно второй вариант.
Вот здесь есть подробный разбор, какие могут возникнуть проблемы в первом случае.

[Dronton2]

Они неправильно рассмотрены. Например, говорится, что область видимости let — блок. А то, что let внутри блока видна только после объявления (в отличие от var) — умалчивается.
Ну, и последний пример, в котором предлагается в цикле использовать IIFE, вместо того, чтобы просто заменить var на let.
Имхо, тем, кто начинает изучать js, полезнее будет прочитать вот это

[vanxant]

А ещё блочная видимость облегчает копипасту.
Типа если мы копируем откуда-то кусок кода с var, и в месте назначения переменная с таким именем уже объявлена, то будут проблемы. А если с let, то всё ок, т.е. может быть три подряд цикла for(let i = 0,...) — хотя название у i одинаковое, это будут три разные переменные.

[RifleR]

Да вроде как рассмотрены. Я вижу их упоминание в статье.

[haldagan]

Извините, если вызвали приступ ностальгии

Ну свинство же — прилагать собственноручно выбранную КДПВ (в оригинальной статье ее нет), а потом еще и извиняться за это.

Тот, кто выбрал картинку, конечно справился с задачей по увеличению количества просмотров, но мне, как фанату серии, было обидно читать очередной переведенный туториал по замыканиям в js, коих и на русском языке в сети хватает.

[Leopotam]

А так? :)

[haldagan]

Но ваше видео

Не относится ни к коммандос, ни к статье.

Меня бы даже заинтересовали статьи к вашим видеороликам, если бы не то, что я увидел: вычисления области видимости упрощены до геометрии на плоскости: высота препятствия учитывается только как z-index: ноль дает полную видимость, 1 — «частичную», 2 — закрывает обзор.

оффтоп

Если у Вас вдруг завалялись ссылки на статьи/ролики по тому же самому, но с «реальным 3д для top-down» с хорошей производительностью (без рейкастинга) — буду благодарен.

[Leopotam]

Оффтоп

вычисления области видимости упрощены до геометрии на плоскости: высота препятствия учитывается только как z-index: ноль дает полную видимость, 1 — «частичную», 2 — закрывает обзор.

Так командосы полностью 2д были — там плоскость, разбитая на сектора по типу поверхности / между препятствиями + 3д человечки (начиная вроде со второй части).
«Внутрянка» в виде 3д — это по сути то же самое 2д на плоскости с 3д стенками. Где они пытались сделать несколько уровней по вертикали (часовые на вышках) — все сильно глючило визуально в плане поля видимости. Такие же глюки были с движущимися объектами (хорошо заметно на первой дневной миссии в доках, где нужно проникнуть на базу и угнать подлодку — машина офицера «просвечивается» взглядом противника визуально, но на практике это не так, они не видят бойцов за ней).

но с «реальным 3д для top-down» с хорошей производительностью

А на видео и есть полное 3д, но с ортогональной-камерой для более удобного обзора поля игроку. Ну и у меня не рейкастинг — это все делается на гпу путем растягивания теневой геометрии от точки обзора:
1. В шейдер передается точка обзора.
2. Рендерится геометрия полной «тени» (может быть любой формы и детализации, в видео это квадрат) с записью в Stencil буфер ( пишется значение 2 там, где стоит 0) и без записи в Z / Color.
3. Рендерится геометрия «полутени» аналогичным способом (в Stencil пишется 1 туда где было записано 0). На этот момент на экране этой «теневой» геометрии нет, она только заполнила Stencil.
4. Рендерится видимая геометрия для «полностью видимой» зоны (рендер производится только туда, где в Stencil буфере 0).
5. Рендерится видимая геометрия для «частично видимой» зоны (где в Stencil буфере 1).

Положительные моменты: нулевая нагрузка на cpu и идеально правильная геометрия (с учетом точности «теневой» геометрии, конечно).
Отрицательные моменты: Нагрузка на gpu, увеличение филрейта, но т.к. оно достаточно хорошо фильтруется условиями + в шейдерах можно учитывать общее направление взгляда для уменьшения площади перерисовываемых областей — вполне себе вариант. На мобилках работает хорошо, меня устраивает.

[morikvendy]

Вот этот пример выглядит как-то очень коряво:
for (var i = 0; i < 5; i++) {
(function logIndex(index) {
setTimeout(function () {
console.log('index: ' + index);
}, 1000);
})(i)
}

учитывая, что можно сделать значительно проще:
for (var i = 0; i < 5; i++) {
setTimeout(function (index) {
console.log('index: ' + index);
}, 1000, i);
}

А так, статья для новичков очень неплоха, на мой взгляд)

[TheShock]

Если цель сделать короче и изящнее, то можно так:

for (var i = 0; i < 5; i++) {
  setTimeout(console.log.bind(console, 'index: ' + i), 1000);
}

[bostan]

А можно просто использовать let вместо var

[TheShock]

Обычно хороший код декомпозируется, потому в качестве колбека передается ссылка на метод или функцию и bind чаще всего использовать легче и лучше для кода, чем даже let.

Да и в IE только начиная с 11-й поддерживается, если верить mdn.

[AxisPod]

А в IE9 не заработает :-D

[EvilGen]

От подсветки кода глаза вытекли… Я очкарик, а контраст потеряли нафиг…