ReactJS *

Ну что ж, начнем с того, что такое GraphQL?

Перевод. Оригинал по ссылке.

В некоторых случаях компилятор TypeScript вставляет вспомогательные функции в сгенерированный JavaScript код, которые потом вызываются во время исполнения. Каждая такая вспомогательная функция эмулирует семантику особенности языка, которая ещё не поддерживается браузерами нативно.

В настоящее время в TypeScript существуют следующие вспомогательные функции:

• __extends для наследования
• __assign для spread оператора
• __rest для rest оператора
• __decorate, __param и __metadata для декораторов
• __awaiter и __generator для async/await

16 сентября 2017 года вышла React Fiber — новая мажорная версия библиотеки. Помимо добавления новых фич, о которых вы можете почитать здесь, разработчики переписали архитектуру ядра библиотеки. Я как React-разработчик решил разобраться, что за зверь этот Fiber, какие задачи он решает, за счёт чего и как в итоге можно применить полученные знания на проектах, над которыми я тружусь в компании Live Typing. Разобрался и пришёл к неоднозначным выводам.

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

Когда приходишь на конференцию, кажется, что всё работает само собой. Всегда есть интересный доклад. В нём есть конкретные места, которые можно использовать в работе прямо сейчас, которые стоит обсудить с друзьями и коллегами или которые просто почему-то цепляют тебя лично.

Это происходит само собой, просто по статистике? Если набрать достаточное количество докладов, всё получится автомагически? Как бы не так. Всё подстроено. Как программу на JS проектируют архитекторы, так и за каждой конференцией стоит команда отличных инженеров, которые проектируют её специальным образом. Они проектируют не только структуру, но и вместе с докладчиками «отлаживают» каждый доклад, строчка за строчкой, раз за разом. Проводят кросс-ревью, оценку, починку багов. Пишутся специальные инструменты и выкладываются на GitHub. И так до тех пор, пока не скомпилируется хорошо работающая, безбажная конференция.

Наверное, каждый иногда хотел пообщаться с разработчиками тех инструментов, которыми мы все пользуемся. К примеру, кто хотел бы сказать пару ласковых создателям React или Node.js? А кто хотел бы узнать от них парочку тайн о внутренней кухне проекта?

Это интервью — с разработчиками конференции HolyJS 2017 Moscow, с её Программным комитетом. Мы будем обсуждать:

• какие сложности возникают при разработке программы конференции и как их побеждают;
• кто допущен к сакральному процессу отбора докладов и нужно ли для этого быть богом JavaScript;
• совместима ли работа в ПК с обычной жизнью;
• какие доклады стоит послушать и на какие ни в коем случае не стоит приходить хипстерам;
• кучу рандомных интересных фактов.

• Компоненты React.
  
• Рендеринг ReactDOM.
  
• Классы компонентов и функциональных компоненты.
  
• JSX.
  
• Состояние (state).
  
• Обработка событий.
  
• Асинхронный метод setState.
  
• Свойства (props).
  
• Ссылки (refs).
  

Уважаемые коллеги, представляю вашему вниманию и на ваше осуждение контейнер для управления состоянием React приложения xstore. Он определенно является таким маленьким детским велосипедом рядом с большим и сверкающим мотоциклом Redux. Все мы программисты JavaScript являемся такой большой и не сбавляющей обороты фабрикой по производству велосипедов.

Для более менее просто начинающих или начинающих свое знакомство с React JavaScript программистов Redux может показаться несколько сложной штукой, которая иногда непонятно как работает и к которой сложно "законнектиться", хочется чего-то попроще, чего-то похожего на данный маленький велосипед.

Давайте рассмотрим его поближе.

Установка

npm install --save xstore

У меня проблемы с поиском фронтенд-разработчика, в основном, по WP, Foundation, CSS, JS, на низкоуровневую позицию. Не могу понять, в чём дело. Ни у кого из кандидатов нет «базовых знаний» ничего из перечисленного. Но они могут делать сайты на React или других JS-фреймворках, или на базе WP-шаблонов. Но если я говорю, что нужно сделать простые изменения в CSS, смотрят пустыми глазами… Или какую-нибудь мелочь на чистом JS, ничего.

Время чтения: 13 минут

Всем йо, хабражители.

В общем, так вышло, что я пишу на JavaScript уже довольно долго, и одной из самых главных задач всегда была организация состояния приложения.
TL; DR;
Нет ничего привычнее на свете,
Чем писать колесо на велосипеда

Что-то хочется кешировать, что-то обновлять, причем обновлять везде, а не только в локальном компоненте, не хочется перерисовывать весь компонент если поменялся весь Store (shout out to Vuex), а хочется подписываться на то, что используешь (shout out to MobX).

Разработчики React тяготеют к функциональному подходу, но с появлением MobX, появилась возможность работать с состоянием в более-менее привычном ООП-стиле. Mobx старается не навязывать какую либо архитектуру, позволяя работать с реактивным состоянием, как с обычными объектами. При этом он делает автоматическое связывание вычислений, когда достаточно написать C = A + B, чтобы при обновлении A, обновился и C.

В HelloWorld это выглядит просто, но если мы добавим fetch, отображение статусов загрузки и обработку ошибок, мы увидим, что получается много копипаста, а в код начинают просачиваться хелперы вроде when, fromPromise или lazyObservable. И уже не получается писать код так, как будто нет асинхронности. Я хочу разобрать некоторые подобные примеры в MobX и попытаться улучшить его базовую концепцию, развив идею псевдосинхронности.

На примере обычного блога (получение из API данных для post-comments), продемонстрирую, как покрываю тестами redux-слой. Исходники доступны тут.

Введение