@finos/legend-application-studio/lib/stores/editor/GraphEditFormModeState.d.ts

Legend Studio application 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 PackageableElement } from '@finos/legend-graph';
import { type GeneratorFn } from '@finos/legend-shared';
import type { Entity } from '@finos/legend-storage';
import { type Problem } from './EditorGraphState.js';
import { GRAPH_EDITOR_MODE } from './EditorConfig.js';
import { GraphEditorMode } from './GraphEditorMode.js';
import type { EditorInitialConfiguration } from './editor-state/element-editor-state/ElementEditorInitialConfiguration.js';
import type { FileSystem_File } from './utils/FileSystemTreeUtils.js';
export declare class GraphEditFormModeState extends GraphEditorMode {
    initialize(): GeneratorFn<void>;
    addElement(element: PackageableElement, packagePath: string | undefined, openAfterCreate: boolean): GeneratorFn<void>;
    deleteElement(element: PackageableElement): GeneratorFn<void>;
    renameElement(element: PackageableElement, newPath: string): GeneratorFn<void>;
    getCurrentGraphHash(): string | undefined;
    get mode(): GRAPH_EDITOR_MODE;
    /**
     * 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 dependencies, 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/
     */
    updateGraphAndApplication(entities: Entity[]): GeneratorFn<void>;
    globalCompile(options?: {
        message?: string;
        disableNotificationOnSuccess?: boolean;
        openConsole?: boolean;
    }): GeneratorFn<void>;
    goToProblem(problem: Problem): void;
    onLeave(): GeneratorFn<void>;
    cleanupBeforeEntering(fallbackOptions?: {
        isCompilationFailure?: boolean;
        isGraphBuildFailure?: boolean;
    }): GeneratorFn<void>;
    handleCleanupFailure(error: unknown): GeneratorFn<void>;
    openFileSystem_File(fileNode: FileSystem_File): void;
    openElement(element: PackageableElement, config?: EditorInitialConfiguration | undefined): void;
}
//# sourceMappingURL=GraphEditFormModeState.d.ts.map