ПРОБЛЕМА В ФРОНТЕНДЕ
HTML-код
- Опубликовано: 29 сен 2024
- Отрывок из стрима ruclips.net/user/li...
Проблема Frontend, которая не решается годами
Телеграм-база с материалами: t.me/shifu_base
Телеграм канал: t.me/shifuio
Сайт проекта: shifu.io
ВК: shifuio
Подкаст: shifu.mave.dig...
Я решил! 20 лет правда потратил, и кроме меня никто особо использовать не может :)
никто не хочет брать на себя ответственность за создание стандарта - так как сразу набежит 1000 хейтеров доказывать что твой стандарт говно, ограничивает, не даёт свободы ...вместо того чтобы изобретать велосипед под каждый сайт - можно было бы создавать микро стандарты, изолированные (в чистом проекте) и скрадывать в базу компании, а например джуны могли бы брать из базы компании эти микро стандарты и юзать их в проектах, под микро стандартами я подразумеваю например "форма с 1 кнопкой", "простая таблица", "таблица с пагинацией", "таблица с пагинацией и сортировкой", ... ...они не обязаны быть идеальными/актуальными - вместо этого можно делать просто разные версии: "что-то на редаксе", "что-то на редакс-тулкие", "что-то на реакт-квери", ...
Так а в чем проблема-то?) Если бизнес все устраивает, и он готов за это платить, так и будем сидеть и пилить одно и то же, а потом обязательно все баги пофиксим) Не нужно решать эту проблему, потому что если взяться за это глобально, никакого фронта потом не будет. Фронтов разжалуют в верстальщиков, а бэк сам будет пулять данные в готовые компоненты. Но сделать это невозможно, потому что на каждом проекте свои ограничения, костыли и тараканы, с которыми нужно мириться, поэтому я вообще не верю, что это будет когда-то пофикшено. Именно для этого и нужен фронтендер
лайк от СЕООНЛИ вам!
Вы как будто читаете мои мысли)) Во фронте в 90% случаев ведь все кристально просто: получил данные => обработал + засторил данные => отобразил данные => собрал данные от пользователя => отвалидировал данные => отправил на сервер. Почему мы до сих пор страдаем и не имеем унифицированных решений на каждый этап (без кучи писанины что важно) мне до сих пор не ясно... Может быть кто-то в комментариях знает ответ😊
Николай как с языка снял, уже 4 год в web (начинал в школе), и иногда приходиться посыпать голову пеплом от рутины и заново изобретать велосипеды.
Но глобальные проекты на разную тематику с собственным дизайном (от kit была зависимость на 1 год - стагнация) и архитектурой как-то спасают.
Последние недели есть мысль написать библиотеку UI компонентов, связанных с graphql + админка для простой работы с данными.
Твоё видео как триггер прям, спасибо!
если тебе пару форм надо на проекте есть решение этой проблемы ворпресс)
понятное дело что если хочешь свой полностью функционал как ни крути придется содержать и бэков и фронтов, все таки сейчас фронтенд не только формы, и картография и видео и аудио да чего только нет на самом деле помимо форм
Ну джак предложите решение...
А на бэке типа не так...
Какое то неполное высказывание. "Есть проблема". А решение то какое?
Ты даже как то не порассуждал, почему так происходит. Звучит просто как крик боли :)
Ну как так, если "всё одинаковое", может быть взять библиотеку компонентов типа MUI\AntD.
А, всё таки взяли MUI\AntD, но "всё равно месяцами пилим и баги исправляем". Ну как же так, если "всё одинаковое". Как то непонятно, что-то тут не стыкуется.
Честно, очень похоже на то, как менеджер рассуждает про разработку.
Попробуй возглавить решение этой проблемы :)) Разработать лучшую систему и пустить все бабки в то, чтобы оно стало наиболее популярным. Если твоё решение всё-таки станет наиболее правильным и популярным, то может станешь чуточку богаче... Хотя и сейчас по тебе видно, что у тебя всё хорошо и спокойно.
Поздравляем, вы изобрели конструктор
Первый!!!
Чим більший розмір бібліотеки буде тим складніше цим керувати.
Навіть у ant, bootstrap та ін. є проблема з некерованістю деяких елементів, якщо замовнику захочеться зробити відступ якимось іншим чи ще якусь малу деталь то для цього може не бути можливості(або костиль який ускладнить проект), а що вже говорити про більше? Якщо буде просто конфіг в який вписати де буде знаходитись авторизація, то як таким потім керувати в деталях?
Всякие тильды это не решение этой проблемы? просто аналогичное решение свое запилить, и уже под каждый кейс отдельный делать вот это вот. У нас в геймдеве это называется игровой движок > все типовые задачи уже решили и закинули в движок, а дальше просто конкретные задачи решаем, типа не нужно каждый раз писать логику того как будет работать рендер или физика в игре
тильда решает проблему не в той плоскости, ты хорошо описал аналогию - игровой движок - это как раз то о чем я говорил
тильда в данном случае была бы как... генератор игр, где ты выбираешь тип игры, сколько игроков и загружаешь обложку и прочие мелочи.
Бойлерплейты и тягаешь по проектам, не?)
И AI чтобы по аналогии с имеющимся бойлерплейтом и смутным описаниям нафигачивал новые экраны и компоненты. А разработчик уже бы доводил их до продакшен качества.
А auth0 вроде как решает?
видео не об этом
Это в какой-то мере решается написанием своей юай либы. Например взять таблички, мы переиспользуем их следующим образом: есть хук в котором лежит реактивный объект с параметрами страницы, лимита, сортировкой, поиска и т.д. при создании его инстанса прокидываются колбэки, которые могу быть вызваны при каких либо действиях. И если на странице, к примеру, используется фильтр, таблица, пагинация мы просто к компонентам привязываем данные.
я бы даже сказал - можно зашить в этот компонент круд операции, а в пропертиз просто указываем урлы на которые надо долбиться
@@shifuio Ъуъ, вот это опасно, компонент хоть и уровня виджет (говоря на FSD-шном), но связывать его логику сразу с тем, что он будет работать с только запросами - несколько сомнительно. Лучше сделать какую-нибудь сущность "DataSource" (можно через интерфейс ради Dep.Inversion), нп хук "useDataSource", который будет принимать в себя коллбек с запросом или моком (если бек не спешит делать апиху для очередной таблицы).
Но все это ситуативно, и мой вариант частенько может быть оверкиллом)