• Как получить доступ к [[PromiseValue]]?

    rockon404
    @rockon404 Куратор тега React
    Xaip, как вы собрались парсить json< с помощью map?
    Вызов response.json() в примере, как раз парсит ответ.
  • Почему не работает Link в react-router?

    rockon404
    @rockon404 Куратор тега React
    KirylLapouski, нет у вас в NavBarCustom свой роутер. Уберите его.
  • JavaScript: Архитектура приложения с нуля?

    Роман,
    Моя позиция... А ваша...

    У вас либо нарушения либо памяти, либо явные проблемы с логическим мышлением.
    Вы, наверно, забыли, но вы рекомендовали "изобретать велосипед" и это якобы поможет "понять как фремворки работают под капотом. Какие паттерны используются, что такое депенденси Инжекшен и почему где-то это основа фреймворка, а где-то запросто без этого обходятся". Только первое не подразумевает второе. А моя рекомендация как раз поможет понять как они работают внутри и по пути изучить все архитектурные подходы за последние 10 лет со всеми их преимуществами и недостатками.

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

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

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

    По сему, вынужден не согласиться с вами насчет велосипедов, но желаю удачи вам в этом нелегком деле.
  • Как исправить ошибку при установке React Jest?

    rockon404
    @rockon404 Куратор тега React
    У вас в корневом каталоге есть файл .babelrc?
    Там стоит пресет react?
  • JavaScript: Архитектура приложения с нуля?

    Роман, с почином еще раз. Я, вроде, даже переменную так назвал. Странно, что вы рассуждаете о паттернах, о важности знания их поименно, но на деле даже самых простых не знаете.

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

    О нет, если забыли, то это вы мне написали и начали спор с утверждением, о том, что велосипеды писать "можно и нужно". А не с того, что "Нужно читать про архитектуру". Это два разных утверждения.
    Вопрос автора лично мне был: "а что можешь предложить?". На что я ему ответил то, что думаю о самописной архитектуре и предложил более рациональный со своей точки зрения вариант.

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

    Или ему нужно изучить все фрейворки,

    Я такого не писал. Давайте я процитирую свой комментарий:
    Изучите историю становления фрейворков от Backbone.js до React/Vue. Предпосылки к появлению, мотивацию к использованию, недостатки, узкие и проблемные места. При этом желательно понять, почему со временем отказались от тех или иных решений и почему пришли к тому, что есть.

    Есть множество статей с такими разборами, которые недолго почитать. Исходники лежат на Github, изучить интересные места не долго.

    Так же напомню, что когда начали появляться первые фронтенд фреймворки, паттерны проектирования и принципы SOLID уже давно существовали, но целому сообществу понадобились годы, чтобы придти к тому, что есть сейчас. По сему, мое мнение, начинать путь с велосипеда прото-фреймворка отнюдь не самое рациональное решение, особенно для новичка.
  • JavaScript: Архитектура приложения с нуля?

    Роман,
    я тоже так и подумал - что никаких своих паттернов во фронте нет.

    Как же нет, если есть.
    банальный пример
    var module = (function () {
        var a = 1;
        
        function bar() {
          return 2;
        }
    
        return {
            foo: function (arg) {
                return a + bar() + arg;
            }
        }
    })();


    Даже если в работе с API фремворка находят эффективные архитектурные решения с конкретными реализациями, которые становятся стандартами, это уже паттерн проектирования.

    Если автор будет знать классику - тогда не будет разницы, фронт это или бэк. Это если мы говорим об архитектуре.

    Сдается мне опыта работы с языками вроде Java у вас нет. Знали бы как сильно отличаются реалии разработки по сравнению с JS.

    Я не спорю, что знание паттернов очень полезно. Заметьте я писал лишь, что "Вопрос о пользе от знания всех классических паттернов проектирования ООП во фронтенд разработке, весьма спорный."
    Это было в противопоставление вашим словам: "но большая часть "синьоров" начинают путаться в паттернах и для решения каких проблем их придумали". Вы думаете вас на оффлайн интервью не поставить в тупик задачей на паттерны? Если это так, то вы слишком самонадеянны.

    Если вы в проектах пишите собственные реализации Observer, то мне вас искренне жаль. Вы делаете напрасную работу.

    И если говорить об архитектуре. В случае с Observer для архитектуры проекта не будет никакой разницы реализовывали вы его сами или нет. Неудачный пример.
  • JavaScript: Архитектура приложения с нуля?

    Роман, в том то и дело, что в отличии от меня вы свое имхо, вроде "можно и нужно" от объективной реальности, видимо, не отличаете.
    Где я посоветовал автору модули и библиотеки? Вы что-то путаете. Это был лишь оффтоп в дискуссии с вами.
    Если у вас паттерны ассоциируются только с классикой, то у меня для вас плохие новости.
    spoiler
    Шаблон проектирования или паттерн - повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

    С почином.

    Я не писал "чисто свои", я мел ввиду свой набор и конкретные реализации, которые хорошо знать.
  • JavaScript: Архитектура приложения с нуля?

    Роман, я в первом комментарии давал рекомендации, которые, имхо, будут куда полезней опыта велосипедостроения.
    В том то и дело, что сейчас передовые фреймворки ушли далеко вперед от идей о масштабируемой архитектуре 2010 года. И ковыряние с протофреймвоком, конечно, немного развивает, но оно и рядом не встанет, с глубоким анализом эволюции идей за последние 8 лет.
    Имхо, хорошо научиться писать модули и библиотеки. Для этого, опять же, достаточно провести анализ хороших примеров на Github и написать свою.
    Вопрос о пользе от знания всех классических паттернов проектирования ООП во фронтенд разработке, весьма спорный. А без знания нормального ООП языка вроде Java, нет смысла заставлять человека детально изучать большинство из них.
    Во фронтенде используются свои паттерны, как в самом JS, так и в разработке с использованием современных фреймворков. Вот их знать хорошо, но и изучить совсем не долго.
  • JavaScript: Архитектура приложения с нуля?

    Роман,
    1. Изобретать велосипед в коммерческих проектах не нужно. У такого подхода только объективные минусы:
    - замедляется скорость разработки
    - onboarding в разы дольше
    - трудно найти адекватных людей, согласных колупаться в вашем коде, даже за хорошие деньги
    - в случае ухода ключевых разработчиков, проект возможно будет обречен
    - архитектурные просчеты могут стоить слишком дорого
    - исходя из предыдущего пункта рефакторинг и масштабирование, могут быть лютой болью
    - отсутствие готовых типовых решений может быть проблемой как для новичков, так и для программистов среднего уровня
    - минусов гораздо больше, смысла нет все перечислять.

    2. "чтобы понимать как они устроены" достаточно изучить исходные коды(для сложных фреймворков желательно почитать статьи с разбором). Я же в своем комментарии выше советовал изучить всю эволюцию и не только код, но и предпосылки, мотивацию. Тогда придет понимание почему они устроены именно так, какие недостатки были у предшественников и какие проблемы призваны решить новые подходы и решения.

    3. Не судите по большей части, вы большую часть не знаете. Все хорошие программисты и изучают исходники(а многие являются контрибьюторами в open source проектах), и знают паттерны проектирования, и много чего еще. А так же они рационально подходят к решению задач. Велосипед вместо фреймворка в 2018 году, это, в подавляющем большинстве случаев, нерациональный подход.

    Вы видимо не поняли посыл моего комментария.
  • Что проверяет это условие?

    Не обязательно:
    !0 === true
    !+"0000000" === true
    !NaN === true

    NaN может прилететь в результате операции подобной этой:
    'text' * 2 === NaN
    !('text' * 2) === true
  • Как работать с prettier?

    rockon404
    @rockon404 Куратор тега React
    webe, вижу вам уже ответили)
  • Как выполнить действие если есть текст?

    Filipp R., не обратил внимания, что в теге JQuery:
    var word1 = 'word1';
    var word2 = 'word2';
    
    var val1 = $('.class1').html();
    var val2 = $('.class2').html();
    
    if (val1 === word1 && val2 === word2) {
      alert(word1 + ' and ' + word2);
    }
  • Самописный роутер на js в функциональном стиле, реально?

    Зачем писать то, что уже давно хорошо написано до вас?
  • Как выполнить действие если есть текст?

    Filipp R.,
    var word1 = 'word1';
    var word2 = 'word2';
    
    var div1 = document.querySelector('.class1');
    var div2 = document.querySelector('.class2');
    
    var val1 = div1 && div1.innerHTML;
    var val2 = div2 && div2.innerHTML;
    
    if (val1 === word1 && val2 === word2) {
      alert(word1 + ' and ' + word2);
    }


    Демо
  • Как выполнить действие если есть текст?

    Filipp R., проверить на что? Если проверить только наличие divов, то текст трогать вообще не надо.
    var div1 = document.querySelector('.class1');
    var div2 = document.querySelector('.class2');
    if (div1 && div2) { console.log('div1 an div2 founded') }
  • Как выполнить действие если есть текст?

    Filipp R., а что именно нужно? На сколько я понял вопрос вам надо возвращать true если есть вхождения в строке. Или вы не знаете как значение из input получить?
  • Почему не работает деструктуризация?

    ivankirshin, ух ты. Очень интересно. Вот и подводные камни отказа от точек с запятой. Исключение поставьте:
    let puzzles = getters.getPuzzles; // eslint-disable-line
    [puzzles[first],puzzles[second]] = [puzzles[second],puzzles[first]]


    По мне код красивей и читаемей с точками с запятой.