Не для запуска людей ее делают. Даже если получится запускать только кубсаты с ограниченным функционалом (не каждый прибор выдержит), все равно это будет огромным достежением и клиенты найдутся.
Это не только про реакт.
Есть такой подход к разработке CDD (Component Driven Development), он подразумевает, что вы сперва пишите независимую от функционала компоненту, как правило в изоляции от приложения и от реальных данных, этакий example. И только потом уже собираете из таких компонент проект. Storybook — это библиотека позволяющая вести разработку компонент в изоляции, составлять каталоги компонент, показывать различные примеры использования каждой компоненты.
В контексте моего комментария, storybook — файл с примерами использования компоненты.
Далеко не все его используют, да и с ростом популярности bit, storybook можно и не рассматривать как необходимость.
data — ok
dataComponents — только компоненты которым нужен data в зависимостях, NicknameInput — это уже скорее часть модуля — input который отображает текущее значение в сторе.
forms — нет, здесь место для TextField, NumberField, Select. NicknameField — слишком специфичный
modules — ok
Вы не поняли назначение каталогов.
Все компоненты в components — это реализация дизайн системы проекта.
Допустим дизайнер передумал и решил что селекты в проекте должны быть кругленькими — изменение на уровне components.
Если нужно добавить новое поле в модуль, а подходящая компонента еще не разработана — создается новая компонента в components, делается обертка этой компоненты в forms и эта обертка используется в modules.
Наболевшая тема.
На текущий момент пришел к структуре:
/components — базовые компоненты (кнопки, поля ввода, и т.д.) с запретом импорта других частей приложения
/data — функции общения с бекендом для абстрагирования
/dataComponents — компоненты с данными полученными с бекенда (CountrySelect например)
/forms — обернутые компоненты в redux-form Field, для более DRY форм
/layouts — компоненты без логики определяющие позиционирование компонент внутри себя и адаптацию под разные размеры экрана
/pages — компоненты на которые ссылаются роуты, не содержат в себе логики кроме передачи параметров роута (для абстрагирования от роутинга) и определения лэйаутов
/modules — независимые друг от друга части приложения с бизнес-логикой, как правило у каждого свой редюсер(ы)
В каждой папке свой eslint для запрета импорта некоторых сторонних библиотек или частей приложения и readme для справки
Получается следующая вложенность при реализации функционала:
Page-Layout-Module-Form-DataComponent-Component
Каждая компонента оформляется как
ComponentName/ — папка для группировки всего что относится к компоненте
— index.js — код компоненты
— ChildComponentName.js — код дочерней компоненты при декомпозиции
— ComponentName.test.js — юнит тесты компоненты
— stories.js — storybook для компоненты
— *.png/*.svg — всякие разные ресурсы компоненты
И я все еще не доволен результатом.
Разделение на папки важно, и чем их больше тем лучше проект документирует себя.
У меня не breadboard, все на платах делаю, макетки правда, но дорожки солидные, от флюса отмываю всегда. Проблема в другом, делаю к примеру набор датчиков на MySensors для аквариума, естественно каждый из датчиков на проводе ~1м, один погружен в аквариум, другой рядом с двигателем фильтра, третий рядом с розеткой, рядом еще управление вентиляторами охлаждения и помпой долива воды. Очень много источников помех. Когда слепо начинаю добавлять подтягивающие резисторы да конденсаторы помехи начинают уходить, но не полностью, местами приходится довольно долго подбирать чтобы эффективность была максимальной. В казалось бы воссозданных максимальных помехах все начинает работать, а при подключении схемы обратно к аквариуму помехи опять мешают работать. Не уверен что одними только показаниями логического анализатора можно упростить наладку. Очень не хватает именно «видеть» шумы.
Спасибо за наводку на анализатор. Почитал что это и как пользоваться, заказал, поиграюсь с ним через месяц-другой.
Вижу что он поможет решить только часть проблем, но гораздо лучше чем дешевый осциллограф.
По шумам вопрос остается открытым. Анализатор мне явно не поможет определить шумы, кроме того щупы анализатора судя по всему могут уменьшить шумы своими подтягивающими резисторами и конденсаторами.
Столкнулся с тем, что мои i2c датчики работают «через раз», вероятно проблема в шумах, которые пришлось устранять вслепую. Шумы я конечно устранил, передача данных стабилизировалась, но с тех пор думаю о том что осциллограф дома нужен. Но т.к. я тот еще дилетант в этой области, покупка хорошего инструмента будет неоправданна, только зря пылиться будет, нужно выбирать максимально бюджетную модель чтобы закрыть 3 пункта: научиться пользоваться инструментом, иметь возможность отладки i2c, uart без необходимости чтения данных, а только стабилизации сигнала и возможность видеть шумы питания критические для МК.
Подскажите пожалуйста, какая должна быть полоса пропускания для определения шумов i2c какого-нибудь 16MHz МК, ардуинки, например. Вычитал, что нужно частоту МК умножить на 5 получается 80MHz, но передача данных как правило идет на более низких частотах, не будет ли такой прибор избыточным? Опять же, если я не планирую читать данные, хватит ли мне одноканального осциллографа?
Писать велосипеды хорошо для самообразования и допустимо только в личных проектах. Когда появляется желание написать свой Redux, подумайте о своей команде, которой придется все это изучать. Вы искусственно завышаете порог вхождения в проект.
Вариант описанный в статье выглядит более удобным.
То что описано в документации не работало для меня т.к. для action типов я использую константы (duck) с шаблонными строками, пример из документации отказывался адекватно работать с константами по какой-то непонятной мне причине.
Но даже если бы он работал, все равно пример из документации недостаточно удобен.
Спасибо большое за статью. Описанные проблемы действительно существуют, куча статей написана, люди продолжают искать наиболее оптимальный способ типизации в Redux. Не могу сказать, что решение идеально, но в сравнении с другими выглядит довольно неплохо.
У меня вопрос к сторонникам flow.js: кто-нибудь пробовал реализовать подобное, все работает?
Это не проблема css-in-js, как раз наоборот, вам нужно хранить конфигурационные значения в теме, и при указании цвета вашей кнопки, использовать значение из темы. Если нужно поменять цвет по требованию дизайнера, вы меняете цвет в теме. Если нужно менять тему динамически, пользователем, тоже самое — даем пользователю или набор тем или доступ к изменению отдельных параметров темы.
Самое ироничное в этом то, что это не React подход, не JS подход, а практика которой уже не один десяток лет, css-in-js дает вам возможность использовать ее безболезненно.
Material UI, кстати предоставляет этот подход из коробки.
Я с вами не согласен. Ваши выводы обо мне не верны, ваши доводы субъективны и агрессивны.
Скажу только, что это было большой ошибкой хабра, разрешать писать комментарии всем. На вашем примере я это осознал в полной мере, спасибо.
Если вы знаете React отлично, то для вас не секрет, что React поощряет разделение приложения на компоненты, а компоненты на еще более маленькие компоненты, чем меньше компоненты, тем больше выигрыш в производительности. Если вы стремитесь следовать этой декомпозиции, то придете к тому, что большинство компонент будут требовать буквально парочку css классов. Выносить 5-10 строк в отдельный файл — это красиво, но не практично. Каждый раз создавая компонент, создавать для него index.js, styles.css, template.jsx становится очень утомительным для рядовых разработчиков, все чаще хочется написать эти 5 строк стилей прямо в MyComponent.js
При разделении компоненты на отдельные файлы, вы должны позаботиться о грамотной файловой структуре приложения. Вы ведь не хотите чтобы быстрый поиск в вашей IDE стал менее удобным? А теперь подумайте, если стили хранятся в styles.css или код компоненты в index.js, быстрый поиск файла должен включать в себя и название каталога. А открыв несколько файлов стилей вы получите в IDE несколько открытых styles.css, если ваша IDE еще и не отображает путь к файлу, то найти нужный становится сомнительным удовольствием. Если вы исправляете эту проблему более информативными наименованиями файлов стилей, пример: MyComponentStyles.css, то нарушаете принцип чистого кода о наименованиях, извиняюсь, но не вспомню точную формулировку.
Теперь давайте вспомним про шум вокруг JSX. JS сообщество было очень недовольно тем что смешали JS и Html, основным доводом были либо ваше субъективное
Всю жизнь программисты боролись за разделение логики, бэка, фронта и стилей.
либо о нарушении Single Responsibility принципа. В первом случае да, так и было, но не забывайте о том что долгое время JS был просто скриптом для веб разработки, инструментом для анимации меню. Но язык развивается, развиваются и инструменты вокруг языка, сегодня мы пишем на JS приложения не уступающие десктопным и логично будет предположить, что старые ценности должны остаться в прошлом, а не мешать развитию и будущему языка. Второй довод в корне некорректен т.к. разделение компонент на разметку, стили и код не является Single Responsibility принципом, и объединение их в один файл не является нарушением этого принципа. Код, разметка и стиль компоненты являются единым целым, они не должны существовать отдельно. Если вы хотите возразить DRY принципом, то имейте в виду, если мы говорим о React, то DRY реализуется здесь при помощи HOC или RenderProps, а не импортом стилей из других компонентов.
Теперь о CSS-in-JS. Давайте говоря об этом думать не о css, а о различных sass, less, postcss, stylus… Все это — попытки дать css какие-либо возможности ЯП. Сперва придумывается новый css ЯП, затем его нужно изучить, затем появляется что-то лучшее, опять учить. Появление CSS-in-JS это вполне логичный шаг если собрать весь предыдущий опыт и попытаться сделать все правильно. Теперь мы можем стилизировать компоненты на понятном нам языке, а не изучать очередной ЯП для css.
Vue в этом плане видится мне эталоном, все в одном файле компоненты, с четкими границами где что должно быть.
Кстати, именно большинство, а не тимлид/техлид. Так как читабельность кода и прочие штуки — это важно для всей команды, именно команда будет работать с этим кодом в дальнейшем. А не тот, кто считает себя самым умным.
Категорически несогласен. Команда должна следовать общим правилам оформления кода, зачастую эти правила принимаются для всей компании, а не для отдельного проекта. Именно тимлид должен быть в курсе этих правил и заставлять команду следовать им. Давать команде решать что они считают читабельным кодом нельзя, если большинство за стиль который не принят на уровне компании, то тимлид должен продвигать его на уровень компании, но не команда на уровень проекта. Стоит не забывать о том, что сегодня проектом занимается одна команда, со своими предпочтениями, а завтра его поддерживает другая.
Другой аспект этого вопроса: за код написанный командой всегда в ответе тимлид/техлид, если команда будет решать как писать код, то тимлиду придется придумывать как нести ответсвенность за такой код, а не отстаивать свою точку зрения.
Рассмотрите следующую ситуацию:
Сеньер проводит код ревью джуна, видит подозрительный участок в коде который ему не нравится.
Простое и очевидное решение с точки зрения сеньера — оставить коммент «Плохой код, не делай так, найди способ лучше». Но такой подход по умолчанию неконструктивный т.к. не предлагает вариантов. А конструктивным было бы: изучить задачу джуна, найти решение, предложить это решение джуну. В таких ситуациях сеньер по факту выполняет задачу которую должен был выполнить джун. Это очень накладно и делает джуна избыточным на проекте. Такие случаи конечно случаются не постоянно, но достаточно часто. Поделитесь пожалуйста вашим мнением. Мое — джун должен тратить свое время на изучение задачи и варианты ее решения, а не время сеньера (если это не менторинг программа).
Открыл ссылку — установить приложение нельзя. (Беларусь)
Есть такой подход к разработке CDD (Component Driven Development), он подразумевает, что вы сперва пишите независимую от функционала компоненту, как правило в изоляции от приложения и от реальных данных, этакий example. И только потом уже собираете из таких компонент проект.
Storybook — это библиотека позволяющая вести разработку компонент в изоляции, составлять каталоги компонент, показывать различные примеры использования каждой компоненты.
В контексте моего комментария, storybook — файл с примерами использования компоненты.
Далеко не все его используют, да и с ростом популярности bit, storybook можно и не рассматривать как необходимость.
dataComponents — только компоненты которым нужен data в зависимостях, NicknameInput — это уже скорее часть модуля — input который отображает текущее значение в сторе.
forms — нет, здесь место для TextField, NumberField, Select. NicknameField — слишком специфичный
modules — ok
Все компоненты в components — это реализация дизайн системы проекта.
Допустим дизайнер передумал и решил что селекты в проекте должны быть кругленькими — изменение на уровне components.
Если нужно добавить новое поле в модуль, а подходящая компонента еще не разработана — создается новая компонента в components, делается обертка этой компоненты в forms и эта обертка используется в modules.
На текущий момент пришел к структуре:
/components — базовые компоненты (кнопки, поля ввода, и т.д.) с запретом импорта других частей приложения
/data — функции общения с бекендом для абстрагирования
/dataComponents — компоненты с данными полученными с бекенда (CountrySelect например)
/forms — обернутые компоненты в redux-form Field, для более DRY форм
/layouts — компоненты без логики определяющие позиционирование компонент внутри себя и адаптацию под разные размеры экрана
/pages — компоненты на которые ссылаются роуты, не содержат в себе логики кроме передачи параметров роута (для абстрагирования от роутинга) и определения лэйаутов
/modules — независимые друг от друга части приложения с бизнес-логикой, как правило у каждого свой редюсер(ы)
В каждой папке свой eslint для запрета импорта некоторых сторонних библиотек или частей приложения и readme для справки
Получается следующая вложенность при реализации функционала:
Page-Layout-Module-Form-DataComponent-Component
Каждая компонента оформляется как
ComponentName/ — папка для группировки всего что относится к компоненте
— index.js — код компоненты
— ChildComponentName.js — код дочерней компоненты при декомпозиции
— ComponentName.test.js — юнит тесты компоненты
— stories.js — storybook для компоненты
— *.png/*.svg — всякие разные ресурсы компоненты
И я все еще не доволен результатом.
Разделение на папки важно, и чем их больше тем лучше проект документирует себя.
Вижу что он поможет решить только часть проблем, но гораздо лучше чем дешевый осциллограф.
По шумам вопрос остается открытым. Анализатор мне явно не поможет определить шумы, кроме того щупы анализатора судя по всему могут уменьшить шумы своими подтягивающими резисторами и конденсаторами.
Подскажите пожалуйста, какая должна быть полоса пропускания для определения шумов i2c какого-нибудь 16MHz МК, ардуинки, например. Вычитал, что нужно частоту МК умножить на 5 получается 80MHz, но передача данных как правило идет на более низких частотах, не будет ли такой прибор избыточным? Опять же, если я не планирую читать данные, хватит ли мне одноканального осциллографа?
То что описано в документации не работало для меня т.к. для action типов я использую константы (duck) с шаблонными строками, пример из документации отказывался адекватно работать с константами по какой-то непонятной мне причине.
Но даже если бы он работал, все равно пример из документации недостаточно удобен.
У меня вопрос к сторонникам flow.js: кто-нибудь пробовал реализовать подобное, все работает?
Самое ироничное в этом то, что это не React подход, не JS подход, а практика которой уже не один десяток лет, css-in-js дает вам возможность использовать ее безболезненно.
Material UI, кстати предоставляет этот подход из коробки.
Скажу только, что это было большой ошибкой хабра, разрешать писать комментарии всем. На вашем примере я это осознал в полной мере, спасибо.
При разделении компоненты на отдельные файлы, вы должны позаботиться о грамотной файловой структуре приложения. Вы ведь не хотите чтобы быстрый поиск в вашей IDE стал менее удобным? А теперь подумайте, если стили хранятся в styles.css или код компоненты в index.js, быстрый поиск файла должен включать в себя и название каталога. А открыв несколько файлов стилей вы получите в IDE несколько открытых styles.css, если ваша IDE еще и не отображает путь к файлу, то найти нужный становится сомнительным удовольствием. Если вы исправляете эту проблему более информативными наименованиями файлов стилей, пример: MyComponentStyles.css, то нарушаете принцип чистого кода о наименованиях, извиняюсь, но не вспомню точную формулировку.
Теперь давайте вспомним про шум вокруг JSX. JS сообщество было очень недовольно тем что смешали JS и Html, основным доводом были либо ваше субъективное либо о нарушении Single Responsibility принципа. В первом случае да, так и было, но не забывайте о том что долгое время JS был просто скриптом для веб разработки, инструментом для анимации меню. Но язык развивается, развиваются и инструменты вокруг языка, сегодня мы пишем на JS приложения не уступающие десктопным и логично будет предположить, что старые ценности должны остаться в прошлом, а не мешать развитию и будущему языка. Второй довод в корне некорректен т.к. разделение компонент на разметку, стили и код не является Single Responsibility принципом, и объединение их в один файл не является нарушением этого принципа. Код, разметка и стиль компоненты являются единым целым, они не должны существовать отдельно. Если вы хотите возразить DRY принципом, то имейте в виду, если мы говорим о React, то DRY реализуется здесь при помощи HOC или RenderProps, а не импортом стилей из других компонентов.
Теперь о CSS-in-JS. Давайте говоря об этом думать не о css, а о различных sass, less, postcss, stylus… Все это — попытки дать css какие-либо возможности ЯП. Сперва придумывается новый css ЯП, затем его нужно изучить, затем появляется что-то лучшее, опять учить. Появление CSS-in-JS это вполне логичный шаг если собрать весь предыдущий опыт и попытаться сделать все правильно. Теперь мы можем стилизировать компоненты на понятном нам языке, а не изучать очередной ЯП для css.
Vue в этом плане видится мне эталоном, все в одном файле компоненты, с четкими границами где что должно быть.
Категорически несогласен. Команда должна следовать общим правилам оформления кода, зачастую эти правила принимаются для всей компании, а не для отдельного проекта. Именно тимлид должен быть в курсе этих правил и заставлять команду следовать им. Давать команде решать что они считают читабельным кодом нельзя, если большинство за стиль который не принят на уровне компании, то тимлид должен продвигать его на уровень компании, но не команда на уровень проекта. Стоит не забывать о том, что сегодня проектом занимается одна команда, со своими предпочтениями, а завтра его поддерживает другая.
Другой аспект этого вопроса: за код написанный командой всегда в ответе тимлид/техлид, если команда будет решать как писать код, то тимлиду придется придумывать как нести ответсвенность за такой код, а не отстаивать свою точку зрения.
Сеньер проводит код ревью джуна, видит подозрительный участок в коде который ему не нравится.
Простое и очевидное решение с точки зрения сеньера — оставить коммент «Плохой код, не делай так, найди способ лучше». Но такой подход по умолчанию неконструктивный т.к. не предлагает вариантов. А конструктивным было бы: изучить задачу джуна, найти решение, предложить это решение джуну. В таких ситуациях сеньер по факту выполняет задачу которую должен был выполнить джун. Это очень накладно и делает джуна избыточным на проекте. Такие случаи конечно случаются не постоянно, но достаточно часто. Поделитесь пожалуйста вашим мнением. Мое — джун должен тратить свое время на изучение задачи и варианты ее решения, а не время сеньера (если это не менторинг программа).