Цикада откладывает личинку в землю. Та в земле питается и развивается от 13 до 17 лет. Летом вылезает на поверхность. Они без крыльев в жестком панцире. Закрепляется на ветке, и из личинки вылезает зеленая цикада, расправляет крылья в течении 10-15 минут. Затем сидит, ждет пока зеленый хитиновый панцирь отвердеет и цикада станет совсем взрослой с крепкими крыльями и прочной тушкой.
Весьма кайфовый процесс, который я пронаблюдал в парке в своем родном городе.
Весьма кайфовый процесс, который я пронаблюдал в парке в своем родном городе.
Отображение процессов браузера от ввода URL до финального рендера в виде MindMap
https://kinopio.club/the-browser-when-you-click-a-link-JFYdfq5YKvM1f9A9K3XcI
https://kinopio.club/the-browser-when-you-click-a-link-JFYdfq5YKvM1f9A9K3XcI
Как я именую функции, классы, компоненты, ивенты, сторы.
Так как большую часть времени мы читаем код, а не пишем его, то хочется легко воспринимать существуюшие части кода. Стоит помнить, что мы далеко не всегда пишем полностью новый код. В существующем проекте мы используем уже созданные ранее переменные, сущности и модули.
Во всех IDE есть функция автоимпорта сущности по имени. Многие ею успешно пользуются, в том числе и я. Да даже без этой функции совет из этого поста актуален. Ведь зачастую импортнув сущность однажды она используется больше одного раза в модуле.
А ещё есть такая штука как автодополнение ввода. Давайте разберемся как оно работает: пишем какие-то буквы, IDE анализирует контекст и ищет сущности по входящим в него символам. Притом, введенные символы должны идти в названии сущности ровно в том же порядке в каком были введены.
Например: введено "rsp", будет найдено "responseType", но не "scopeDescription".
Так как большую часть времени мы читаем код, а не пишем его, то хочется легко воспринимать существуюшие части кода. Стоит помнить, что мы далеко не всегда пишем полностью новый код. В существующем проекте мы используем уже созданные ранее переменные, сущности и модули.
Во всех IDE есть функция автоимпорта сущности по имени. Многие ею успешно пользуются, в том числе и я. Да даже без этой функции совет из этого поста актуален. Ведь зачастую импортнув сущность однажды она используется больше одного раза в модуле.
А ещё есть такая штука как автодополнение ввода. Давайте разберемся как оно работает: пишем какие-то буквы, IDE анализирует контекст и ищет сущности по входящим в него символам. Притом, введенные символы должны идти в названии сущности ровно в том же порядке в каком были введены.
Например: введено "rsp", будет найдено "responseType", но не "scopeDescription".
А если сложить всё вместе, можно заметить интересный паттерн. Неважно, в какой парадигме ведется разработка, всегда есть некий объект и методы.
В ФП это будет
в ООП-like
И мы как разработчики всегда знаем, с каким объектом работаем в данный момент, но не всегда знаем какие методы есть у него. Поэтому для нас важнее объект, ведь можно ввести имя объекта и IDE предложит, что с ним можно сделать. В ФП это может работать через pipe/compose или оператор
Зачастую большое количество используемых методов удобно импортировать в область имен:
Тогда формат вызова превращается в
На самом деле компоненты проектируется ровно также как методы в ООП или ФП — выполняют только одну четко определенную задачу. А значит, вполне могут быть именованы в похожем формате. Только
Примеры:
Ровно та же схема работает и с классами. Достаточно почитать книги с примерами по джаве. То же самое с методами и функциями. Внезапно, это работает с именами переменных и констант. При этом введя
Главный принцип — от общего к частному.
В ФП это будет
method(object, arg)в ООП-like
object.iss.onethod(arg)И мы как разработчики всегда знаем, с каким объектом работаем в данный момент, но не всегда знаем какие методы есть у него. Поэтому для нас важнее объект, ведь можно ввести имя объекта и IDE предложит, что с ним можно сделать. В ФП это может работать через pipe/compose или оператор
|>. А может быть через ковенцию objectAction. И тогда всё будет работать ровно как в ООП-like objectAction(object, arg), не нужно бояться дублирования object здесь, ведь переменная почти никогда не называется по имени сущности.Зачастую большое количество используемых методов удобно импортировать в область имен:
import * as namespace from "...".Тогда формат вызова превращается в
namespaceObjectAction(object, arg).На самом деле компоненты проектируется ровно также как методы в ООП или ФП — выполняют только одну четко определенную задачу. А значит, вполне могут быть именованы в похожем формате. Только
action превратится в variant, ведь компоненты сами по себе не выполняют действий, они могут быть разных вариантов отображения.Примеры:
Button, ButtonPrimary, Input, InputMask, InputPassword. Это всё описано в формате ObjectVariant. Если добавить namespace, то получится такое: Form, FormField, FormFieldPrimary, или же Form.Field тут уж как удобнее.Ровно та же схема работает и с классами. Достаточно почитать книги с примерами по джаве. То же самое с методами и функциями. Внезапно, это работает с именами переменных и констант. При этом введя
namespace в IDE, можно увидеть все входящие объекты, дописав или выбрав нужный объект namespaceObject, можно увидеть всего варианты и/или действия.Главный принцип — от общего к частному.
Ну что.
Неделя началась — https://twitter.com/jsunderhood/status/1277501157447958534
Накидывайте свои вопросы или ещё что, буду отвечать
Неделя началась — https://twitter.com/jsunderhood/status/1277501157447958534
Накидывайте свои вопросы или ещё что, буду отвечать
Twitter
jsunderhood
Всем доброго утречка. Я Сергей Сова (@_sergeysova). Я лид фронтовой команды Питерского @REDMADROBOT. Меня беспокоит архитектура современного фронтенда на реакте и ему подобных. Изредка появляюсь с докладами и подкастами. Расскажу о методологии FeatureSlices…
Все треды из jsunderhood про архитектуру и FeatureSlices перенес в канал по теме:
https://t.iss.one/feature_slices/50
https://t.iss.one/feature_slices/50
Telegram
Feature Slices
Список тредов про архитектуру и FeatureSlices с jsunderhood: