4 библиотеки, упрощающие жизнь React-разработчика

Ну почти переизобрел (Библиотека не моя, просто пользуюсь. Только декоратор самописный). Мне кажется, react-bem-helper немного более гибкий. По крайней мере я не заметил в Вашей библиотеке подобных конструкций:

bemHelper('element', {
  mod1: true,
  mod2: false,
  mod3: function() { return false; }
  'mod5 mod6': function() { return true; }
});

Для меня замыкания не столь необходимы, но вот передавать объект с модификаторами, где все контролируется Boolean значениями, это просто мегаудобно. Прям как доктор прописал.

Посмотрите в сторону этой библиотеки. Там много чего интересного есть. А декоратор написать не сложно.

Firefox легко обходит защиту в новом интерфейсе Gmail

С трудом представляю себе, как можно все правильно провернуть в браузере. От принтскрина и скринрекорда ничего не спасет. А текст? Ну что можно сделать с текстом, чтобы его ну никак нельзя было вытянуть из кода страницы? Рисовать в canvas? Но его тоже можно правой кнопкой сохранить. Как вариант, можно на странице расположить сотню канвасов и рисовать текст фрагментированно, чтобы было сложнее вытянуть данные. Хотя я не уверен, что сохранение страницы целиком не сохраняет и содержимое канвасов — не проверял. Но тем не менее. Любой, кто владеет кнопкой PrtSc, а это почти все, сможет сохранить себе сообщение навсегда, как бы Google не старался.

4 библиотеки, упрощающие жизнь React-разработчика

Статья немного не формата хабра, но ладно… Немного моих мыслей.

Замечание по поводу первой библиотеки: использовать в списках ее категорически нельзя. Это может очень плохо сказаться на производительности, особенно на больших списках, т.к. ReactJS будет пересоздавать элементы на каждый чих. Тогда уж лучше вообще ключи не использовать, чем рандомные. На крайний случай, индекс массива, хотя это тоже не рекомендуется. А лучше всего использовать статичные IDшники, либо, как в Вашем примере, сам элемент:

Код

import React from 'react'

const ListDrinks = props => {
    const drinks = ['rum','bear','vodka']
    return(
        <ul>
            {drinks.map((value)=>{
                return(
                    <li key={value}>{value}</li>
                )
            })}
        </ul>
    )
}
export default ListDrinks

Если говорить про библиотеку для генерации классов, то я использую эту. Люблю BEM. Написал обертку-декоратор для этой либы, который можно использовать примерное так:

Еще код

import React from 'react';

import bemHelper from './bemHelper';

@bemHelper('timeline')
export default class Timeline extends React.PureComponent {
    render() {
        const {
            bemHelper
        } = this.props;

        return <div className={bemHelper()}>
            <div className={bemHelper('element', 'modifier')}></div>
        </div>;
    }
}

Просто нереально удобно // Знаю про CSS-in-JS, но у нас используется SCSS со всеми вытекающими

Для форм использую react-form. Он немного сложен, но гибок и удобен.

ФАС предлагает закон по обязательной установке российского ПО на смартфоны

Мне почему-то кажется, что автор комментария имел в виду обновление именно Google Play и Google Services, которым закон не писан и обновляются при любом подключении. И это не отключить, не удалить. Особенно бесит это на старых или дешёвых телефонах, где эти обновления сжирают сходу 80% всей доступной памяти…

10 советов по дизайну интерфейса

Выпадающие списки — это, конечно, круто. Но до тех пор, пока в этом списке не больше 10 значений. Кто бы только знал, как меня бесят эти списки со всеми странами мира, где нельзя просто взять и отфильтровать, а приходится среди этого всего искать нужную мне Russia, в уме перебирая английский/русский алфавит. Мне нравятся гибриды текстового поля и выпадающего списка, где можно и выбрать, и ввести

Блокировка Telegram оставлена в силе по решению Мосгорсуда

Я вот никак не могу понять, а что мешает террористам использовать другие защищённые методы общения? Окей, про мессенджеры уже не говорю. Но вот что первое в голову пришло: заранее обменяться паролями, взять и создать файлик в keepass, внести туда свои данные и отправить всем своим друзьям любым существующим методом, хоть через ВК или mail.ru. Либо что мне мешает отправлять через тот же ВК заранее зашифрованные данные, например, RSA шифрованием? Администрация ВКонтакте тут уже ничем не поможет.
Даже если Дуров прогнётся и сделает все так, как его просят сделать, и все сообщения будут в открытом виде на серверах, то что мешает другим сделать клиент, который повторяет текущую функциональность с е2е шифрованием? Просто сообщения будут передаваться через обычный чат в зашифрованном виде, а ключи будут только у пользователей

