Да, я провалил один проект на модном фреймворке, теперь, обжегшись на молоке, приходится дуть на воду ). Когда пишешь на низком уровне — я полностью уверен в себе и результат предсказуем. С фреймвокамми не так — нужно постоянно усиленно грести по течению, в том же реакте появляются новые концепции, в результате чего старые становятся неактуальными. Возможно это кстати причина, по которой линуксоиды до сих пор пишут на Си и GTK+ вместо модных C++, Rust и Qt. Похоже, сейчас мы видим некую стабилизацию, и контекст с хуками наконец-то станут стандартной архитектурой.
можно писать код ванильно и эффективно (а не олдскульно, как выше обозначили)
Это как? В приведенном коде всего 2 проблемы — совмещение логики сториджа с логикой отображения в одно толстом компоненте (хотя последняя тенденция в том же Vue — делить не по технологиям а по ответственности, отсюда и однофайловые компоненты), и использование строк вместо статики. Для маленького приложения это норм. Логика работы с БД выносится на узел выше, по аналогии с Flutter Provider или реактовым useContext() за 10 минут, не ломая при этом всю архитектуру. При этом у меня получился несжатый бандл в 18.5 раз (!) меньше чем упакованный бандл стартового приложения React. Плюс при навигации страницы не рендерятся заново, поскольку целиком хранятся в DOM а не в State, а это означает лучшую отзывчивость.
PS
Я работал на действительно больших проектах, когда в БД полторы тысячи таблиц. Большинство коммерческих веб-приложений примерно в 10 раз меньше. И да, в том большом проекте не было декларативщины и реактивщины — вполне себе олдскульный императивный ООП.
PPSS
Я люблю фукнциональное программирование, но деньги приходится зарабатывать ООП, увы, потому что приходится работать на высоко-нагруженных проектах.
PPPSSS
Сейчас активно изучаю Flutter с прицелом в том числе на WEB-разработку, и бандл у него на маленьких приложениях где-то в 2 раза больше реактового. Кодирование абсолютно в стиле React )
Просто Ionic оборачивает все браузерные API (медиа-девайсы, местоположение, IndexedDB, LocalStorage и проч.) в свои собственные абстракции, чтобы на всех платформах было одинаково. Как пример — я через Ионик сохраняю файл, а под ковром он создает IndexedDB базу с именем Disk, и туда все файлы в виде блобов складывает. В итоге Flutter WEB получается выгодней, да и красивей у него интерфейс. Из фреймворков посматриваю на Stencil, очень близко к ванили, но при этом реактивно.
Ковырнул Ionic-React, демо-приложение. Все модно, на хуках, более ли менее красиво — но релизная сборка: 2.3 мегабайта мимифицированного JS, побитого на 100 файлов. Приложение просто делает фотки и кладет в базу, у меня функционал в три раза больше, а размер исходного JS — 27 килобайт. Если б на тайпскрипте сделал — было бы 15 килобайт. Разница в 85 раз, Карл ! И это еще без редакса с мобиксом.
Для сравнения — на флаттере приложение 1.5 мегабайта одним файлом.
Я ничего не имею против реакта с иоником, и даже наверное буду продолжать на них писать, но это явно инструменты для богатых. Я понимаю, функциональный код проще тестировать, меньше ошибок и т.д. Но линукс написан на голом СИ, и до сих пор работает )
PS
Объем исходного кода одинаков — что на ионике, что на ванили, на ионике даже немного больше за счет длинных имен.
Я буду мужественно грызть кактус использовать контекст. С флаттером получается идентичная архитектура, а я как раз его сейчас изучаю, делаю сравнение Flutter vs Ionic React на простой прикладной задаче.
Главная проблема при работе с контекстом — это поиск shared state и общего предка. Как нам упростить эти шаги? Так как у нас реакт-дерево — это дерево, то у всех компонентов есть общий предок. Давайте хранить все shared state в root'овом компоненте.
Это слишком радикальный прыжок разума ) Поиск общего предка — это не проблема, это задача, если мы хотим слепить приложение из чужих компонентов, или хотим компоненты переиспользовать многократно, или хотим их менять в процессе эксплуатации, короче когда нам нужен локальный стейт с понятным временем жизни.
Баловался когда-то экселем, получив шикарный перфоманс. Но формулы писались сразу в синтаксисе JS, и переводились в код с помощью new Function(). По поводу хранения стейта, понимаете, плоский хэшмэп это шаг назад по сравнению с деревом. Вообще, парадигма MVC сильно переоценена, и сейчас наблюдается некоторый откат к толстым компонентам. Потому что разделяя модель и представление, вам приходится вручную управлять иерархией и временами жизни и вьюшек и моделей. Сложность предметной области удваивается — модели имеют свою иерархию и свой жизненный цикл, вьюшки — свою. В простых случаях можно все модели свалить в «вечный» хэшмап, а если их 1000? Нужно создавать фреймворк по управлению моделями. А потом его реактивно подружить с фреймворком по управлению вьюшками (условный Реакт).
Вот и возникла идея — а давайте будем размещать и модели и вьюшки в едином дереве компонентов с автоматической деструкцией. Получился паттерн контекст-провайдер, наиболее красиво реализованный во Flutter, ссылку на хорошую статью уже приводил habr.com/ru/company/piter/blog/503074
Но тогда получается, что моделька — это просто дополнительный узел в дереве виджетов, и грань между виджетом-моделью и виджетом-представлением сильно истончается. А следующим логическим шагом будет объединение этих 2-х виджетов в один «толстый» компонент, как это сделано в моем коде.
Ну то есть в индустрии существует вечный спор — на какие части нарезать изначальную сложность бизнес-задачи. Можно по технологическим признакам (хранилище — модель — контроллер — вью), можно по бизнес-ответственности (справочник клиентов, операция закупка, операция продажа), а больших приложениях всегда режут и так и так — горизонтально по технологиям, вертикально по функционалу, называется матричная схема. В относительно компактных проектах достаточно оставить только вертикальное деление, то есть толстые автономные однофайловые компоненты. Это уменьшает количество сущностей, файлов, и служебного кода. И делает приложение более живучим, когда каждый компонент содержит внутри логику собственного сториджа, реконнекта к другим компонентам, визуализации и проч.
Подобный подход (толстые автономные компоненты) в свое время был популярен на бэке, называется микросервисы. Каждый микросервис автономен, живуч, и имеет собственную БД. Отдельная БД на сервис, по сути инкапсуляция сториджа внутри сервиса — это выглядит странно (всегда было принято уровень хранения выделять в отдельный слой приложения), но тем не менее куча людей эти микросервисы форсят (я нет). Так же и толстые веб-компоненты имеют право на жизнь в определенных случаях. Причем, такие толстые model-view компоненты внутри могут быть сколь угодно сложными и реактивными, но извне выглядят как монолит.
Спасибо, понятно. Поэтому я и не люблю реакт, слишком много нюансов и противоречивых подходов. Посмотрите как чисто то же самое реализовано на флаттере, который некоторые считают форком реакта. Теперь на нем и вебню можно писать: https://m.habr.com/ru/company/piter/blog/503074/
Провайдер хорош, но статья просто шедевр, очень приятно читать, баланс между краткостью и полнотой выдержан идеально. Склоняю голову перед профессионалами !
Однозначно. Потому что с веб-компонентами не все хорошо например у FF. В этом конкретном проектике я на лису вообще не расчитывал, т.к. она не умеет красиво фотографировать, а выдирать фото из нефокусированного видео-потока это такое себе развлечение. Про Стройного слышу только положительные отзывы, спасибо.
Это вообще вечный архитектурный спор за локальность против глобальности. Микросервисы против монолитов, композиция против наследования, локальный стейт против глобального и т.д. На бэкенде модно, чтобы каждый микросервис имел собственную БД, теперь и на фронте пошла тема за «микро-фронтенды». Хуже всего, когда коммерческий проект огромный и чужой, но нужно всунуть туда свою страничку. Пусть это обзовут кривым дизайном, но когда у меня однофайловый веб-компонент, со своими стилями и собственным сториджем, мне только нужно договориться об интерфейсе событий, и я за его судьбу спокоен — нет зацепленности, нет зависимостей, ошибкам негде жить. А так Вы правы конечно, на реактивное приложение нужен грамотный архитектор. У меня такого не было, вот и результат.
Да, и с тех пор появились watch() и read()
-
PS
Я работал на действительно больших проектах, когда в БД полторы тысячи таблиц. Большинство коммерческих веб-приложений примерно в 10 раз меньше. И да, в том большом проекте не было декларативщины и реактивщины — вполне себе олдскульный императивный ООП.
PPSS
Я люблю фукнциональное программирование, но деньги приходится зарабатывать ООП, увы, потому что приходится работать на высоко-нагруженных проектах.
PPPSSS
Сейчас активно изучаю Flutter с прицелом в том числе на WEB-разработку, и бандл у него на маленьких приложениях где-то в 2 раза больше реактового. Кодирование абсолютно в стиле React )
Хуки во флаттере появились только что, похоже Гугл сам не определился еще со своим продуктом.
PS
Однако, ваш комментарий крут )
Спасибо, понял.
2.3 мегабайта мимифицированного JS, побитого на 100 файлов. Приложение просто делает фотки и кладет в базу, у меня функционал в три раза больше, а размер исходного JS — 27 килобайт. Если б на тайпскрипте сделал — было бы 15 килобайт.
Разница в 85 раз, Карл ! И это еще без редакса с мобиксом.
Для сравнения — на флаттере приложение 1.5 мегабайта одним файлом.
Я ничего не имею против реакта с иоником, и даже наверное буду продолжать на них писать, но это явно инструменты для богатых. Я понимаю, функциональный код проще тестировать, меньше ошибок и т.д. Но линукс написан на голом СИ, и до сих пор работает )
PS
Объем исходного кода одинаков — что на ионике, что на ванили, на ионике даже немного больше за счет длинных имен.
грызть кактусиспользовать контекст. С флаттером получается идентичная архитектура, а я как раз его сейчас изучаю, делаю сравнение Flutter vs Ionic React на простой прикладной задаче.Вот и возникла идея — а давайте будем размещать и модели и вьюшки в едином дереве компонентов с автоматической деструкцией. Получился паттерн контекст-провайдер, наиболее красиво реализованный во Flutter, ссылку на хорошую статью уже приводил habr.com/ru/company/piter/blog/503074
Но тогда получается, что моделька — это просто дополнительный узел в дереве виджетов, и грань между виджетом-моделью и виджетом-представлением сильно истончается. А следующим логическим шагом будет объединение этих 2-х виджетов в один «толстый» компонент, как это сделано в моем коде.
Ну то есть в индустрии существует вечный спор — на какие части нарезать изначальную сложность бизнес-задачи. Можно по технологическим признакам (хранилище — модель — контроллер — вью), можно по бизнес-ответственности (справочник клиентов, операция закупка, операция продажа), а больших приложениях всегда режут и так и так — горизонтально по технологиям, вертикально по функционалу, называется матричная схема. В относительно компактных проектах достаточно оставить только вертикальное деление, то есть толстые автономные однофайловые компоненты. Это уменьшает количество сущностей, файлов, и служебного кода. И делает приложение более живучим, когда каждый компонент содержит внутри логику собственного сториджа, реконнекта к другим компонентам, визуализации и проч.
Подобный подход (толстые автономные компоненты) в свое время был популярен на бэке, называется микросервисы. Каждый микросервис автономен, живуч, и имеет собственную БД. Отдельная БД на сервис, по сути инкапсуляция сториджа внутри сервиса — это выглядит странно (всегда было принято уровень хранения выделять в отдельный слой приложения), но тем не менее куча людей эти микросервисы форсят (я нет). Так же и толстые веб-компоненты имеют право на жизнь в определенных случаях. Причем, такие толстые model-view компоненты внутри могут быть сколь угодно сложными и реактивными, но извне выглядят как монолит.
Спасибо, понятно. Поэтому я и не люблю реакт, слишком много нюансов и противоречивых подходов. Посмотрите как чисто то же самое реализовано на флаттере, который некоторые считают форком реакта. Теперь на нем и вебню можно писать:
https://m.habr.com/ru/company/piter/blog/503074/
Ваше мнение насчёт context.provider? Во флаттере форсится почти как стандарт, почему в реакт нельзя использовать только его ?
Хм, а мне наоборот понравилось. В мире Rust "спавнить футуру" (spawn future) вообще обычное дело )
Провайдер хорош, но статья просто шедевр, очень приятно читать, баланс между краткостью и полнотой выдержан идеально. Склоняю голову перед профессионалами !