мммммм

ну такое. всё сильно зависит от области расширения

может быть и программное API для плагинов. это самое "неглубокое" внедрение. а можно хоть в ядро их пускать

проще идти от задачи

ну смотря на gajim и qutim, то там расширения всё что угодно делают

в рамках мессенджера естесвенно

в основном с сообщениями конечно взаимодействуют

не берусь утвеждать, но насколько я помню - QIP давал API, через которые можно было регистрировать свои обработчики протоколов, и API для создания всяких GUI в самом мессенджере

программное API имею в виду. export-функции в dll'ках

мммм

ну вообще, идеальная архитектура в таком случае, когда всё что делает ядро - подключает/отключает плагины

и каждый плагин может как подключиться к чъему-то API, так и зарегистрировать своё, с которым могут работать

ну вот, хотелось бы тонкости почитать

чтобы не наступать на грабли

самому тоже теперь интересно стало)

https://github.com/c9/architect

Похоже на то что нужно

моя удочка: [node app plugin system]

но найти сложно

модульная архитектура называется

на самом деле, мало чем отличается от обычной архитектуры node модулей

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

ну вот идея, чтобы пользователи расширения писали

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

не совсем. все таки node модули это другая история. Делать плагины это значит что у тебя есть некая логика и ты ее расширяешь т.е. у тебя где-то есть хэндлеры какие-то или еще штуки которые в коде твоего приложения которые эти плагины подклчают без гемороя

чтобы в настройках\меню новые пункты добавлялись

так ты лучше опенсорс сразу делай

типа логин\пароль

пусть PR присылают

ну так и будет

ну это ты просто шаришь функцию createMenuItem(text, handler) и всё. GUI это ведь по сути тоже отдельный модуль, шарящий какие-то свои возможности в окружение

# С появлением лямбд в js хочется записывать функции выражениями (Expression), а не операторами (Statement) ?: вместо if then else throw(...) через библиотеку, а не throw ... и т.д. или например вместо: .then(val => {const res = fn(val); return check(res) && res}) так: .then(val => okPass(fn(val), check)) где okPass = (v, cond) => cond(v) && v Таким путём например идёт python как вам использование такой функции как okPass, как бы её понятнее называть? Кажется, что было бы круто иметь языковую конструкцию для такого приёма.

# С появлением лямбд в js хочется записывать функции выражениями (Expression), а не операторами (Statement) ?: вместо if then else throw(...) через библиотеку, а не throw ... и т.д. или например вместо: .then(val => {const res = fn(val); return check(res) && res}) так: .then(val => okPass(fn(val), check)) где okPass = (v, cond) => cond(v) && v Таким путём например идёт python как вам использование такой функции как okPass, как бы её понятнее называть? Кажется, что было бы круто иметь языковую конструкцию для такого приёма.

when кверх ногами)

Без data last

data last?

data last?

const selector = P( R.prop('value'), R.when( isArray, R.last ) ) const result = selector ( anyData )

ramda?

Ну)

а что такое P?

Прикольно, кажется, я уже вырос из lodash и готов к рамде)

а что такое P?

R.pipe, их слишком много, чтобы они занимали 6 символов в строчке, уже на автомате так пишется)

столько вокруг Lo миксинов накручиваю

А как вам такая штука? http://npmapi.invntrm.ru это как npm repo %package%, но в омнибоксе браузера и в Alfred (macOS Spotlight like)

Как проверить объект на пустоту?

const info = {} if (info) { // true }

в общем случае — bad practice так делать

_.empty(val)

Object.keys(obj).length — длинно

Проверяет именно на пустоту '' [] {}, но 0 будет давать true

_.empty(val)

lodash не вшили в es6?

:)

либо лаконично, либо нативно

Как проверить объект на пустоту?

Проверяй наличие в нём нужных свойств

Или заведи отдельную переменную-счётчик, например, при добавлении полей инкрементируй

Единственно пустой объект — это Object.create(null)

Или заведи отдельную переменную-счётчик, например, при добавлении полей инкрементируй

Не, это вообще криво

Ибо не прототипов, ни свойств

Единственно пустой объект — это Object.create(null)

+

Ни*

ну или Map юзай

я бы просто функцию вверху объявил: const empty = obj => Boolean(Object.keys(obj).length)

@ZeroBias А Ramda умеет так же как и Lodash превращать цепочку map().map()... в один внутренний цикл вместо N циклов?

Как там вообще с производительностью?

Как удалить элемент из объекта?

ERROR: S client not available

delete obj.prop но это bad practice обычно ибо портит внутренние jit оптимизации и просаживает немного скорость альтернатива: obj.prop = undefined

@ZeroBias А Ramda умеет так же как и Lodash превращать цепочку map().map()... в один внутренний цикл вместо N циклов?

Может, там так работает чуть ли не половина библиотеки) Производительность оценивал, когда делал на ней мини-интерпретатор, ~20 тысяч вызовов всей библиотеки спокойно умещались в пол секунды работы программы

.

какую IDE используете для ноды? NetBeans с плагином как?

нет конечно

NetBeans уже стал историей webstorm, sublime, atom, vim

vscode)

вим сомсем хардкор

не могу в вим

> @mxtnr ибо портит внутренние jit оптимизации и просаживает немного скорость Неправда же

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

delete как раз переводит объект в режим словаря

что и нужно, если хочешь использовать объект как словарь

в эмбере была даже такая оптимизация: добавляли свойство и сразу удаляли

хех, прикольно, чтобы не конвертить, когда уже много даннных будет запомню этот приём пожалуй.

именно

А сейчас нас разве не спасёт Map?

По идее Object.create(null) всегда в режим словаря

т.е. не смотря на то что typeof null === 'object', prototype объекта не отнаследуется?

null это не объект и протипа у него нет

это просто странное поведение typeof

да, знаем-с) Object.create(null).__proto__ // undefined Object.create({}).__proto__ // Object {}

@ZeroBias Читаю про Ramda. Как наиболее идеоматично модифицировать такой пример: var amtAdd1Mod7 = R.compose(R.moduloBy(7), R.add(1), R.prop('amount')); Чтобы значение не распаковывалось из объекта? Внутри распаковать, произвести манипуляции и вернуть в прежней обёртке с другими нетронутыми элементами. Забыл опять как это в функциональной теории назывется Сейчас работает так amtAdd1Mod7({amount: 17}); // => 4 а надо так: amtAdd1Mod7({amount: 17}); // => {amount:4}

assoc — это если не используя сразу перезаписать

а с использованием?

вот с такой примерно сигнатурой String → (a→a) → {k: v} → {k: v}

> @mxtnr Забыл опять как это в функциональной теории назывется Никак, там так нельзя

Ну в рамде все объекты иммутабельные, подгоняются под теорию)

Почему нельзя? Я же не модифицирую ничего, новый контейнер возвращаю Который клон введённого с изменённым полем

А без этого ФП не работает

а с использованием?

Два варианта, через линзы и через evolve