Насколько она актуальна?

С новыми асинк авейтами

Или она про другое?

Она неактуальна

Забудьте её

ох вы про этот async

как страшный сон

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Generator_comprehensions что это? этого ведь нет в стандарте?

а, это вообще из 1.8

я загонялся мне было интересно :(

и что удалось интересного узнать из исходников v8?

и что удалось интересного узнать из исходников v8?

Про разные режимы словарей и внутренние методы. Работа промисов на тот момент

Ну, некоторые штуки вообще полезно знать. В исходники для этого, правда, лезть необязательно.

http://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism.html полезная.

Например.

> @ChALkeR В исходники для этого, правда, лезть необязательно. просто неэффективно

может быть разве что местами с комментариями, которых немного

Надо репозиторий на гитхабе под нацпол завести.

Например,этот стартер? https://github.com/kriasoft/react-starter-kit

Забей на киты, они все не очень

Забей на киты, они все не очень

А что тогда?) Просто в доках тыкать в модули и смотреть описания?)

А что тогда?) Просто в доках тыкать в модули и смотреть описания?)

Для нормального todo app на реакте и ноде нужен rest api, его в китах я не наблюдал Я тебе советую собрать свой кит под твои задачи из множества чужих

Если я передаю экземпляр одного класса в качестве аргумента конструктора второго класса и сохраняю его в виде свойства экземпляра второго, это будет считаться реализацией dependency injection?

Ну с какой то стороны да

Если я передаю экземпляр одного класса в качестве аргумента конструктора второго класса и сохраняю его в виде свойства экземпляра второго, это будет считаться реализацией dependency injection?

Ой)

> @bigslycat это будет считаться реализацией dependency injection А какая разница?

Я кстати так и делал, когда надо было управлять зависимостями

Ну, на самом деле, меня волнует не столько соответствие паттернам, сколько реальная несвязанность кода.

Ну, на самом деле, меня волнует не столько соответствие паттернам, сколько реальная несвязанность кода.

А в чём несвязанность?

А в чём несвязанность?

Возможность взять и перенести какой-либо компонент приложения.

Ну да, это и есть dependency injection

Возможность взять и перенести какой-либо компонент приложения.

Это не всегда цель, но показатель. Если я добиваюсь этого условия, то мне потом намного проще поддерживать приложение.

Я просто узнал о термине и решил ознакомиться с паттернами вокруг него — вдруг я делаю что-то не так, или упустил какой-то интересный подход.

Возможность взять и перенести какой-либо компонент приложения.

Ну реализуй это как-то аккуратно) По моему сам по себе такой метод это не проблема

Много бойлерплейта, но в целом хорошо

Тестировать становится все очень просто

А ещё. Парится ли кто-нибудь о реализации приватных методов/свойств?

нет

Нормальная ли практика: 1. Большое количество методов в классе? 2. Вынос методов в отдельные файлы с последующим подключением к MyClass.prototype?

Без второго хотелось бы обойтись. Просто выделяй смежную, но отдельную сущность

Я бы не стал так делать. По мне - неудобно поддерживать, неявно.

+ допустим ты захочешь перейти на es6 классы, это дополнительное усложнение для перехода

Эм... Ничего сложного.

Нуу хз

class MyClass {} MyClass.prototype.myMethod = ...

Неа

вопрос, а зачем так делать? Даже с точки зрения работы с кодом - чтобы посмотреть реализацию нужно все время скакать по файлам.

Это не ES6 классы

Неа

Работает.

Эм... ?

И это и плохо

это может работать в зависимости от реализации траншпилера

Это не "переезд" тогда вообще)

Как реализовывал через прототипы, так и продолжаешь)

в голове вертится вопрос "а зачем так делать?"

++

А, ну, в общем, да.

Это работает, но это не повод

=)

Писать классы меньше, но больше сущностей?

Static методы

на TS ты тоже без объединения в файл переехать не сможет нормально, например

А что статик методы?

Фаулер завещал больше маленьких сущностей

=)

И больше сущностей, да, почему нет

А что статик методы?

Считай то, что ты и делал через прототипы

Один метод на весь класс

class Foo { static staticMethod() {.. } private method() { Foo.staticMethod(); .. }

ERROR: S client not available

кстати никто не смотрел, статические методы дают прирост производительности?

я просто не смотрел как они траншпилятся в том же TS..

кстати никто не смотрел, статические методы дают прирост производительности?

Разницы по идее никакой, если сравнивать с отдельно лежащим методом

Естественно, если в каждом экземпляре по методу, то памяти будет есть больше

в каком случае будет в каждом экземпляре по методу?

Ну когда не static

Неа.

ну тогда же он берет по ссылке из прототипа всегда

Прототипы остаются прототипами.

А контекст?

Классы — это просто сахар же.

это задача JS уже

Да всё так же, как с прототипами.

или я что-то не знаю о JS? oO

По сути, механизм не поменялся.

или я что-то не знаю о JS? oO

Всё верно.

Классы — это просто сахар же.

Расскажи это поменявшейся семантике оператора new

давно не игрался с такими вещами но, var foo = function() { console.log(this) }; b = { a: 1, foo: foo }; b.foo()

вернет b

контекст будет всегда объекта от котого ф-я исполняется

без bind

Да

Расскажи это поменявшейся семантике оператора new

Про это не слышал, где глянуть можно?

function Class1() {} Class1.staticMethod = function() {}; Class1.prototype.method = function() {}; class Class2 { static staticMethod() {} method() {} }

Одно и то же.

Кэп ?

> @bigslycat Одно и то же. почти

В чём отличия?

вторая запись мне нравится больше определенно)

Ну, это да.

В чём отличия?

static в прототипе и методы не enumerable

static в прототипе и методы не enumerable

О. Благодарю.