Исследовал множество инструментов для тестирования на nodejs и выбрал nightwatchjs. Много лет применял nightwatchjs в работе в разных компаниях, но на текущий день его сложно рекомендовать новым людям из-за отсутствия поддержки async/await из коробки, которые помогают писать тест как «синхронный» код, делая тесты лаконичнее в синтаксисе и проще для восприятия и понимания.
В эпоху ES6 стоит 2 раза подумать об этом, прежде чем делать свой выбор в пользу того или иного инструмента.
На самом деле это паттерн модуль + паттерн открытия модуля.
Такой подход позволяет работать и с this (он есть в замыкании, просто в своем коде вы его не применяете).
Такой подход хорош для эмуляции защищенных свойств и методов. Но отсутсвие вынести общее поведение в прототип приводит к тому, что каждый инстанс расходует больше памяти, нежели работа с цепочкой прототипов.
Еще в примере кода возвращается инстанс, лучше возвращать конструктор. Чтобы можно было создать свой инстанс, если потребуется более 1 инстанса модуля и провайдить настройки в конструктор, если модуль настраиваемый.
Паттерн «модуль» и паттерн «открытия модуля» однозначно стоит применять. Но на мой взгляд нужно возвращать не инстанс модуля, а конструктор модуля. Это позволит из внешнего кода создать инстанс модуля самостоятельно и пробросить в функцию конструктор модуля нужные параметры или зависимости. Сконфигурировать модуль под место его работы.
Таким образом можно использовать несколько экземпляров одного модуля на странице и каждый настроить на свой вкус.
odm.findAllSync — не используется, это для примера чисто. Что асинхронный вызов с yield с точки зрения кода можно сопоставить с синхронным вызовом. Под "синхронным flow" я имею ввиду не вызов синхронных функций, а стиль работы с кодом, как с синхронным.
Так с промисами работа получается с точки зрения кода почти синхронной:
var posts = yield odm.findAllAsync(); // findAllAsync return Promise
var posts2 = odm.findAllSync();
Вот что я имел ввиду, мы работаем не с колбеками, или ветками .then(), а из асинхронной функции получаем результат, как бы синхронно с точки зрения скрипта.
Как только я стал писать на koa через функции-геренаторы, то отношение к программированию на nodejs улучшилось в разы. Код пишется так, как-будто все функции работают синхронно. А с учетом того, что на многие пакеты есть promise обертки, которые позволяют работать с кодом также как с синхронным (в koa это сопрограммы кажется называется, но могу ошибаться), программировать на nodejs теперь намного проще.
Для своих классов можно использовать паттерн модуля и паттерн открытия модуля, когда функция конструктор возвращает явно объект. Который является по сути маппингом на методы и свойства замыкания, чтобы сделать из публичными.
Вариант декодера стороннего пока тоже рассматриваю. Работая с сервисом, который передает несколько петабайт изображений в месяц, прирост даже в 10% может быть ощутим.
Js декодер на стороне сайта/приложения, не должен принести проблем пользователю, это же не плагин какой-то ему ставить самому в систему или браузер.
Сравнивал webp с bpg с пол года назад, в большинстве случаев bpg картинка занимала меньше места, чем webp c таким же качеством на глаз :)
Хочется верить, что формат получить широкое распространение и браузеры в будущем будут его поддерживать.
>>«Поскольку функция конструктор возвращает простой объект, не работает instanceof;»
Никто не мешает создаваемому объекту указать явно прототип Animal, вместо Object (создаем через Object.create, а не литерал). Тогда и instanceof будет работать корректно через цепочку прототипов и конструктор будет определяться верно у объекта.
В эпоху ES6 стоит 2 раза подумать об этом, прежде чем делать свой выбор в пользу того или иного инструмента.
Такой подход позволяет работать и с this (он есть в замыкании, просто в своем коде вы его не применяете).
Такой подход хорош для эмуляции защищенных свойств и методов. Но отсутсвие вынести общее поведение в прототип приводит к тому, что каждый инстанс расходует больше памяти, нежели работа с цепочкой прототипов.
Еще в примере кода возвращается инстанс, лучше возвращать конструктор. Чтобы можно было создать свой инстанс, если потребуется более 1 инстанса модуля и провайдить настройки в конструктор, если модуль настраиваемый.
Паттерн «модуль» и паттерн «открытия модуля» однозначно стоит применять. Но на мой взгляд нужно возвращать не инстанс модуля, а конструктор модуля. Это позволит из внешнего кода создать инстанс модуля самостоятельно и пробросить в функцию конструктор модуля нужные параметры или зависимости. Сконфигурировать модуль под место его работы.
Таким образом можно использовать несколько экземпляров одного модуля на странице и каждый настроить на свой вкус.
Львиная доля сложности может уйти и при работе с odm, если изменить flow с асинхронного на синхронный.
Вот что я имел ввиду, мы работаем не с колбеками, или ветками .then(), а из асинхронной функции получаем результат, как бы синхронно с точки зрения скрипта.
Скорее всего есть orm/odm пакеты с промисами.
Может кто-то подсказать где найти обсуждение или rfc сейчас этой фичи?
moikrug.ru/nikolaev29
Js декодер на стороне сайта/приложения, не должен принести проблем пользователю, это же не плагин какой-то ему ставить самому в систему или браузер.
Хочется верить, что формат получить широкое распространение и браузеры в будущем будут его поддерживать.
Никто не мешает создаваемому объекту указать явно прототип Animal, вместо Object (создаем через Object.create, а не литерал). Тогда и instanceof будет работать корректно через цепочку прототипов и конструктор будет определяться верно у объекта.