Електроніка, схеми, плати, статті - сторінка 3

Почему Flask

Почему именно Flask? Flask – фреймворк, который поражает своей простотой и богатством функционала. Он не навязывает разработчику конкретную базу данных или конкретные подходы. Вы можете освоить его базовые функции за один вечер. Что с одной стороны обеспечивает легкий старт, а с другой Flask обладает могучими функционалом, который можно изучать месяцами, удивляться и радоваться.

В этой начальной серии примеров будут показаны простые, но достаточные приемы для разработки простых web - приложений. Основной задачей этих примеров создать beckend и подружить его с frontend – ом. Формат выдачи данных - JSON.

Відео про те, як оцінити потужність саморобного BLDC двигуна.

Розрахунок потужності BLDC двигуна (приблизний):
https://blog.avislab.com/uploads/motor/

Отдельный роут для редактирования данных

Традиционно для редактирования данных делают отдельный роут. Это удобно особенно если нужно коллегам скинуть ссылку на конкретный товар, карточку клиента и т.п. Согласитесь, проще поделиться ссылкой типа https://myproject.com/#/client/135, нежели глупо рассказывать куда зайти на какой странице куда нажать для просмотра или редактирования.

Для реализации этого функционала сделано два отдельных роута. Для просмотра списка path: '/client' (используется компонент client), и для редактирования path: '/client/:id' (используется компонент client-edit):

Стандартный компонент

Представьте, что вам нужно сделать десятки интерфейсов для заполнения каких-нибудь данных в своем приложении. Данные однотипные и интерфейсы так же похожи один на другой. Для таких целей логично сделать универсальный компонент, чтобы можно было перечислить поля с их типами, свойствами и все работало само. Именно это реализовано в этом примере. А именно сделан компонент standard-page, который включает в себя ранее созданные компоненты standard-table, standard-form. В результате мы получаем компонент, который постранично выводит данные в табличной форме с сортировкой, фильтром/поиском, с формой для редактирования, возможностью добавления и удаления записей.

В файле приложения описана константа const appDataset. В ней собрано описание полей всех компонент в одном месте. Вы можете поступить по другому. Или скажем, вообще загружать эти данные из отдельного файла.

md-dialog для Vue

В этом примере используется md-dialog для создания диалоговых окон. Форма для редактирования данных превращена в диалоговое окно. Использован шрифт fontawesome для создания иконок. Сделаны диалоги alert, confirm, confirm3btn, prompt. Перед удалением записи запрашиваться подтверждение. В приложение добавлена система нотификаций (Notifications). Компонент notification отображает всплывающие сообщения, информирующих пользователя о каких либо событиях. Сообщения исчезают через определенное время.

Динамическая загрузка компонент

В этом примере компоненты разделены на отдельные файлы и сделана система динамической загрузки компонент. Разумеется, во Vue есть шикарный механизм разделения приложения на чанки, и при переходе к системам сборки нужно использовать возможности фреймворка. Этот пример лишь демонстрация того как это можно легко сделать и на сколько Vue гибкий инструмент. Для загрузки компонент используются навигационные хуки vue-router.

Стандартная таблица. Минимизируем код.

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

Применяя компонент standard-table, мы легко сможем реализовать вывод других данных Seller и Product с тем же функционалом (сортировка, фильтр/поиск, постраничный вывод и т.д.). При этом нам достаточно перечислить нужные поля и задать им свойства.

Таблица - трансформер

В этом примере продолжаем дорабатывать компонент client.

Поскольку web - приложение должно нормально работать и на мобильных устройствах, сегодня займемся отображением таблицы. На мобильных устройствах табличное представление данных приносит пользователям страдания и при малой ширине экрана крайне не удобны в работе. Я сделал несколько компонент, с помощью которых можно легко сделать универсальную адаптивную таблицу. Она будет выглядеть как таблица на десктопной версии и как «плиточки» на мобильных устройствах.

Сортировка, поиск

В этом примере продолжаем дорабатывать компонент client.

Добавлен компонент header-order. С его помощью заголовки таблицы могут быть сделаны «кликабельными» и при клике менять направление сортировки соответствующего столбца. Обратите внимание как этот компонент используется в компоненте client-table и как он работает со slot-тами.

Постраничный вывод данных

Продолжая тему разделения полномочий и обязанностей в приложении, будут созданы компоненты по следующему принципу: Родительский компонент будет взаимодействовать с backend-ом, работать с данными и отдавать их дочерним компонентам. Дочерние компоненты будут отображать данные и при необходимости выполнить какие либо операции с данными, будут передавать «родителю» события, но сами изменять данные не будут. Родитель получив событие будет выполнять операции с данными и раздавать их дочерним компонентам.

Во фреймворке Vue реализован удобный механизм примесей (mixins). Вы можете создать объект, который будет подмешиваться к создаваемой компоненте. Можно сказать и другими словами — можно создать объект или несколько объектов на основе которых будет создан компонент. Это не то чтобы наследование, просто Вы можете вынести повторяющиеся методы в отдельный миксин и указывать его при создании компоненты. И все, что Вы укажите в миксине будет перенесено в компонент. Используя миксины можно эффективно устранить куски повторяющиеся кода.

CRUD

В этом примере освоим работу с данными используя подход CRUD (создание (create), чтение (read), обновление (update), удаление (delete)).

Именно понимание основного замысла этого подхода облегчит в будущем разработку и поддержку больших и сложных приложений. В данном примере мы создадим четыре отдельных метода для работы с данными. Каким бы сложным не казалось приложение или структура данных, можно обойтись этими четырьмя методами. Мало того, если backend для любой сущьности будет реализовывать все 4 метода, то frontend сможет реализовать интерфейс любой сложности и любого вида. Крайне желательно чтобы стандарт работы и формат выдачи данных на backend-е не менялся от одной сущьности к другой и выдерживался стандарт. В этом случае Вы сможете создать стандартные компоненты для работы с данными (что и будет продемонстрировано в следующих примерах). В реальной жизни, долгоиграющие проекты страдают болезнью, которую я называю «наслоение исторических слоев». Приходят новые технологии, backend состоит из разных составных частей, backend пишут разные люди/группы, и получается что могут быть совсем не похожие форматы данных. И если здесь не будет стандартизации, это все придется разгребать фронтенду. И мы будем строить такую структуру приложения, чтобы оно в любом случае смогло.