Набор метафреймворков Быстрый, Астро, Свежий, Следующий, Твердый старт, Стройный комплект все не делают этого, у них нет возможности импортировать пакет, который инкапсулирован с маршрутом (маршрутами), клиентским компонентом (ами), данными ssr, и запускать его в рамках.

Обновлять В Remix есть способ сделать программные маршрутизаторы с помощью файла конфигурации.. С помощью этой простой функции вы можете делать большую часть того, о чем я говорю. Однако может быть сложно обмениваться контекстом между маршрутами, например, с клиентом базы данных.

В принципе, я хочу писать приложения иначе, чем большинство метафреймворков маршрутизации на основе файлов. Я хочу написать небольшие компоненты пользовательского интерфейса с действиями сервера и загруженными сервером данными, которые должны быть определены в одном файле, и иметь возможность загружать этот файл в качестве «плагина» для фреймворка. Мне нужны глобальные контексты, которые позволяют плагинам получать доступ к таким вещам, как базы данных, env vars и сторонние API-клиенты.

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

Файловая маршрутизация имеет один фатальный недостаток — компонуемость: она не позволяет сломать форму.

Я думаю выражать / дуб правильно маршрутизировал на сервере, позволяя вам составлять и вкладывать полные маршрутизаторы, которые могут быть модулями npm. Мы отошли от этого, и это означает, что мы не можем разбить наш код на разделяемые фрагменты.

Кент С. Доддс недавно опубликовал статью под названием «Компоненты полного стека«концепция, которая очень похожа на мою идею о том, чтобы весь код конечной точки был в одном файле. Однако ремикс не допускает ничего, кроме маршрутизации на основе файлов, что означает отсутствие программного способа добавления компонента полного стека из NPM.

Я вижу один из двух вариантов будущего: либо фреймворки начинают видеть преимущества добавления модульности в свои кодовые базы и добавляют возможность для импорта плагинов/модулей/URL-адресов содержать маршруты, компоненты, острова, доступ к базе данных, контекст и т. д., либо мы придумываем другой способ, используя Micro Frontends.


Почему это желательно?

Без возможности импортировать код, который мы пишем, нельзя использовать совместно, приложения являются двумерными/одноразовыми. Почему не так просто создать шаблон простого функционала сайта? Проблема в том, что все слишком заняты генераторами статических сайтов, интерфейсными фреймворками и маршрутизацией на основе файлов. Вам не хватает отметки! Будущее — это изолированные серверные + клиентские элементы пользовательского интерфейса «полные компоненты стека», и для запуска не требуется более крупная структура/система.

По сути, мне нужны плагины для WordPress. У WordPress была потрясающая экосистема плагинов, которые могли делать с системой все что угодно, а также новые таблицы базы данных, новые элементы пользовательского интерфейса, новые темы. Я даже баловался с друпалом, так много контроля и очень сложный в использовании.

Я представляю целую структуру с чистыми плагинами supabase, плагинами shopify, плагинами Google Drive, чтобы обеспечить локальное кэширование информации от сторонних API.

Фред, создатель astro, даже похвалил это, хотя, к сожалению, в astro это невозможно.

const calendar = wireCalendarScheduler({
  google: {
    client: GOOGLE_CLIENT, 
    secret: GOOGLE_SECRET,
  },
  ...calendarSettings
})

// what might calendar return?

const { routes, headtags, styles, components } = calendar
const { Calendar } = components

Войти в полноэкранный режим

Выйти из полноэкранного режима

Думая обо всех вещах, которые входят в приложение «календарного планирования», например, calendly.

  1. Иметь доступ к календарю Google
  2. Создание маршрутов Webhook для обновлений событий календаря
  3. Иметь доступ к супербазе
  4. Создайте таблицу базы данных в сервисе, таком как supabase
  5. Кэшировать данные календаря локально в супабазе
  6. Отправка кода сервера SSR
  7. Отправьте интерактивный клиентский код (если есть)

Дено даже сделал клон календаря под названием встреть меня построен со свежими. Это отдельная вещь, вам нужно загрузить сервер, чтобы использовать ее. Почему я не могу просто добавить это на свой новый веб-сайт?


RSC и Next.js

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



Случайная мысль

Возможно, действительное принятие «серверных компонентов» как простых функций могло бы освободить нас?

Предыдущие сообщения: