Reference

Overview

The chapters so far told a story. This section is the index card — a rough map of the classes, features and functions WebFluid exposes, grouped by where they live. It is deliberately terse: enough to find a name and remember what it does, not a line-by-line specification.

 

From this beta onwards, everything listed in a package's __all__ follows semantic versioning. Anything else — module layout, private attributes, helpers that are not exported — is internal and may move in any release. Treat this page as a compass rather than a specification, and keep your version pinned while the beta runs.

How the package is laid out

The import tree mirrors the layers you've worked through:

  • Core — webfluid, webfluid.core.*: the Fluid app, config, context, the shared extension registry and the runtime constants.
  • Extensions — webfluid.extensions.*: the base extension and the full battery set.
  • Surface — webfluid.surface.*: the frontend integration, Node and Tailwind tooling.
  • Additives — the Additive system, manifests and the registry helpers.
  • Utils — webfluid.utils.*: framework helpers, logging and the exception hierarchy.

Top-level exports

What you can import straight from webfluid:

  • Fluid — the application class. See Core.
  • Additive, Manifest — the module system. See Additives.
  • version — a callable returning the running framework version.
  • utils, fluid, extensions, exceptions — the sub-packages.
 

Every package in the tree resolves its exports lazily through a module __getattr__, so importing webfluid does not drag the whole framework into memory and an extension you never enable is never instantiated. It also means dir() on a package is the honest list of what it offers.

Continue reading

From here you can continue straight with Core.