Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Отказаться от сущности element #155

Open
sk1e opened this issue Oct 21, 2019 · 2 comments
Open

Отказаться от сущности element #155

sk1e opened this issue Oct 21, 2019 · 2 comments

Comments

@sk1e
Copy link
Contributor

sk1e commented Oct 21, 2019

Мы сейчас разделяем компоненты из shared/view на components и elements. Это течёт отсюда:

image

но я не вижу в этом смысла.

Декомпозиция на уровни использования между собой не нужна т.к. это не имеет значения при использовании. Нам нужна shared компонента и нам всё равно на каком уровне она находится. Нам приходится об этом думать во время импорта и вспоминать что на каком уровне находится. Делать поиск сначала в components, потом в elements. Думать об этом когда добавляем компоненту, решать на какой уровень добалять. Перемещать эти компоненты между каталогами, когда уровни изменились, править по всем проекту импорты которые зависили от этих уровней.

В моей практике компоненты всегда имели древовидную зависимость и никогда не имели циклическую.

Даже если и возникнет циклическая, то непонятно как это разделение решит проблему.

И в целом, это разделение не сформулировано в полной мере и из него непонятно что куда класть.

@NikitaRzm
Copy link
Contributor

В доке по аритектуре я может не полностью раскрывал все мысли на этот счет (было давно и я имел мало опыта), но выразил это словом декомпозинг - косяк согалсен. Сейчас уже сложно вспомнить все профиты, но я подскажу, куда копать.

Atomic design - в целом как подход для дизайна интерфейсов (и как следствие части дизайна архитектуры представления на фронте).

http://atomicdesign.bradfrost.com/chapter-2/ - это из гугла нашел, там схожие термины с архитектурой, которую используют пацаны в Тинькове. Атомы, молекулы, организмы и т.д.
Прежде чем точно отказаться, стоит подумать про усовершенствование. Я в целом всегда за упрощение и вынести все в компоненты выглядит логично и круто. Но обобщив весь фидбэк по модулям, элементам (микрофичам прости господи), призываю изучить эту методологию и взять или не взять лучшее из того что она предлагает. Но при этом не усложнять восприятие при разработке архитектуры и раскладки компонентов дизайна на фронте.

@kinda-neat
Copy link
Contributor

http://atomicdesign.bradfrost.com/chapter-2/ - это из гугла нашел, там схожие термины с архитектурой, которую используют пацаны в Тинькове. Атомы, молекулы, организмы и т.д.
Прежде чем точно отказаться, стоит подумать про усовершенствование. Я в целом всегда за упрощение и вынести все в компоненты выглядит логично и круто. Но обобщив весь фидбэк по модулям, элементам (микрофичам прости господи), призываю изучить эту методологию и взять или не взять лучшее из того что она предлагает. Но при этом не усложнять восприятие при разработке архитектуры и раскладки компонентов дизайна на фронте.

Дэ, надо будет изучить, здесь вся пачка статей из ресурса выше http://atomicdesign.bradfrost.com/table-of-contents/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants