Render provides the raw data payload that will be sent to the frontend on initial render and during any sideeffect update. In most cases, you should return a RenderBase instance. If you have no data to display you can also return None.

This function must be explicitly typehinted with your response type, which allows the AppController to generate the correct TypeScript types for the frontend:

Code
class MyServerData(RenderBase):
    pass

class MyController:
    def render(self) -> MyServerData:
        pass
CopyCopied!

If you don't intend to sync any data from server->client you can typehint this function with an explicit None return annotation:

Code
class MyController:
    def render(self) -> None:
        pass
CopyCopied!

Render functions accept any number of arguments and keyword arguments, following the FastAPI route parameter style. This includes query parameters, path parameters, and request bodies.

Code
class MyController:
    url = "/my-url/{path_param}"

    def render(
        self,
        query_param: str,
        path_param: int,
        dependency: MyDependency = Depends(MyDependency),
    ) -> MyServerData:
        ...
CopyCopied!

Typically used internally by the Mountaineer build pipeline. Calling this function sets the active view_base of the frontend project, which allows us to resolve the built javascripts that are required for this controller.

Register a new controller. This will:

• Mount the html of the controller to the main application service
• Mount all actions (ie. @sideeffect and @passthrough decorated functions) to their public API

After an on-disk change of a given path, we should clear its current script cache so we rebuild with the latest changes. We should also clear out any nested children - so in the case of a layout change, we refresh all of its subpages.

Compiles the HTML for a given page, with all the controller-returned values hydrated into the page.

When we register a new element, we need to:

• Find if there are any on-disk layouts that have been defined. We add these greedily, before we know if they're backed by a layout controller
• Add the controller as a LayoutElement if it's new. Otherwise update the existing element

This function is built to be invariant to the order of the updates, so we can call it multiple times and call it progressively as more controllers are added. It will be valid at any given state for the current webapp mounting.

Collects the signature from the "reference_controller" and replaces the active target_controller's render endpoint with this new signature. We require all these new parameters to be kwargs so they can be injected into the render function by name alone.

Bundle custom user exceptions in the OpenAPI schema. By default endpoints just include the 422 Validation Error, but this allows for custom derived user methods.

Builds the header for this controller. Returns the list of tags that will be injected into the

Parse the source map file and build up the internal mappings. This is deterministic with respect to the initialized source map path, so this will be a no-op if it's already been run.

For a compiled line and column, return the original line and column where they appeared in the pre-built file.

Given a JS stack exception, try to map it to the original files and line numbers

Absolute paths are convenient for internal use since they fully qualify a given file. However, for display they often get long and repetitive across multiple lines. This function will convert an absolute path to a relative path if it's within the same directory as the current working directory.