Do not store certain tabs in the shell layout (between sessions). Is there general interest for a contribution?

[dmm9]

Hi! In my theia-based app, I do not want certain tabs to be restored between client sessions. For that, I have rebound the ShellLayoutRestorer. Code below. This has some caveats:

a) This rebind can only be done once
b) I have to keep an eye on changes in the upstream ShellLayoutRestorer.

So, from implementation perspective, it would be good to have some kind of contributionpoint that allows to add custom widget filters. Would this be worth a pull request to theia with a modified ShellLayoutRestorer that uses filters from contributions?

export default new ContainerModule((bind, _unbind, _isbound, rebind) => {
    rebind(ShellLayoutRestorer).to(CustomLayoutRestorer).inSingletonScope();
}

@injectable()
export class CustomLayoutRestorer extends ShellLayoutRestorer {
    protected readonly filter: string = "abcde";

    storeLayout(app: FrontendApplication): void {
        if (this.shouldStoreLayout) {
            try {
                this.logger.info('>>> Storing the layout...');
                const layoutData = app.shell.getLayoutData();
                this.pruneConfig(layoutData.mainPanel?.main);     // <----- Adds widget filter here
                const serializedLayoutData = this.deflate(layoutData);
                this.storageService.setData(this.storageKey, serializedLayoutData);
                this.logger.info('<<< The layout has been successfully stored.');
            } catch (error) {
                this.storageService.setData(this.storageKey, undefined);
                console.error('Error during serialization of layout data', error);
            }
        }
    }

    protected pruneConfig(area: DockLayout.AreaConfig | null | undefined) {
        if (area?.type === 'tab-area') {
            this.pruneTabConfig(area);
        } else if (area?.type === 'split-area') {
            this.pruneSplitConfig(area);
        }
    }

    protected pruneTabConfig(area: DockLayout.AreaConfig) {
        if (area.type === 'tab-area') {
            const newwidgets = area.widgets.filter(widget => {
                if (widget.id.startsWith(this.filter)) {
                    return false;
                }
                return true;
            });
            area.widgets = newwidgets;
        }
    }
    protected pruneSplitConfig(area: DockLayout.AreaConfig) {
        if (area.type === 'split-area') {
            area.children.forEach(c => this.pruneConfig(c));
        }
    }
}

[sdirix]

Hi @dmm9,

Yes I think so. I know of other adopters who also customized this to get a predictable "stable" state at startup. I think the most valuable point of the suggestion is to split the Layout processing from the store/restore implementation.

The filtering use case is very specific. Is there a use case of having multiple such contributions for an application? What do you think about a LayoutData Processor which gets full access to the LayoutData before it is saved and before it is loaded? It could be marked optional for adopters who are not interested in it.

[dmm9]

The filtering use case is very specific. Is there a use case of having multiple such contributions for an application?

I see 2 topics under discussion:

1. Architectural approach to modify the layout data (either during store or restore).
2. Layout manipulation algorithm (e.g. filter by widget id)

Regarding the architectural approach, we have to consider that adopters create different frontend contributions for the UI. The goal (use case) would be to make each contribution capable of manipulating its own layout data.

With a single layout data processor, like the workaround I have shown in the original post, it is not possible to keep frontend contributions isolated from each other. We need one single component to know about the implementation details (e.g. widget id) of all the frontend contributions that need layout manipulations.

Therefore the contributionPoint mechanism comes in handy. The ShellLayoutRestorer would implement a contributionPoint that aggregates all layout modifications in a generic way. Each frontend contribution that need special layout manipulations would implement such contribution, thus keeping the implementation details about such manipulations isolated.

There are 2 topics that would remain open. One is the layout manipulation algorithm. Filter by widget id is one of many possible use cases. A possible implementation would be to fully defer the algorithm implementation to the individual contribution implementations. This defers more integration effort to the adopters, but would keep the Theia platform open for every use case. An alternative would be to implement different layout manipulation algorithms inside the contributionPoint, and let adopters choose the desired algorithm. This alternative is more straightforward for adopters, but more restricted in use cases.

The other open topic which has not been mentioned yet is the 'authorisation' of individual frontend contributions to modify the layout of other contributions. The most naive implementation would allow contribution A to manipulate the layout of contribution B. This can happen in various scenarios: writing layout manipulation algorithms that don't take into account all existing contributions, a 'malicious' or poorly-crafted third-party contribution/extension,... To avoid this, there could be a mechanism in place, for example, by introducing a layout ownership property and only allow the owner contribution to manipulate its own layout data. Given that this feature probably doesn't have much demand yet, the risk of leaving this unaddressed is likely very low.

[dmm9]

@sdirix in reply to your comment (read above)

[sdirix]

Thanks for the write up.

The ShellLayoutRestorer would implement a contributionPoint that aggregates all layout modifications in a generic way

If I understand correctly, then this is matches my suggestion above. It's "just" even more generic to allow multiple such contributed modifications instead of a single one.

I'm all for such a feature, so you would get an approval from me for a clean implementation.

An alternative would be to implement different layout manipulation algorithms inside the contributionPoint, and let adopters choose the desired algorithm. This alternative is more straightforward for adopters, but more restricted in use cases.

I prefer a very open approach as it's difficult to foresee all potential use cases. I think an open is is more straightforward too as adopters don't need to check additional algorithm enums etc.

The other open topic which has not been mentioned yet is the 'authorisation' of individual frontend contributions to modify the layout of other contributions. The most naive implementation would allow contribution A to manipulate the layout of contribution B.
[...]
Given that this feature probably doesn't have much demand yet, the risk of leaving this unaddressed is likely very low.

I agree, I don't see any risk leaving this unaddressed. In general we don't have such guard rails within Theia.

[dmm9]

Thanks for your comments. I will work on it.