желания — проблемы — решение — решения — продукт — обновление

1, процесс реализации продукта — это процесс определения продукта.

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

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

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

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

6, он остается неизменным при изменениях.

==============

Кодирование — это акт сокращения вычислений.

==============

app
├── comps
│   ├── strucs
│   ├── styles
│   ├── anims
|   └── events
│       └── anims
└── data
    ├── api
    ├── utils
    └── db

1, мы определяем голую структуру продукта. Как набросок от руки. В целом он взаимодействует с другими, поэтому мы должны определить его как набросок объекта.

Этот уровень имеет самый низкий уровень неизменности. Что означает высокий уровень абстракции. Позже мы можем указывать на него, называть его, говорить о нем со всей легкостью.

2. определяем стили. на этом уровне мы определяем только его пространство и расположение основных форм, что может дать нам первый уровень удобства использования. Только он привлекательный и простой в использовании, люди действительно будут его использовать. этот уровень определения может измениться, но только с достаточной детализацией. На этом уровне мы используем заполнители и утилиты начальной загрузки.

3 мы определяем анимацию (сложный стиль), которая во многом основана на времени и общих действиях. Теперь продукт запущен, GIF-движение страницы начинает оживать.

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

причина, по которой мы разделяем анимацию со стилем, заключается в следующем:

I. разного уровня сложности. Большая часть анимации делается с помощью js, а не css.

II. если это слишком сложно, он определенно должен отделиться от своего окружения.

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

На основе других существующих объектов, которые вы определили.

На ощупь как руки Скетчи с минимумом логических взаимосвязей.

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

Базовой структурой может быть только ее положение.

Иерархия контейнеров

2 основных стиля: (СТИЛИ) Высококачественный внешний вид без лишних деталей и ожидание дальнейших параметров для его изменения.

Ну, это доходит до уровня проектирования Bootstrap. Но не слишком много отшлифованного дизайна. Просто небольшая демонстрация этого.

Пока нам нужны базовые стили, потому что мы не слишком много знаем о глобальной спецификации дизайна. Что мы понимаем под синим? Который будет определяться более высоким уровнем командования. Но пока мы только знаем, как бы глобально это ни выглядело, это должно очень понравиться.

3 основных анимации: (ANIMS) трансформация внешнего вида на основе времени. (изменения автоматики)

Анимация — это просто степень стиля. Стиль меняется со временем.

3.1 автоматические изменения: (АВТО), что означает, что это течение времени, как просмотр видео. Он не требует какого-либо пользовательского ввода или команды. Единственное, что может сделать пользователь, это приостановить его, но большую часть времени мы требуем, чтобы они смотрели эти быстрые изменения изображений в качестве обязательства.

3.2 изменения на основе событий: (СОБЫТИЯ) Я думаю, что элемент не должен знать, какое событие, ему важно только, как реагировать. Как и в css, мы добавляем или удаляем класс в div, и анимация выполняется автоматически. Как же это круто.

4. Обработка событий (СОБЫТИЯ): ввод данных пользователем (щелчок, наведение, изменение, отправка, перетаскивание и т. д.)

Эту штуку иногда называют View Controller. Как представление должно реагировать, когда происходит событие. Мы заботимся только о внешнем виде, а не о данных CURD.

5 Подача данных: (ДАННЫЕ)

5.1 API (API): данные должны поступать от API, который предоставляет или получает только необработанные данные.

5.2 Утилиты модели (UTILS): жесткая логика для вычисления входящих данных, отправки их пользователю или сохранения в базе данных.

5.3 Реализация базы данных (БД): не следует много знать о том, как взаимодействовать с базой данных.

6 сложных стилей: это должна быть какая-то утонченная работа.

7 Сложная анимация: Это также должно быть изысканной работой.

8 Производственный сервер