Задать вопрос
  • Как результат promise передать в переменную?

    kzoper, вы не понимаете простых основ вытащить ее легко и записать куда угодно легко, а вот использовать в том же блоке где и промис можно только в async/await функции, либо в колбеке then. Никто вам не мешает вызвать в then другую функцию и что угодно:
    asyncCall.then(res => {
      foo(res);
      bar(res);
    });
    // тут использовать res нельзя
    // только в async/await функции
  • Как результат promise передать в переменную?

    kzoper, после вызова возвращающего просись у вас вообще не должно быть кода использующего результат вызова. Только в колбеке then. Как альтернативу можно использовать async/await. Почитайте статьи о том как организовывать асинхронный код. Основы я вам рассказал.
  • Как результат promise передать в переменную?

    kzoper, так я вам простой пример и показал. Вы можете вызывать в колбеке then все что захотите.
  • Как результат promise передать в переменную?

    kzoper, нет, вам надо научиться писать асинхронный код. В then вы можете вызывать колбек в котором можно и браузер в переменную писать и выполнять все, что захотите.
  • Почему не получается унаследовать класс?

    someserj, как работает? Взгляните в консоль. Последний вывод. При использовании var значение инкапсулировано(находится в замыкании) и строка:
    counter.value = 100500;
    его не переопределяет. При использовании this переопределяет.
  • Почему не получается унаследовать класс?

    someserj, лучше в прототип. Но можно и внутри. Смотрите пример с прототипом. Тут мы можем легко подменить значение counter.value в коде.
    Пример с методами в конструкторе. Тут value инкапсулирована, она является переменной в окружении(замыкании) созданном при вызове конструктора и недоступна из объекта-экземпляра. Ее подменить невозможно.
    Другое дело, что редко когда такое может понадобиться, да и главный недостаток в том, что копии методов не берутся из прототипа, а создаются в каждом экземпляре.
    Объявлять методы в конструкторе целесообразно только для инкапсуляции значений и других методов. Во всех других случаях лучше выносить в прототип.
  • Почему не получается унаследовать класс?

    someserj, смотрите, если мы добавим в прототип С метод и попробуем его вызвать на объекте созданном конструктором D, то получим ошибку.
    Строка:
    D.prototype = Object.create(C.prototype);
    делает копию прототипа C и пишет его в прототип D. Копия потому, что если мы захотим расширить D.prototype без копирования, расширится C.prototype. После добавления этой строки вызов obj.foo() будет работать.
    Вторая строка:
    D.prototype.constructor = D;
    просто подменяет ссылку на конструктор. Чтобы у созданных объектов была правильная ссылка на конструтор.
  • Односвязные список - добавление нового узла?

    Артем, может еще это поможет:
    1. добаляем в список элемент 'xxx'.
    head:
    {
      next: null,
      value: 'xxx',
    }

    tail:
    {
      next: null,
      value: 'xxx',
    }

    2. добавляем 'yyy'.
    head:
    {
      next: {
        next: null,
        value: 'yyy',
      },
      value: 'xxx',
    }

    tail:
    {
      next: null,
      value: 'yyy',
    }

    3. добавляем 'zzz'.
    head:
    {
      next: {
        next: {
          next: null,
          value: 'zzz',
        },
        value: 'yyy',
      },
      value: 'xxx',
    }

    tail:
    {
      next: null,
      value: 'zzz',
    }
  • Что такое mapDispatchToProps?

    rockon404
    @rockon404 Куратор тега React
    WarriorKodeK, смотрите вы делаете actions такого вида:
    export const decrement = () => dispatch => {
      dispatch({
        type: DECREMENT
      });
    };

    Так как decrement возвращает функцию:
    dispatch => {
      dispatch({
        type: DECREMENT
      });
    };

    Его перехватывает redux-thunk, вот тут и вызывает передавая на вход store.dispatch, getState и опциональный аргумент.
    Так как ваши acions не содержат асинхронных вызовов, передавать их в таком виде нет смысла. Можно изменить на:
    export const decrement = () => ({ type: DECREMENT });

    А возвращаемый объект в редьюсере:
    return {
       ...state,
      value: state.value + 1
    };

    можно сократить до:
    return {
      value: state.value + 1
    };

    так как state редьюсера содержит только ключ value.
  • Что такое mapDispatchToProps?

    rockon404
    @rockon404 Куратор тега React
    WarriorKodeK, я там в примере забыл ключевое слово await написать. Добавил, посмотрите.
  • Что такое mapDispatchToProps?

    rockon404
    @rockon404 Куратор тега React
    WarriorKodeK, обращайтесь, если что-то еще будет непонятно.)
  • Что такое mapDispatchToProps?

    rockon404
    @rockon404 Куратор тега React
    WarriorKodeK, mapDispatchToProps используется для передачи AC в props компонента в виде функций которые просто вызывать.
    componentDidMount() {
      const { id,  getConditionById } = this.props;
    
      getConditionById(id);
    }

    Но да вы можете использовать воторой аргумент ownProps и передавать в mapDispatchToProps props компонента. Это редкий кейс. Я в проектах ни разу его не использовал. В mapStateToProps второй аргумент используется часто.
  • Что такое mapDispatchToProps?

    rockon404
    @rockon404 Куратор тега React
    WarriorKodeK, ох. Во-первых установите и подкючите redux-thunk это отличное middleware для асинхронных действий.
    Ваше действие:
    export const getConditionById =  id => async dispatch => {
      const domenPath = domen[domenKey];
      const apiPath = api[apiKey];
      
      try {
        const { data } = await Api.get(`${domenPath}${apiPath}/${id}`);
        
        dispatch({
          type: `${CREATE_QUESTION}_SET_COND_QUESTION`,
          payload: { body: data },
        });
          
        return data;
      } catch (e) {
        console.log(e);
      }
    };
    
    export const clearCreateQuestion = () => ({ type: `${T.CREATE_QUESTION}_CLEAR` });


    Ваш connect:

    const mapDispatchToProps = {
      clearCreateQuestion,
      getConditionById,
    };
    
    export default connect(mapStateToProps, mapDispatchToProps)(CreateConditionComponent);


    Самому со store.dispatch работать не надо, connect обернет в него все вызовы за вас. Когда передаете в mapDispatchToProps объект(как в моем приере) он передается в вызов bindActionCreators.
  • Как правильно создать многомерный массив/объект?

    boga-net, по поводу:
    var data = {
      fruits : {
        Apple: 'http://.png',
        Banana : 'https://.png'
      },
      animals : {
        Apple: 'http://.png',
        Banana : 'https://.png'
      }

    не лучшее решение, с такими данными не во всех кейсах удобно работать.
    Так как я написал будет лучше. Со временем думаю сами все поймете)
  • Как запустить React.js на сервере Scala REST API?

    rockon404
    @rockon404 Куратор тега React
    Папку для статики надо определить.
  • Как получить доступ к [[PromiseValue]]?

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

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

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

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

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

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

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

    По сему, вынужден не согласиться с вами насчет велосипедов, но желаю удачи вам в этом нелегком деле.