Let vs const — что использовать?

Всё только начинается)

Array.splice и Array.slice в JavaScript

Array.splice это Array.splice — статический метод класса Array. Если нужно кратко записать метод экземпляра (Array.prototype.splice), то обычно используется запись Array#splice.

Опрос по инструментам фронтенда 2019 — результаты

Секция scripts в package.json.

Оформляйте стили наведения, фокуса и активного состояния по-разному

Зачем вообще показывать состояние фокуса, если пользователь не прикасался к клавише Tab? Это лишняя информация для него. Нужно делать так:
На body висит класс _noFocusHighlight который прячет всё (почти всё, про исключения ниже) отображение фокуса, при нажатии на Tab он снимается и пользователь видит состояние фокуса, раз нажал на Tab — значит оно ему нужно. При любом клике, после которого document.activeElement указывает на body, возвращается класс _noFocusHighlight. Возможны некоторые исключения, например, текстовые поля, состояние фокуса на которых отображается даже если было получено мышкой.
Вот код: тыц.

Ом-ням-ням и валидация данных

Интересная идея с возможностью извлекать статический тип из валидатора. Надо будет попробовать так сделать.

Ом-ням-ням и валидация данных

Реализовал оба варианта. keypath подставляется сам когда есть вложенность. Вместо message можно использовать type, в таком случае сообщение об ошибке будет сформировано с учётом .or:

om(om.custom({ validator, type: 'type1' }).or.custom({ validator, type: 'type2' }), type3);
// бросит TypeError('Expected "type1" or "type2"')

Примеры в сообщении выше тоже рабочие.

Ом-ням-ням и валидация данных

Привет. Можно научить понимать возвращаемую валидатором строку как сообщение об ошибке при неудачной проверке:

om.number.and.custom(value => value > 18 || 'Вы ещё слишком маленький')

Можно в этой строке некоторые простые замены делать, например, {keypath} заменять на место где случилась ошибка.

Ещё вариант — научить .custom() понимать не только функцию, но и объект с функцией и строкой ошибки:

om.number.and.custom({
    validator: value => value > 18,
    message: 'Вы ещё слишком маленький ({keypath})'
});

Если нужно такое, создайте issue чтобы я не забыл. Сделаю в скором времени.

React + Mobx: в чём смысл?

Ну да, просто тестировать имеет смысл на реалистичных сценариях.

ну там вполне реалистично, 1-2 зависимости, можно увеличить до 1-3, но не более, это будет похоже на 99% ячеек в реальном приложении. А про глубину нет смысла думать, как я уже говорил, ячейке пофиг на какой она глубине, на скорости её обработки никак не отражается, это просто способ сделать их много.

Ну там долго расписывать, какая именно часть его не понятна?

в общих чертах вроде понял, вопрос уже другой: это реально даёт результат в плане ускорения или это пока просто эксперимент? Чем больше понимаю алгоритм, тем большее ощущение, что это никак не должно быть быстрее использования Set и тем более массива при малом числе зависимостей.

React + Mobx: в чём смысл?

Разные реализации по разному справляются с разным числом зависимостей. Ну грубо говоря indexOf на большом числе зависимостей может начать тормозить.

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

трекинг происходил как можно быстрее

ну это понятно, я про идею алгоритма спрашивал.

React + Mobx: в чём смысл?

а в худшем — что-нибудь ломается капитально

ok, на самом деле я немного о другом случае описанном здесь. А то о чём говоришь ты похоже из этой серии. Странно, но со мной такого ни разу так и не случилось, может мне очень повезло, а может что-то в моём фреймворке не даёт этому происходить. В любом случае хорошо, что ничего подобного больше не случится ни с $mol_atom, ни с cellx.

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

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

но без indexOf

выглядит довольно запутанно, плюс отталкивает slaves с разными типами значений (в masters как я понял тоже самое) и лишние итерации при переборе masters (if( !master ) continue). Set#has конечно чуть медленнее, но неужели вся эта дополнительная возня действительно даёт результат? Можешь поверхностно объяснить идею?

React + Mobx: в чём смысл?

Про глубину в очередной раз ответил чуть раньше.

Чтоб можно было на полученные от бека данные вешать реактивные поля, и потом не париться тем, что перед JSON.stringify обратно на сервер эти реактивные поля нужно будет вычищать.

я для подобного использую декоратор NonEnumerable.

React + Mobx: в чём смысл?

но когда стреляло — отрывало руки по локоть

можно пример? Я находил у себя в приложении пару мест с таким лишним вычислением, там всё гладко было. Я именно намеренно искал, никаких проблем не возникало.

И надобности в сильно глубоких деревьях мне встречать не приходилось

вычисляемой ячейке где-то в середине цепочки вообще без разницы сколько там в глубину над или под ней. Твоё предложение менять число зависимостей ещё хоть как-то обосновано (ответил ниже), но я хоть убей не понимаю, что ты так вцепился в глубину дерева. Это же просто способ увеличить число ячеек в тесте.

Трекинг большого числа зависимостей
Инвалидация большого числа зависимых

я вижу у тебя для хранения родительских и дочерних ячеек используется Set, has на котором, при достаточно большом количестве айтемов, будет заметно быстрей, чем indexOf на массиве (https://jsperf.com/array-indexof-vs-set-has/). Наверно, в таком кейсе твой вариант действительно будет быстрее. Я же выбрал массив, тк. при малом числе айтемов уже indexOf быстрее, плюс нативный for-of тогда ещё рано было использовать, а Set#forEach был заметно медленнее обычного цикла. Малое число зависимостей — это 99.9% случаев. Мой бенчмарк показывает как ведут себя библиотеки в этих 99.9%, ты же предлагаешь мне бенчмарк под 0.1% заявляя, что он будет более адекватным. Мне кажется ты всё же не прав.

React + Mobx: в чём смысл?

Корректность всё же важнее производительности

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

Или есть какие-то новые более адекватные бенчмарки?

Не понимаю почему ты не веришь в адекватность такого бенчмарка. Ну вот уменьшу я глубину (число слоёв) одновременно увеличив количество ячеек в каждом слое и что дальше? Если количество вычисляемых ячеек по которым пройдёт сигнал будет тем же, то и результат будет абсолютно тем же.
Все бенчмарки для такой библиотеки, скорей всего, можно разделить на два типа: 1 — скорость создания экземпляра ячейки, 2 — скорость прохождения сигнала по вычисляемым ячейкам. Остальное практически не имеет какого-либо смысла. Что ты предлагаешь ещё замерить? Скорость чтения не вычисляемой ячейки? Зачем?

React + Mobx: в чём смысл?

Начиная с v1.8 алгоритм тот же, что и в mobx. А на счёт менее продвинутого я бы поспорил, да в старом алгоритме есть один мелкий нерешаемый недостаток, но зато он минимум в 3 раза быстрее. В три раза медленнее — это лучшее, что я смог получить с нового алгоритма избавившись всего лишь-то от одного недостатка с которым вполне нормально жилось. Довольно сомнительное улучшение.

Неожиданный порядок инициализации наследованных классов в JavaScript

получаете поле объекта, а в python — это-таки поле класса

ок, в общем-то я и и предлагаю использовать поля класса, на js будет так:

class BaseTooltip {
    static template = 'baseTemplate'
    constructor(content) {
        this.render(content)
    }
    render(content) {
        console.log('render:', content, this.constructor.template)
    }
}

new BaseTooltip('content')

class SpecialTooltip extends BaseTooltip {
    static template = 'otherTemplate'
}

new SpecialTooltip('otherContent')
// render: content baseTemplate
// render: otherContent otherTemplate

Всё зависит от того — хочет ли он этот самый template, в какой-то момент, менять.

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

Неожиданный порядок инициализации наследованных классов в JavaScript

что человек его не знает

не претендую.

Это, вроде как, не совсем то, чего хотел топикстартер

почему? Вроде именно этого он и хотел. Какие недостатки у такого решения для его задачи?

Неожиданный порядок инициализации наследованных классов в JavaScript

Делить на ноль действительно плохо, не делайте так.

Неожиданный порядок инициализации наследованных классов в JavaScript

Python.

Неожиданный порядок инициализации наследованных классов в JavaScript

Как обычно набежала куча любителей самоутверждения чтения документации. Хабру явно не хватает возможности отключать комментарии.

v1vendi на многих ЯП ты бы получил ожидаемый результат:

class BaseTooltip:
    template = 'baseTemplate'

    def __init__(self, content):
        self.render(content)

    def render(self, content):
        print('render:', content, self.template)

BaseTooltip('content')

class SpecialTooltip(BaseTooltip):
    template = 'otherTemplate'

SpecialTooltip('otherContent')

# render: content baseTemplate
# render: otherContent otherTemplate

, плюс все (которые я видел) обёртки имитирующие классы до ES6 вели себя именно так. Я тоже когда-то попался на этом хоть и заглядываю в спецификацию.

UPD: одно из решений — использование статических свойств с обращением к ним через this.constructor.

Улучшайте свое знание JavaScript разбирая исходный код

А как же PrototypeJS и MooTools? Я довольно прилично прокачал свои знания js именно за счёт изучения внутренностей PrototypeJS.