Member Junction
    Preparing search index...

    Base class for all Angular components in the MemberJunction system.

    Hierarchy (View Summary)

    Index

    Constructors

    Properties

    EditMode: boolean = false
    Provider: IMetadataProvider | null

    If specified, this provider will be used for communication and for all metadata purposes. By default, if not provided, the Metadata and RunView classes are used for this and the default GraphQLDataProvider is used which is connected to the same back-end MJAPI instance as the Metadata and RunView classes. If you want to have this component connect to a different MJAPI back-end, create an instance of a ProviderBase sub-class like GraphQLDataProvider/etc, and configure it as appropriate to connect to the MJAPI back-end you want to use, and then pass it in here.

    record: BaseEntity
    "ɵdir": unknown
    "ɵfac": ɵɵFactoryDeclaration<BaseAngularComponent, never>

    Accessors

    • get HasPendingChanges(): boolean

      Whether this section is holding edits the host form's Save still has to persist.

      A section that owns its own editor — a canvas, a grid, a designer — accumulates changes the host knows nothing about, so without this the form's dirty indicator says "no changes" while the user is looking at edits they have made. Default false: a section that only renders fields has nothing of its own to report.

      Returns boolean

    • get ProviderToUse(): IMetadataProvider

      Returns either the default Metadata provider or the one specified in the Provider property, if it was specified

      Returns IMetadataProvider

    • get RunQueryToUse(): IRunQueryProvider

      Returns either the default RunQuery provider or the one specified in the Provider property, if it was specified

      Returns IRunQueryProvider

    • get RunViewToUse(): IRunViewProvider

      Returns either the default RunView provider or the one specified in the Provider property, if it was specified

      Returns IRunViewProvider

    Methods

    • Joins this section's writes to the host form's save.

      Why a transaction group rather than "save yourself". A section that saves independently gives the record two save buttons and two failure modes: the form can succeed while the section fails, leaving the user with a record that looks saved and edits that are gone. Queuing into the host's group makes the whole record atomic — everything lands or nothing does.

      Implementations should queue work on the group and return; the host submits. Return false to abort the save (the host will not submit). Default is a no-op that succeeds, so every existing section is unaffected.

      Parameters

      Returns Promise<boolean>