Умная колонка Echo записала частную беседу и отправила случайному контакту

Наверное, потому что может, хочет, у них есть деньги и, скорее всего, большой дом с многочисленными комнатами в 2 (или более этажа), где одного такого девайса будет мало

Как мы на React 16 переезжали

Да, спасибо, уже переехали)

PHP может стать еще лучше

Любые функции можно импортировать через use, как и классы. Поэтому, это опять же не проблема.

PHP может стать еще лучше

Можно старые функции оставить, пометить как deprecated, а новое по-человечески запихивать в namespace'ы, а не в глобальную область видимости

PHP может стать еще лучше

Было бы все просто, если было бы все просто. RFC писать без предварительной реализации и без тестов не имеет особого смысла (там так и сказано). Я бы с удовольствием поддержал проект кодом. Но сколько времени займет изучение языка C и исследование внутренностей проекта, прежде чем я смогу написать что-то толковое? С учетом полной рабочей занятости, на это могут уйти годы...

PHP может стать еще лучше

Спасибо, исправил

DevConf: из шаурмы в Symfony или миграция legacy

У нас такая же ситуация была. Но фронт контроллера не было, а было распихано по файлам. Проект был в настолько плохом состоянии, что написание тестов только навредило бы. Постелено внедрил в проект Yii2. Теперь от старого кода осталась только БД, которую я постепенно мигрирую на новый манер. Удивительно, но прям сложно это не было.
Сейчас понимаю, что Yii2 — не самый подходящий для нашего проекта инструмент и хочу как-то переползти на Symfony. Только Yii2 не очень-то учит хорошим практикам программирования, и из-за нехватки опыта в свое я успел научиться плохому и жёстко привязать проект к фреймворку. И вот теперь я понимаю, что мигрировать с одного фреймворка на другой будет сложнее, чем этого хотелось

Собственные валидации полей для Rules в одном классе

Вы, к сожалению, правы на счет последнего. Обычный callable Yii2 в качестве валидатора не принимает (хотя очень хотелось бы). Достаточно посмотреть в код \yii\validators\Validator::createValidator

Зато он принимает Closure! И тогда можно использовать одну из фич PHP7 Closure::fromCallable:

\Closure::fromCallable([$this, 'validationMethod'])

// Опять же, я не проверял. В теории, должно работать. Но идея с трейтами мне до сих пор не нравится.

Собственные валидации полей для Rules в одном классе

Не претендую на истинность высказываний, но Ваше решение очень плохо пахнет… Yii в качестве валидатора может принимать любой callable (ведь так?). Поэтому я бы предпочел либо сделать класс с набором статических методов-валидаторов [CustomValidators::class, 'phoneValidator'], либо создавать экземпляр класса и указывать метод [new CustomValidators(), 'phoneValidator'], либо можно вообще наполнить статическое свойство yii\validators\Validator::$builtInValidators конфигами часто используемых валидаторов и писать так: ['propertyToValidate', 'phone']. Но использовать для этого трейт и пихать все нужные и ненужные методы в класс… Почему-то мне кажется, это не самое лучшее решение…
Я предпочитаю для часто используемых валидаторов использовать последний метод (для номеров телефонов, например), а в остальных случаях создавать новый класс и явно его указывать.
// Все выше сказанное является абсолютным ИМХО

PHP ACL. Попытка сделать код безопаснее

Это все, конечно, здорово. Идея мне нравится. Но какой оверхед от этого, не замеряли? Или это все пока что на стадии концепта?

Чего боятся программисты?

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

Чего боятся программисты?

Недавно наняли одного человека, который тестирует новые функции. Стало намного лучше. Но не может ведь человек тестировать одно и то же каждый раз. Для этого и пишутся автоматические тесты. Естественно, ручное тестирование и раньше было, только очень посредственное. Для этого даже сделали специальный тестовый сервер, на котором все можно безопасно опробовать.

Чего боятся программисты?

А на "бояться" как-то время не уходит. В проект только недавно внедрили автоматическое тестирование, а кодовая база уже немаленькая. Поэтому тестами покрываются сначала самые важные части системы, без которых функционирование сервиса будет совсем невозможным (Unit тестирование, тестирование API и п.р.); тестирование очень хрупких частей, изменение которых может повлечь за собой неадекватную реакцию на действия пользователей (в нашем случае — это тестирование правильного распределения прав доступа); а потом на то, что сломалось, стараюсь написать тест и поправить ошибку. Естественно, при внедрении новых функций стараюсь писать тесты, если это необходимо.

Чего боятся программисты?

Все бы ничего, но если ты один кодер/верстальщик/дизайнер/тестер на весь проект, то времени и сил тестить "побольше" как-то совсем нет.