ПРОБЛЕМА В ФРОНТЕНДЕ

Поделиться
HTML-код
  • Опубликовано: 29 сен 2024
  • Отрывок из стрима ruclips.net/user/li...
    Проблема Frontend, которая не решается годами
    Телеграм-база с материалами: t.me/shifu_base
    Телеграм канал: t.me/shifuio
    Сайт проекта: shifu.io
    ВК: shifuio
    Подкаст: shifu.mave.dig...

Комментарии • 23

  • @orego800
    @orego800 11 месяцев назад +1

    Я решил! 20 лет правда потратил, и кроме меня никто особо использовать не может :)

  • @ignatneko1339
    @ignatneko1339 Год назад

    никто не хочет брать на себя ответственность за создание стандарта - так как сразу набежит 1000 хейтеров доказывать что твой стандарт говно, ограничивает, не даёт свободы ...вместо того чтобы изобретать велосипед под каждый сайт - можно было бы создавать микро стандарты, изолированные (в чистом проекте) и скрадывать в базу компании, а например джуны могли бы брать из базы компании эти микро стандарты и юзать их в проектах, под микро стандартами я подразумеваю например "форма с 1 кнопкой", "простая таблица", "таблица с пагинацией", "таблица с пагинацией и сортировкой", ... ...они не обязаны быть идеальными/актуальными - вместо этого можно делать просто разные версии: "что-то на редаксе", "что-то на редакс-тулкие", "что-то на реакт-квери", ...

  • @zooyotz
    @zooyotz 11 месяцев назад

    Так а в чем проблема-то?) Если бизнес все устраивает, и он готов за это платить, так и будем сидеть и пилить одно и то же, а потом обязательно все баги пофиксим) Не нужно решать эту проблему, потому что если взяться за это глобально, никакого фронта потом не будет. Фронтов разжалуют в верстальщиков, а бэк сам будет пулять данные в готовые компоненты. Но сделать это невозможно, потому что на каждом проекте свои ограничения, костыли и тараканы, с которыми нужно мириться, поэтому я вообще не верю, что это будет когда-то пофикшено. Именно для этого и нужен фронтендер

  • @seoonlyRU
    @seoonlyRU Год назад +1

    лайк от СЕООНЛИ вам!

  • @partyfavor4825
    @partyfavor4825 6 месяцев назад

    Вы как будто читаете мои мысли)) Во фронте в 90% случаев ведь все кристально просто: получил данные => обработал + засторил данные => отобразил данные => собрал данные от пользователя => отвалидировал данные => отправил на сервер. Почему мы до сих пор страдаем и не имеем унифицированных решений на каждый этап (без кучи писанины что важно) мне до сих пор не ясно... Может быть кто-то в комментариях знает ответ😊

  • @slavus54
    @slavus54 Год назад +1

    Николай как с языка снял, уже 4 год в web (начинал в школе), и иногда приходиться посыпать голову пеплом от рутины и заново изобретать велосипеды.
    Но глобальные проекты на разную тематику с собственным дизайном (от kit была зависимость на 1 год - стагнация) и архитектурой как-то спасают.
    Последние недели есть мысль написать библиотеку UI компонентов, связанных с graphql + админка для простой работы с данными.
    Твоё видео как триггер прям, спасибо!

  • @makarov.1996
    @makarov.1996 11 месяцев назад

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

  • @uran1980video
    @uran1980video Год назад

    Ну джак предложите решение...

  • @dmitriyobidin6049
    @dmitriyobidin6049 4 месяца назад

    А на бэке типа не так...

  • @lx700
    @lx700 Год назад

    Какое то неполное высказывание. "Есть проблема". А решение то какое?
    Ты даже как то не порассуждал, почему так происходит. Звучит просто как крик боли :)
    Ну как так, если "всё одинаковое", может быть взять библиотеку компонентов типа MUI\AntD.
    А, всё таки взяли MUI\AntD, но "всё равно месяцами пилим и баги исправляем". Ну как же так, если "всё одинаковое". Как то непонятно, что-то тут не стыкуется.
    Честно, очень похоже на то, как менеджер рассуждает про разработку.

  • @amxx8335
    @amxx8335 Год назад

    Попробуй возглавить решение этой проблемы :)) Разработать лучшую систему и пустить все бабки в то, чтобы оно стало наиболее популярным. Если твоё решение всё-таки станет наиболее правильным и популярным, то может станешь чуточку богаче... Хотя и сейчас по тебе видно, что у тебя всё хорошо и спокойно.

    • @daveyjonesx
      @daveyjonesx Год назад

      Поздравляем, вы изобрели конструктор

  • @IgorGallemar
    @IgorGallemar Год назад

    Первый!!!

  • @ВладиславБугир
    @ВладиславБугир Год назад +2

    Чим більший розмір бібліотеки буде тим складніше цим керувати.
    Навіть у ant, bootstrap та ін. є проблема з некерованістю деяких елементів, якщо замовнику захочеться зробити відступ якимось іншим чи ще якусь малу деталь то для цього може не бути можливості(або костиль який ускладнить проект), а що вже говорити про більше? Якщо буде просто конфіг в який вписати де буде знаходитись авторизація, то як таким потім керувати в деталях?

  • @Fenneig
    @Fenneig Год назад

    Всякие тильды это не решение этой проблемы? просто аналогичное решение свое запилить, и уже под каждый кейс отдельный делать вот это вот. У нас в геймдеве это называется игровой движок > все типовые задачи уже решили и закинули в движок, а дальше просто конкретные задачи решаем, типа не нужно каждый раз писать логику того как будет работать рендер или физика в игре

    • @shifuio
      @shifuio  Год назад +2

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

  • @i.n.9761
    @i.n.9761 Год назад

    Бойлерплейты и тягаешь по проектам, не?)

    • @PavelKoryagin
      @PavelKoryagin Год назад

      И AI чтобы по аналогии с имеющимся бойлерплейтом и смутным описаниям нафигачивал новые экраны и компоненты. А разработчик уже бы доводил их до продакшен качества.

  • @dev_insider
    @dev_insider Год назад

    А auth0 вроде как решает?

    • @shifuio
      @shifuio  Год назад

      видео не об этом

  • @rustam-hr1qy
    @rustam-hr1qy Год назад

    Это в какой-то мере решается написанием своей юай либы. Например взять таблички, мы переиспользуем их следующим образом: есть хук в котором лежит реактивный объект с параметрами страницы, лимита, сортировкой, поиска и т.д. при создании его инстанса прокидываются колбэки, которые могу быть вызваны при каких либо действиях. И если на странице, к примеру, используется фильтр, таблица, пагинация мы просто к компонентам привязываем данные.

    • @shifuio
      @shifuio  Год назад

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

    • @metalcorewitchkhousovitch5774
      @metalcorewitchkhousovitch5774 6 месяцев назад

      ​@@shifuio Ъуъ, вот это опасно, компонент хоть и уровня виджет (говоря на FSD-шном), но связывать его логику сразу с тем, что он будет работать с только запросами - несколько сомнительно. Лучше сделать какую-нибудь сущность "DataSource" (можно через интерфейс ради Dep.Inversion), нп хук "useDataSource", который будет принимать в себя коллбек с запросом или моком (если бек не спешит делать апиху для очередной таблицы).
      Но все это ситуативно, и мой вариант частенько может быть оверкиллом)