Это нисколько не прояснило, у вас стало "например, какой-то сайт".
Название сервиса вообще не влияет на то как хранить данные.
Чтобы понять вам нужно ответить на вопросы:
- какие именно данные
- как они структурированы
- какие объемы
- какие требования по нагрузке (чтение/запись), как распределяется нагрузка по разным типам операций.
- какие требования по отказоустойчивости
- какие требования по скорости доступа и географическому расположению
- экономические соображения
Это то что сразу пришло в голову.
Вообще, простое правило - если вы не знаете какая вам нужна БД, значит вам скорее всего все равно - берите то что попадется под руку - результат с большой вероятностью будет одинаковый.
голова змейки - первый элемент массива. остальные элементы, хвост.
допустим змейке надо передвинуться вправо на 1 клетку - вы первый элемент массива перемещаете (left+1), остальные просто двигаются так как я описал - второй встает на место первого, третий на место второго и так далее. (копируете left и top).
Нарисуйте на бумажке каждый шаг и посмотрите как меняется массив, если вам так будет проще.
Вопрос то в чем? сформулируйте его где-нибудь. А то у вас там от вопроса только знак вопроса.
Ну и вы показываете картинку - с нее можно только понять что у вас что-то не правильно - это вы и так знаете. Вставляйте свой кодпен.
Flakelf, потому что "arrays that grow without bound are a MongoDB anti-pattern." До тех пор пока вы не будете обладать достаточным опытом лучше следовать best practices - уменьшите количество потенциальных проблем.
Ну и то что выше написали.
Автор, вам просто нужно поработать с кем-то более опытным. Гит позволяет сделать как угодно, а как именно делать - зависит от того как процессы разработки выстроены. По каким условиям ветки создаются, когда их надо мержить, будет ли ребейз, в каком виде лучше мастер держать, будут ли релизные ветки, работа с код ревью мержреквестами, или нет, хочется ли всю вообще историю держать в общем репозитории или там нафиг ваши 100500 фича-веток никому не нужны, и так далее.
Вот в это вникните, а как под это дело ветки крутить в гите - уже дело техники, там по сути несколько команд нужно.
Если вы за оффлайн работу переживаете - не переживайте, по большому счету никакой разницы нет, есть у вас интернет или нет. Если нет интернета - это все равно что он есть но в этот момент никто с кодом не работает кроме вас.
Артем, Тут уж вы сами выбираете нужный уровень "жести" исходя из задачи и количества ресурсов которые можно на это потратить. Написать свою обвязку к mongo драйверу чтобы она работала быстрее/была меньше это довольно лайтовый вариант, ничего сложного.
Артем, например - форкнуть и поменять как надо. Или взять нативный драйвер и написать вокруг него свою спец объвязку, с минимальным оверхедом и memory footprint, если это для вас настолько важно.
Если не настолько важно - то о чем сыр-бор? расслабьтесь :)
У меня складывается впечатление что вы хотите не потому что есть реальная потребность а "из принципа". Заморочиться чтобы заморочиться - тут вам никто не помешает развлекаться так как заблагорассудится.
Если вы пишете что-то обычное - вебсервис какой-нибудь например с обычным числом запросов, то все эти проблемы перед вами вряд ли стоят - делайте стрелочные функции и не парьтесь. вряд ли вы сможете наделать их столько чтоб сборщик мусора не успел это собрать или чтобы процесс сборки был заметен.
Виталий, это пусть уж автор вопроса решает что он дальше с нодой будет делать. Может она ему для Tessel нужна а тут вы со своим коа. Не заставляйте меня думать что вы вопрос даже не прочитали - там все конкретно и четко сформулировано. Даже жирным текстом есть.
Я вам написал самый простой вариант - менять helper.method. Чтобы он принимал все данные целиком, и с ними вызывал ваш колбек.
Насчет своего мусорщика - если вам нужна будет сложную работу с данными чтобы сделать код максимально оптимизированным - то у вас будет сложная работа с данными. Другой вопрос - нужно ли вам это на самом деле.
Вообще переиспользовать объекты можно по разному - если у них шейп одинаковый, например, сделать пул, оттуда их брать и туда же отдавать. так вы можете их гонять по приложению без пересоздания. Методов много, но если вы хотите пару строчек магических написать и все будет здорово - не получится, было бы просто - все бы так делали.
Артем, нужно менять helper.method. Или же передавать ext где-то еще, может у вас есть какой-то общий объект стейта куда его можно положить.
Если вариантов ext не сильно много и конечное количество, то можно сделать memoization для result - будет столько копий сколько вариантов ext.
Проводить аналогии там где их нет - неблагодарное занятие, лучше просто посмотреть в спеку как оно все называется и как работает :) Это конечно дольше но надежнее для понимания.
По факту - for всегда бегает по итератору, который есть в специальном свойстве любого объекта. Свойство определяется символом Symbol.iterator, Symbol.iterator - это свойство объекта Symbol и именем iterator, в котором лежит Symbol, и потому является с одной стороны глобально уникальным, с другой стороны - глобально доступным. Его туда положили просто для удобства.
Чтобы не надо было на каждый объект писать свой итератор, у объекта Object есть это же свойство, в котором находится стандартный итератор, который просто бежит по свойствам текущего объекта (с учетом дескрипторов объекта и дефолтного поведения for)
Так как Object лежит в конце цепочки прототипов любого объекта - он по умолчанию работает для любого объекта, если только где-то в цепочке не найдется другой итератор сохраненный в этом же свойстве. Если же он есть - то возьмется тот итератор который лежит выше по иерархии (ближе к актуальному объекту по которому итерируем)
Это все работает по стандартной схеме прототипов JS.
Вы можете все это назвать "перегрузкой for", если вам так удобнее, но это просто притягивание за уши знакомых слов. Если вы прочитаете определение "перегрузки" в других языках - не факт что оно подойдет к тому что происходит в JS хотя бы наполовину.
попытается вызывать this.result, а что там у вас будет в this - только helper.method знает. Может быть что угодно вплоть до undefined, на котором все упадет.
Виноват, каюсь. Вы поумничали я потроллил. Ваш ответ слишком далек от того о чем спрашивал автор вопроса, не удержался. Автор спрашивает "как лучше изучать ноду" вы отвечаете "чтобы изучить бек вам надо изучить ноду + еще 100500 вещей"
