Back to Convex Backend

Components example

npm-packages/private-demos/components-poc/README.md

latest3.6 KB
Original Source

Components example

Run a local backend with components enabled:

bash
just run-local-backend

Run convex dev against the local backend (be sure to just rush build if needed):

bash
just convex dev

Try running the demo function:

bash
just convex run messages:componentTest

In progress

Bundling

Definitions work but no explicit functions are being sent up so only implicit exports are working really.

Some confusion around terms ComponentPath, DefinitionPath, etc.

Authoring a component

When authoring a component a developer needs to

  • run npx component create somewhere/myComponent

Codegen

Components need to generate

  1. _generated/server.ts for its function wrappers like mutation() generated specifically for

    • the parameters of the component definition, (use analysis)
    • the component definition's schema (could be a type import?)
    • the component definitions's child components (use analysis)
  2. _generated/api.ts for functions to call and schedule other functions. This could just be the old lazy api since this isn't imported in the component definition.

  3. _generated/component.ts for the types for defineComponent that wil be used by componentDefinitions? This will be an autocompletion stumbling block no worse than for implementations.

None of these are implemented yet.

For codegen we need a notion of "these components are part of this project; we are responsible for runnign codegen for them.

When importing a component definition from another package we should consider it "frozen;' it's read-only, and when we analyze it, we don't need to generate any code to "fix" the types.

TODOs removed from public code

Play with npm packaging

// TODO It will be important when developers write npm package components // for these to use a specific entry point or specific file name? // I guess we can read the files from the filesystem ourselves! // If developers want to import the component definition directly // from somewhere else,

is the const candidates = [args.path] logic really necessary?

Allow transistive imports of component definitions

// TODO compress these inputs so that everything that is not a convex.config.ts has its dependencies compacted down. // Until then we just let these missing links slip through.

I'd like to move all the bundling logic into the existing bundler code // TODO These should all come from ../../../bundler/index.js, at least helpers.

And besides, the error reporting code is duplicated

// TODO In theory we should get exactly the same errors here as we did the first time. Do something about that. // TODO abstract out this esbuild wrapper stuff now that it's in two places

Node.js bundles

// TODO Node compilation (how will Lambdas even work?) const _nodeResult = { bundles: [], externalDependencies: new Map(), bundledModuleNames: new Set(), };

registerEsbuildReads needs to be stretched out between the two esbuild invocations! Changes to the component definition dep tree will not be picked up or invalidated.

in components.ts

// TODO // Note we need to restart this whole process if any of these files change! // We should track these separately if we can: if any thing observed // by the definition traversal changes we need to restart at an earlier // point than if something in one of the implementations changes. // If one of the implementions changes we should be able to just rebuild that.

Gather push dependencies without doing an inadvertent bundle

// Note that it bundles!!! That's a step we don't need. const { config: localConfig } = await configFromProjectConfig(