Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (16)

Наибольший вклад в теги

Все теги (82)

Лучшие ответы пользователя

Все ответы (142)
  • В чём принципиальный смысл PropTypes/TypeScript/Flow?

    @Interface
    Вы задаете очень общий вопрос, на который полно информации в интернете. Например вот статья: https://habr.com/post/326304/ .

    Вам не понятно в чем профит?
    - меньше ошибок при разработке
    - более адекватный intellisense
    - намного проще рефакторить
    - использовать сторонний код (тайпинги могут (но не должны) частично заменить доки)
    - генерация документации https://typedoc.org/
    - возможность вообще описать где-то сущности, а не опираться на их создание в коде
    и много всего еще.

    Или вы не согласны, что профит есть? Тогда аргументируйте с чем вы не согласны (относительно множества источников в интернете).
    Ответ написан
  • Можно ли считать выполнение xmlhttprequest запроса работой в отдельном потоке?

    @Interface
    Дисклеймер:
    С веб-воркерами (и чем-то подобным) все и так понятно, поэтому далее я пишу вне их использования

    Ответ на ваш вопрос сильно зависит от понимания заголовка. Если мы говорим про браузер или какую-то его часть - то вполне вероятно это действительно работа в отдельном потоке. Только это работа браузера, а не javascript. Вот например статья про node.js https://codeburst.io/how-node-js-single-thread-mec... (достаточно прочитать Top Highlight)
    The main event loop is single-threaded but most of the I/O works run on separate threads, because the I/O APIs in Node.js are asynchronous/non-blocking by design, in order to accommodate the event loop.

    Таким образом про node.js можно сказать, что оно - многопоточное приложение. Но вот с точки зрения javascript-а, то есть как-бы изнутри него - node.js - однопоточный. Иными словами: весь JavaScript код и в браузере и в ноде позиционирует себя как однопоточное приложение. И исполняется так же. Но какие-то операции вне языка (I/O или тот же xhr) могут быть реализованы как угодно браузером. Это строго говоря вопрос больше про устройство среды исполнения.

    Я подвис, но мой ответ был, что JS можно считать многопоточным и я так предполагаю из-за наличия xmlhttprequest запросов (в простонародии ajax).
    - строго говоря это не так. Хотя мне кажется это не далеко от истины. Если мы поговорим, что язык многопоточный, я думаю мы имеем ввиду, что языком поддерживается работа с потоками, а не то как он устроен изнутри или как изнутри устроена среда его исполнения. Потому как какая-нибудь сборка мусора может выполняться в отдельном потоке, но это не делает сам ЯЗЫК много поточным.

    Вопрос: Относится ли WebAPI к движку JavaScript и корректно ли утверждать, что фактически xmlhttprequest выполняется в отдельном потоке от остального кода JavaScript?

    - Нет. Это API которое браузер предоставляет внутрь движка. Это можно проследить взяв например node.js и сравнив с браузерным js. Так, например, в node.js доступны внутренние модули (fs, http, path etc.)., а также другие фичи, такие как process.argv и так далее, в то время как в браузере есть WebAPI, например, fetch. При этом в браузере нет require('path'), зато в ноде нет fetch.

    И это при том что и браузер (chrome) и node.js работают на одном движке (V8).

    В node.js нет доступа к xhr, что уже может навести на мысли о том, что это не часть движка.

    Важное замечание: я думаю сравнивая node.js и браузер, можно сформировать какое-то представление о том, что из себя представляет чистый движок js, но тем не менее это не полностью достоверно. Потому как, например, и там и там есть совместимые друг с другом setInterval и setTimeout, однако (если мне не изменяет память) они не входят в движок.

    Если хочется четче понять где проходит граница, но не так сильно чтобы читать спеки - можно попробовать встроить движок самостоятельно. V8 или SpiderMonkey (в Firefox'е) умеют встраиваться в другие приложения и если встраивать их самостоятельно - и API внутрь движка (причем конкретной его реализации, а не абстрактного понятия) нужно будет прокидывать самостоятельно - тогда можно будет увидеть, что в голом движке не будет ни setTimeout, ни alert, ни console.log, ни document ни даже require и т.д.
    Ответ написан
  • Почему регулярка быстрее indexOf?

    @Interface
    Прежде всего нужно понять - действительно ли быстрее?

    Есть замечательный доклад на эту тему: https://www.youtube.com/watch?v=HPFARivHJRY - очень рекомендую к просмотру.

    На вскидку:
    - движок может выкидывать тот или иной кусок бенчмарка
    - движок может реализовывать какой-либо кэш и считать один раз

    P.s. в мозиле результаты другие: победил lodash, что иронично потому что у него под капотом indexOf
    Ответ написан
  • Почему (8 == (10 || 9 || 8)) === false, и чем заменить данное условие?

    @Interface
    вероятно вам нужно что-то такое:
    if (![10, 9, 8].includes(8)) ...

    Судя по всему вы хотели написать
    if ((8 == 10 || 8 == 9 || 8 == 8) === false) ...
    В таком случае:

    1) при сравнении чисел лучше использовоть строгое равенство (===):
    // для адекватности примера заменил 8 на x
    if ((x === 10 || x === 9 || x === 8) === false) ...


    2) нет смысла сравнивать результат логической операции с false, можно просто поставить перед скобками !:
    if (!(x === 10 || x === 9 || x === 8)) ...
    Ответ написан
  • Можно ли написать функцию, которая проверяет существует ли переменная или нет (js)?

    @Interface
    Дисклеймер: так как вопрос скорее теоретический, я не стараюсь предоставить "адекватное" решение.
    Конечно, все это нельзя использовать в реальном проекте!


    Интересный вопрос.

    Начнем с того, что определимся насколько критично сохранить сигнатуру функции? В зависимости от этого, решения можно поделить на 2 категории:
    - где допускается изменение сигнатуры
    - где сигнатура должна быть строго такой и никакой иначе

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

    Стоит оговориться, что строго говоря такую функцию в данном виде написать нельзя, потому как при вызове функции переменная уже должна быть "разименована", а значит мы так или иначе будем работать с ее значением или с какими-то косвенными сайд эффектами вызванными обращением к ней.


    Сначала рассмотрим несколько решений с изменением сигнатуры: они попроще и в каком-то смысле более логичны.

    есть как минимум 2 категории решений с изменением сигнатуры:
    - функция будет принимать строку
    - функция будет принимать функцию

    При этом проблема того, что все падает до попадания в функцию, пропадает сама собой.

    вот несколько решений:

    1) класс решений построенный на анализе кода в рантайме:
    решение заключается в том, что вызываемая функция анализирует свой код (а также код функции которая вызвала ее и т.д.)
    https://stackoverflow.com/questions/2051678/gettin... вот тут есть частчный разбор такого решения.
    Приводить его в виде кода я не буду :)

    Плюсы:
    - вроде как решает задачу
    - сигнатура изменилась не сильно
    Минусы:
    - крайне жирное решение с точки зрения производительности
    - сигнатура не та, что просили
    - нельзя использовать 'use strict', так как решения возможно будут завязаны на arguments.callee.caller

    Уровень безумия: достаточно безумное

    2) решение построенное на том, что приниматься будет функция:
    isExists(() => someVar); // такая будет сигнатура

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

    Одна из возможных реализаций:
    function isExists(someVarFn){
        try {
            someVarFn();
        } catch(e) {
            if (e instanceof ReferenceError) {
                return false;
            }
            throw e;
        }
        return true;
    }

    Примеры использования:
    function f1() {
        let x;
        console.log(isExists(() => x)); //  => true
        console.log(isExists(() => y)); //  => false
    }
    
    function f2() {
        let x;
        console.log(isExists(() => x)); //  =>  true
        console.log(isExists(() => y)); //  => false
    }
    
    f1();
    f2();


    Плюсы:
    - плюс-минус адекватная производительность
    - довольно компактно
    Минусы:
    - несильно меняется сигнатура функции
    - api получается несколько не очевидным

    Уровень безумия: почти адекватное

    3) решения с использованием eval:
    Суть похожа на решение #2, но с другим api:
    function isExists(varName, fn){
        return fn(`(()=>{
            try {
                const nop = ${varName};
            } catch(e) {
                if (e instanceof ReferenceError) {
                    return false;
                }
                throw e;
            }
            return true;
        })()`);
    }
    
    function f1() {
        let x;
        console.log( isExists('x', c => eval(c)) ); //  => true
        console.log( isExists('y', c => eval(c)) ); //  => false
    }
    
    function f2() {
        let y;
        console.log( isExists('x', c => eval(c)) ); //  =>  false
        console.log( isExists('y', c => eval(c)) ); //  => true
    }
    
    f1();
    f2();


    Плюсы:
    - сложнее чем в №2 передать какую-то фигню
    Минусы:
    - сигнатура отлиается сильнее и уродливей
    - сложнее / жирнее / больше чем №2

    Уровень безумия: безумненько

    Решения с сохранением сигнатуры:

    4) магия es6 Proxies + with
    класс решений строится на стратегии: слушать доступ к глобальному объекту и если он происходит и в нем нет переменной с таким именем - такой переменной нет:
    const pseudoUndefined = {};
    
    const scopeTrap = new Proxy(window, {
        has() {return true},
    
        get(target, prop) {
            if (prop in window) {
                return window[prop];
            } else {
                return pseudoUndefined;
            }
        }
    })
    
    function isExists(someVar) {
        return someVar !== pseudoUndefined;
    }
    
    // весь код использующий функцию должен быть обернут в такой with :(
    with (scopeTrap) {
    
        let y;
        console.log( isExists(x) ); //  =>  false
        console.log( isExists(y) ); //  => true
    
    }


    Плюсы:
    - мы сохранили желаемую сигнатуру! Ура!
    Минусы:
    - теперь вместо исключения будет получаться что-то совсем левое. Хорошего дебагга! :D
    - накладные расходы производительности
    - все нужно обернуть в with
    - необходима поддержка es6+

    Уровень безумия: с точки зрения реализации - задача подъемная. использовать в бою - а вы знаете толк!

    Решения с предобработкой:

    Первые две категории решений исходят из того, код (включая код вызовов функции) будет исполняться без изменений напряму интерпретатором. Если развязать себе руки, то открывается целый спектр новых решений:

    5) первое, что приходит в голову с приобретением такой свободы - это, очевидно... написание своего языка программирования компилируемого в js / своего интерпретатора js и т.д.
    В рамках этого решения особого труда (относительно всего прочего) не составит реализовать такую функцию нативно.

    Плюсы: ...
    Минусы: ...
    (Без комментариев)

    Уровень безумия: я думаю все понятно
    ...

    есть и более сдержанные решения, например, используя compile-time можно оптимизировать предыдущие решения:

    6) можно используя парсер составить дерево областей видимости (хэш-таблица [функция <-> список переменных]), привязать каждую область к функции, через позицию в исходном коде (возможно придется сохранять дополнительную информацию). А дальше все это интегрировать с решением №1.

    В итоге:

    Плюсы относительно (#1):
    - относительно хорошая производительность
    Минусы:
    - сложно
    - дорого
    - требует compile-time

    Уровень безумия: стало еще безумнее, чем было :)

    7) написать (или найти) плагин для babel'я (или чего-то другого), который будет трансформировать доступ к переменным в особую функцию

    Плюсы относительно (#1):
    - достигнут результат
    Минусы:
    - требует поддержки
    - требует compile-time
    - упадет производительность (вероятнее всего существенно)

    Уровень безумия: буднечно безумное
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (33)