Кирилл Халитов , вы серьезно сомневаетесь в компетенции людей пишущих js движки, а по совместительству разрабатывающих спецификацию ECMA? Подобная концепция, помимо всего прочего, позволяет быть реализованной с использованием уже существующих элементов языка, оставляя реализацию спорных моментов на откуп js программисту. Попытка реализовать настоящие приватные поля привела бы к значительной переработке парсеров и оптимизаторов использующихся в движках, а так же увела бы ECMA в степь ей не присущую - классы к которым все привыкли в C++. Хотите настоящие приватные поля - идите в C++, иначе скорректируйте немного мышление.
Мне кажется вы пытаетесь смешать логику с представлением - в момент обновления представления, модель уже должна быть к этому готова, вы же хотите обновлять модель в момент компиляции шаблона. Конечно ваша цель достижима (например с помощью промайзов, которые упомянули выше). Но когда вы допишете подобную реализацию, то обнаружите что асинхронщина размазана по файлам шаблонов и не поддается никакому пониманию. В сравнении с этим обычный коллбек хелл покажется вам цветочками.
mayorovp, согласен с вами. Видимо вчера после пары тестов, я лишний раз переопределил null прототип. В реальной ситуации лучше конечно и для window и для Object искать null прототип в цикле, а не надеяться на точный путь до него.
loopback.io
По поводу вашего подхода, первое что мне видится тяжелым для восприятия, это ваш способ хранения моделей и контроллеров - спустя какое-то время это превратится в зоопарк файлов, и операция "найти нужный контроллер -> перейти на уровень выше -> перейти в модели -> найти нужную модель" будет занимать у вас непростительно много времени. Так же подобное расположение может привести к нежелательному нарушению инкапсуляции (когда все контроллеры находятся в одной папке, совесть не мучает ссылаться из одного контроллера на другой).
Я бы предложил относиться к каждой rest команде как к отдельному модулю:
route
- index.js
- test1
-- model.js
-- controller.js
-- package.json (при желании)
-- любой другой файл, который может потребоваться именно этой команде
- test2
-- model.js
-- controller.js
- любой другой файл, который может потребоваться нескольким командам
По поводу сокращения времени - для меня это очень сомнительно - из видеоуроков я могу вспомнить только презентацию "Как отлаживать NodeJS с помощью Node Inspector" от StrongLoop, которую я посмотрел исключительно чтобы знать можно ли на нее ссылаться в каких-нибудь ответах. Так вот мне легче за 15 минут освоить всю документацию Node Inspector, чем 40 минут слушать и смотреть картинки, а ведь еще надо ставить на паузу и пытаться повторить.
Возможно меня интересует этап не начала изучения технологии, а тот момент, когда базис уже есть, например я знаю js и мне не понадобилось смотреть видео, чтобы разобраться как работать с D3.js
Существует ли причина смотреть уроки по D3 если уже отлично знаеiь js?
ALLEROY 88 , ну что вы скромничаете? Давайте ваше фирменное "Сверстайте кому не лень", как в предыдущих вопросах, так глядишь с миру по нитке к концу месяца сайт закончите.
Это вопрос к тому, что вам сказали ниже "если вы не хотите чтобы пустые значения перекрывали значения прототипа - объявляйте свойство только если это необходимо"
К слову о стактрейсах. Как разработчик node-inspector могу вам заявить, что ближе к лету в node сообществе появится такая же возможность отлаживать асинхронные стактрейсы, как и на фронтенде
