@finos/legend-studio/lib/stores/EditorGraphState.d.ts

Legend Studio core

/**
 * Copyright (c) 2020-present, Goldman Sachs
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
import { type GeneratorFn } from '@finos/legend-shared';
import type { EditorStore } from './EditorStore.js';
import { GraphGenerationState } from './editor-state/GraphGenerationState.js';
import type { Entity } from '@finos/legend-model-storage';
import { type EntityChange, type ProjectDependency } from '@finos/legend-server-sdlc';
import { ProjectDependencyCoordinates } from '@finos/legend-server-depot';
import { type SetImplementation, type PackageableElement } from '@finos/legend-graph';
import { type LambdaEditorState } from '@finos/legend-application';
export declare enum GraphBuilderStatus {
    SUCCEEDED = "SUCCEEDED",
    FAILED = "FAILED",
    REDIRECTED_TO_TEXT_MODE = "REDIRECTED_TO_TEXT_MODE"
}
export interface GraphBuilderResult {
    status: GraphBuilderStatus;
    error?: Error;
}
export declare class EditorGraphState {
    editorStore: EditorStore;
    graphGenerationState: GraphGenerationState;
    isInitializingGraph: boolean;
    isRunningGlobalCompile: boolean;
    isRunningGlobalGenerate: boolean;
    isApplicationLeavingTextMode: boolean;
    isUpdatingGraph: boolean;
    isUpdatingApplication: boolean;
    constructor(editorStore: EditorStore);
    get hasCompilationError(): boolean;
    clearCompilationError(): void;
    get isApplicationUpdateOperationIsRunning(): boolean;
    checkIfApplicationUpdateOperationIsRunning(): boolean;
    buildGraph(entities: Entity[]): GeneratorFn<GraphBuilderResult>;
    private redirectToModelLoaderForDebugging;
    /**
     * Get entitiy changes to prepare for syncing
     */
    computeLocalEntityChanges(): EntityChange[];
    /**
     * Loads entity changes to graph and updates application.
     */
    loadEntityChangesToGraph(changes: EntityChange[], baseEntities: Entity[] | undefined): GeneratorFn<void>;
    globalCompileInFormMode(options?: {
        message?: string;
        disableNotificationOnSuccess?: boolean;
        openConsole?: boolean;
    }): GeneratorFn<void>;
    globalCompileInTextMode(options?: {
        ignoreBlocking?: boolean;
        suppressCompilationFailureMessage?: boolean;
        openConsole?: boolean;
    }): GeneratorFn<void>;
    leaveTextMode(): GeneratorFn<void>;
    /**
     * This function is used in lambda editor in form mode when user try to do an action that involves the lambda being edited, it takes an action
     * and proceeds with a parsing check for the current lambda before executing the action. This prevents case where user quickly type something
     * that does not parse and hit compile or generate right away.
     */
    checkLambdaParsingError(lambdaHolderElement: LambdaEditorState, checkParsingError: boolean, onSuccess: () => Promise<void>): GeneratorFn<void>;
    /**
     * NOTE: IMPORTANT! This method is both a savior and a sinner. It helps reprocessing the graph state to use a new graph
     * built from the new model context data, it resets the graph properly. The bane here is that resetting the graph properly is
     * not trivial, for example, in the cleanup phase, there are things we want to re-use, such as the one-time processed system
     * metamodels or the `reusable` metamodels from project dependencies. There are also explorer states like the package tree,
     * opened tabs, change detection, etc. to take care of. There are a lot of potential pitfalls. For these, we will add the
     * marker:
     *
     * @risk memory-leak
     *
     * to indicate we should check carefully these pieces when we detect memory issue as it might still
     * be referring to the old graph
     *
     * In the past, we have found that there are a few potential root causes for memory leak:
     * 1. State management Mobx allows references, as such, it is sometimes hard to trace down which references can cause problem
     *    We have to understand that the behind this updater is very simple (replace), yet to do it cleanly is not easy, since
     *    so far it is tempting to refer to elements in the graph from various editor state. On top of that, change detection
     *    sometimes obfuscate the investigation but we have cleared it out with explicit disposing of reaction
     * 2. Reusable models, at this point in time, we haven't completed stabilize the logic for handling generated models, as well
     *    as depdendencies, we intended to save computation time by reusing these while updating the graph. This can pose potential
     *    danger as well. Beware the way when we start to make system/project dependencies references elements of current graph
     *    e.g. when we have a computed value in a immutable class that get all subclasses, etc.
     * 3. We reprocess editor states to ensure good UX, e.g. find tabs to keep open, find tree nodes to expand, etc.
     *    after updating the graph. These in our experience is the **MOST COMMON** source of memory leak. It is actually
     *    quite predictable since structures like tabs and tree node embeds graph data, which are references to the old graph
     *
     * NOTE: One big obfuscating factor is overlapping graph refresh. Sometimes, we observed that calling this update graph
     * method multiple times can throws Mobx off and causes reusing change detection state to cause memory-leak. As such,
     * we have blocked the possibility of calling compilation/graph-update/generation simultaneously
     *
     * A note on how to debug memory-leak issue:
     * 1. Open browser Memory monitor
     * 2. Go to text mode and compile multiple times (triggering graph update)
     * 3. Try to force garbage collection, if we see memory goes up after while, it's pretty clear that this is memory-leak
     * (note that since we disallow stacking multiple compilation and graph update, we have simplify the detection a lot)
     * See https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/
     */
    private updateGraphAndApplication;
    /**
     * Used to update generation model and generation graph using the generated entities
     * does not alter the main or dependency model
     */
    updateGenerationGraphAndApplication(): GeneratorFn<void>;
    getIndexedDependencyEntities(): GeneratorFn<Map<string, Entity[]>>;
    buildProjectDependencyCoordinates(projectDependencies: ProjectDependency[]): GeneratorFn<ProjectDependencyCoordinates[]>;
    /**
     * NOTE: Notice how this utility draws resources from all of metamodels and uses `instanceof` to classify behavior/response.
     * As such, methods in this utility cannot be placed in place they should belong to.
     *
     * For example: `getSetImplemetnationType` cannot be placed in `SetImplementation` because of circular module dependency
     * So this utility is born for such purpose, to avoid circular module dependency, and it should just be used for only that
     * Other utilities that really should reside in the domain-specific meta model should be placed in the meta model module.
     *
     * NOTE: We expect the need for these methods will eventually go away as we complete modularization. But we need these
     * methods here so that we can load plugins.
     */
    getPackageableElementType(element: PackageableElement): string;
    getSetImplementationType(setImplementation: SetImplementation): string;
}
//# sourceMappingURL=EditorGraphState.d.ts.map