Сегодняшние занятия учебного курса по React, перевод которого мы публикуем, посвящены продолжению работы над TODO-приложением и свойствам компонентов.



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

Представленные на рынке системы хранения данных, в основной своей массе, мало чем отличаются друг от друга, ведь многие вендоры заказывают оборудование едва ли не у одних и тех же ODM-производителей. У нас же почти все свое, начиная от шасси и заканчивая контроллерами, технологиями типа RAID 2.0+ и софтом.



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

Задаетесь вопросами: «Как написать чисто, понятно? Как быстро разобраться в чужом коде?»

Вспомните о приведенных ниже правилах и примените их!

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

Рассмотрим процесс восприятия данных, чтобы соотнести описанные правила с процессом восприятия и определить критерии простого кода.

Упрощенный процесс восприятия состоит из следующих этапов:

1. Поступающая через рецепторы данные соотносятся с предыдущим опытом.
2. Если соотнесения нет – это шум. Шум быстро забывается. Если есть с чем соотнести, происходит опознавание фактов.
3. Если факт важен — запоминаем, либо обобщаем, либо действуем, например говорим или набираем код.
4. Для сокращения объема запоминаемой и анализируемой информации используется обобщение.
5. После обобщения, информация вновь соотносится и анализируется (этап 1).

Введение

Итак, мы уже определились с областью применения, методологией и архитектурой. Перейдем от теории к практике, к написанию кода. Хотелось бы начать с шаблонов проектирования, которые описывают бизнес логику — Service и Interactor. Но прежде чем приступить к ним, изучим структурные паттерны — ValueObject и Entity. Разрабатывать мы будем на языке ruby. В дальнейших статьях разберем все паттерны, необходимые для разработки с использованием Вариативной архитектуры. Все наработки, являющиеся приложениями к данному циклу статей, соберем в отдельный фреймворк.

И мы уже подобрали подходящее название — LunaPark.
Текущие наработки выложенны на Github.
Разобрав все шаблоны, соберем один полноценный микросервис.

Предисловие

Важно! Если Вам хочется побыстрее приступить к технической стороне дела – просто пропустите эту главу.

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

Кстати картинка «человека дождя» на заглавной не просто для привлечения внимания и именно для этого в повествование добавлена «лирика», все события, имена и прочее есть суть фантазии автора. Как обычно, никто ни за что не несет ответственности :)

Многие студенты, впервые сталкиваясь с описанием какой-нибудь хитроумной штуки, вроде алгоритма Кнута – Морриса – Пратта или красно-чёрных деревьев, тут же задаются вопросами: «К чему такие сложности? И это, кроме авторов учебников, кому-нибудь нужно?». Лучший способ доказать пользу алгоритмов – это примеры из жизни. Причём, в идеале – конкретные примеры применения широко известных алгоритмов в современных, повсеместно используемых, программных продуктах.



Посмотрим, что можно обнаружить в коде ядра Linux, браузера Chromium и ещё в некоторых проектах.