для начала - все ивенты которые вы навешиваете надо убирать потом или сделать так чтобы это происходило только один раз. Лаги у вас вряд ли от того что 20 кнопок, если все нормально то лаги должны начинаться где-то на 500-1000 кнопок.
Ничего не понял, но
- "экспортировать" что-то в глобальную область видимости - плохая практика, надо вескую причину чтобы это делать
- пишите по простому - без 'module'
- настройте вебпак так чтобы он компилировал и собирал вам ts файлы. компилировать их отдельно и собирать отдельно не надо. как это сделать описано тут https://github.com/TypeStrong/ts-loader
Если вы уверены фейсбук за вами настолько следит и эту ошибку вам выдает в качестве предупреждения, то лучше даже и не думать ничего лишнего при открытой вкладке. Мало ли.
Актуален для чего? для задачи которую он призван решить - наверное актуален.
Насчет никто не реализовал - тонкости реализации это одно, а решаемая в целом задача это другое.
Так-то реал-таймовое совместное редактирование документов делали уже много кто и некоторые даже успешно это развили и продали за много денег.
А сделать это же самое именно таким вот способом - ну, можно наверное и так.
Слишком узкая задача чтобы библиотека была прямо супер популярная и все про нее знали. В целом такой функционал мало кому нужен.
Диаграммы подобные на тому что на вашем скриншоте рисуются руками, для этого есть библиотеки которые крайне гибкие и берут на себя всю муторную работу по обработке данных и рендерингу, на основе которых можно создать подобное.
Когда-то самой крутой из таких была https://d3js.org/
как сейчас - не знаю.
скорость работы в данном случае зависит напрямую от количества элементов в массиве items,
C чего вы взяли? какая разница в скорости будет если length = 1 и length = 1000000?
Алгоритм в примере просто берет значение из переменной Length и возвращает его.
"Взять значение переменной" всегда одно и то же действие. И сложность этого действия - одинаковая.
со 100%. Не слушайте этих яваскрипт-программистов, которые jQuery не осилили и говорят что надо писать все на JavaScript, вы можете быть нормальным востребованным jQuery-программистом и все что хотите писать на jQuery.
достаньте его из электрона и положите на вебсайт.
или - какой-то нужный функционал вынесите на сервер и там проверяйте подписку.
Если оно полностью автономно работает у пользователя на компе то варианты защиты только юридические.
yarn ом вы ничего не собираете - вы просто выполняете скрипт start из package.json.
загляните туда для начала и посмотрите чем вы действительно собираете. Скорее всего это какой-нибудь бабель или вебпак с бабелем. Хотя для flow может что-то еще не использовал не знаю.
а потом для этого загуглите как включить флаг decorators-legacy.
потому что вы нигде сам passport не вызвали.
добавьте
app.use(passport.initialize())
и passport.authentificate в роуты. В общем - для начала сделайте как в документации.
никак, порядок ключей в объекте вообще не гарантирован, зависит от реализации в движке и завтра 5 может начитать добавляться после 10, а 10 вставать перед 5. или ваш код вдруг будет запущен на не v8 а каком-нибудь другом движке где все не так.
Хотите гарантированно перебрать ключи в порядке добавления - используйте массив или еще что-то подходящее.
если где-то сохранится ссылка на один из этих объектов то delete не поможет.
даже если её и нет - то при delete память не освободится сразу, а в какой-то рандомный момент времени
В целом - вы не контролируете распределение памяти и единственный способ точно убедиться что объект удален - это попрофилировать руками, запуская сборщик мусора и убедившись что объекты этой либы реально удаляются.
В целом нормально, аргументы функции - такие же локальные переменные, как и явно объявленные.
Другой вопрос что вы можете привыкнуть, ненароком отхватить там объект и поменять что-то там где вообще не надо.
Поэтому лучше в более- менее сложном коде так не делать, но в таких примитивных примерах как ваши - введение дополнительной переменной никакой пользы не приносит, только читаемость ухудшает. В них не надо.
