• Почему пропсы из Редакса в обработчике Реакт не видит, когда в render(){} видит?

    rockon404
    @rockon404 Куратор тега React
    Frontend Developer
    Вы передаете метод clickHandle в колбек слушателя события click, при вызове метод теряет контекст, так как вызывается не на вашем объекте. this в таком случае ссылается не на ваш объект, а на undefined. Так как babel при трансляции добавляет 'use strict' (иначе, при выполнении в браузере, ссылался бы на window). Исправить это можно несколькими способами:
    1. переделать обработчик из метода класса в class field arrow function:
    было:
    clickHandle(e) {
      // some code
    }

    стало:
    clickHandle = e => {
      // some code
    };

    class field arrow function получает контекстом экземпляр класса при инициализации и всегда ссылается на него, куда бы вы ее не передали. Это экспериментальная возможность JavaScript и в спецификации ее пока нет. За трансляцию этой конструкции в валидный код отвечает babel.
    Результат, который будет получен после трансляции, можно посмотреть тут. Строки с 23 по 28.

    2.забиндить его в конструкторе на экземпляр класса:
    constructor(props) {
      super(props);
      this.clickHandle = this.clickHandle.bind(this);
    }

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

    3. обернуть в стрелочную функцию в render:
    <SomeComponent onClick={() => this.сlickHandle()} /> // контекст не будет потерян

    При оборачивании в стрелочную функцию происходит следующее: сама функция использует как контекст ваш объект, поэтому при вызове метод будет вызван на вашем объекте и this в самом методе будет ссылаться на объект. Этот вариант разумно использовать, только тогда, когда в хандлер необходимо передать свои аргументы, помимо event:
    <ListItem
      key={item.id}
      onClick={e => this.сlickHandle(item.id, e)}
    >
      {item.name}
    </ListItem>

    так как движок вынужден определять контекст для стрелочной функции каждый рендер, а на это уходит дополнительное процессорное время.

    Как метод теряет контекст.
    Разберем на примере объекта. То же самое происходит в случае с классом, но мы будем использовать в примере объект:
    var john = {
      firstName: 'John',
      getName() {
        return this.firstName;  // this - контекст вызова и это не всегда наш объект
      }
    }


    Сценарий 1:
    console.log(john.getName()); // john
    Тут мы вызываем метод на объекте. Контекстом будет наш объект.

    Сценарий 2:
    var foo = {
      firstName: 'foo',
    };
    var foo.getName = john.getName;
    console.log(foo.getName()); // foo

    Тут мы передаем метод объекта john в свойство объекта foo без вызова и следующей строкой вызываем его на нем. Контекстом в этот раз будет объект foo. Ошибки не будет только потому, что у объекта foo есть свойство fullName

    Сценарий 3:
    var bar = john.getName;
    console.log(bar()); // undefined

    В данном случае в стандартном режиме контекстом будет window, а в строгом режиме вылетит исключение:
    Cannot read property 'firstName' of undefined
    так как this в строгом режиме будет ссылаться на undefined

    Когда вы передаете метод в колбек onClick или в любой другой колбек события, вызов идет подобно третьему сценарию. Поэтому вы должны позаботиться о том, чтобы ваш метод не терял контекст, используя один из способов приведенных выше.
    Ответ написан
    2 комментария
  • Как следует организовать базу и поиск по 1 000 000 000 000 (триллиону) записей на 100ТБ?

    Largo1
    @Largo1
    Айтишник далёкого плана
    хм, странно всё это.. обычно кто создаёт подобную базу - уже знает что делать.. работайте с Oracle
    Ответ написан
    4 комментария
  • Почему преподаватель так считает?

    @asd111
    Возможно преподаватель плохо знал php или на тот момент когда он его учил ассоциативных массивов в PHP ещё не было. Не обращайте внимания, ориентируйтесь не на преподавателя, а на документацию. И обязательно поговорите с преподом на эту тему, чтобы он больше не позорился.
    Ответ написан
    Комментировать
  • Почему преподаватель так считает?

    @Centrino
    Он хотел вас устрашить, что бы выбрали Ассемблер.
    Ответ написан
    Комментировать
  • Почему преподаватель так считает?

    rdifb0
    @rdifb0
    Программист, реалист
    Сходите к нему в гости и спросите. И нам потом расскажете.
    Ответ написан
    Комментировать
  • Закон Деметры. Нужен ли?

    ConConovalofff
    @ConConovalofff
    Сегодня прочитал об этом законе и сделал для себя следующие выводы:

    Закон не нацелен на улучшение читаемости или эстетичности кода. Наоборот, красота кода теряется, а структура класса обрастает проксирующими функциями-пустышками, портя читаемость класса.

    Основная цель использования закона, это избавить команду программистов от страха изменять существующий код.

    К примеру, представим 2 разные ситуации:
    1. В проекте игнорируется закон Деметры. Класс b включен в классы a, c и d. Каждый класс инстанцируется в разных участках кода по 10 раз каждый и применяется a.b.Method(), c.b.Method() и d.b.Method()
    2. В проекте применяется закон Деметры. Класс b включен в классы a, c и d. Каждый класс инстанцируется в разных участках кода по 10 раз каждый и применяется a.Method(), c.Method() и d.Method()

    При замене класса 'b' на класс 'z':
    В 1-ом случае нам придется изменить код в 30 местах где используется a.b.Method().
    Во 2-ом случае нам потребуется изменить код в 3-ех методах классов a, c и d.

    Следуя этому правилу, я думаю будет логичен следующий код:
    $user = new User('Paul')
    $comments = $user->getCommentsOfLastPost()


    В классе User:
    function getCommentsOfLastPost()
    {
        $posts = new Posts()
        $posts->getCommentsOfLastPostUser($this)
    }

    и т.д.

    В итоге, этот закон стоит применять там, где стоимость легкого изменения кода выше стоимости чистоты структуры классов. А значит, закон лучше игнорировать при разработке небольших проектов.

    Я уловил суть?
    Ответ написан
    1 комментарий
  • json_encode в PHP превращает кирилицу в \u041D коды

    MTonly
    @MTonly
    Веб-разработчик с 2002 года
    Собственно, «исправлять» не обязательно (хотя в плане перфекционизма я вас хорошо понимаю). Это легитимные JS-строки, в браузере отображаются корректно. Объём данных, правда, больше. Но, с другой стороны, Gzip-сжатием этот фактор минимизируется. ;-)

    Можно ещё делать так:

    $json = defined('JSON_UNESCAPED_UNICODE')
          ? json_encode($data, JSON_UNESCAPED_UNICODE)
          : json_encode($data);
    

    Тогда в свежих версиях PHP JSON-код будет наиболее оптимальным по объёму, а в более старых — всего лишь несколько менее оптимальным.
    Ответ написан
    2 комментария