Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Resolve circular reference of imports #121

Closed
wants to merge 5 commits into from

Conversation

4513ECHO
Copy link
Contributor

@4513ECHO 4513ECHO commented Aug 24, 2024

WIP

Need to discuss:

  • Should we stop re-exporting Base* classes and Base*Params types from types.ts?
  • Should we move definitions of Base*Params types to types.ts and import them from base/*.ts?

Current dependencies graph:

image

@4513ECHO

This comment was marked as outdated.

@Shougo
Copy link
Owner

Shougo commented Aug 25, 2024

Should we stop re-exporting Base* classes and Base*Params types from types.ts?

It should.

Should we move definitions of BaseParams types to types.ts and import them from base/.ts?

It should not.

Because base/*.ts files are already exported.

@4513ECHO
Copy link
Contributor Author

We have stopped re-exporting, but the problem continues to persist.
types.ts defines User{Column,Fiter,Source,Ui which depends on Base{Column,Filter,Source,Ui}Params, so we cannot make types.ts independent.
To solve the problem we have to define Base*Params in types.ts in the same way that we do BaseActionParams in types.ts.

@Shougo
Copy link
Owner

Shougo commented Aug 25, 2024

Hm... If so, User{Column, Filer, Source, Ui} should be exported in base/*.ts files.

@4513ECHO 4513ECHO changed the title Better dependency management [WIP] Resolve circular reference of imports Aug 25, 2024
@4513ECHO
Copy link
Contributor Author

Oh, I have found DduOptions also depends on Base*Params.
Is there any way to keep DduOptions in types.ts other than defining Base*Params and User* in types.ts?

export type DduOptions = {
  // ...
  columnParams: Record<ColumnName, Partial<BaseColumnParams>>;
  filterParams: Record<FilterName, Partial<BaseFilterParams>>;
  kindParams: Record<KindName, Partial<BaseKindParams>>;
  // ...
  postFilters: UserFilter[];
  sourceParams: Record<SourceName, Partial<BaseSourceParams>>;
  sources: UserSource[];
  // ...
  uiParams: Record<UiName, Partial<BaseUiParams>>;
};

@Shougo
Copy link
Owner

Shougo commented Aug 25, 2024

DduOptions must be defined in types.ts.

Hm...

Base*Params can be defined as BaseParams in types.ts.
Because it is just Record<string, unknown>.

@4513ECHO
Copy link
Contributor Author

Remaining circular reference:

  • ddu.ts and types.ts
  • context.ts and types.ts
  • loader.ts and base/source.ts

@4513ECHO
Copy link
Contributor Author

4513ECHO commented Aug 25, 2024

I think the following way is better to resolve a circular reference between loader.ts and base/source/ts:
I've tried, but Loader depends on Base* classes so the way is impossible...

  1. Define Loader interface in types.ts.
export interface Loader {
  initStaticImportPath(denops: Denops): Promise<void>;
  autoload(denops: Denops, type: DduExtType, name: string): Promise<void>;
  registerAlias(type: DduAliasType, alias: string, base: string): void;
  registerPath(type: DduExtType, path: string): Promise<void>;
  getUi(index: string, name: string): BaseUi<BaseParams> | null;
  getSource(index: string, name: string): BaseSource<BaseParams> | null;
  getFilter(index: string, name: string): BaseFilter<BaseParams> | null;
  getKind(index: string, name: string): BaseKind<BaseParams> | null;
  getColumn(index: string, name: string): BaseColumn<BaseParams> | null;
  getAlias(type: DduAliasType, name: string): string | undefined;
  getAliasNames(type: DduAliasType): string[];
  getSourceNames(): string[];
}
  1. Implement the interface in loader.ts.
import type { Loader } from "./types.ts";

export class LoaderImpl implements Loader {
  // ...
}
  1. Import Loader from types.ts in base/source.ts.

@Shougo
Copy link
Owner

Shougo commented Aug 26, 2024

context.ts and types.ts

Hm.

export { ContextBuilder } from "./context.ts";

can be removed in types.ts.

ddu.ts and types.ts

export type { Ddu } from "./ddu.ts";

can be removed in types.ts

NOTE: Both ddu.ts and context.ts must be exported.

@Shougo
Copy link
Owner

Shougo commented Aug 26, 2024

loader.ts and base/source.ts

Hm...

loader.ts is only used for the arguments.

export type OnInitArguments<Params extends BaseSourceParams> = {
  denops: Denops;
  sourceOptions: SourceOptions;
  sourceParams: Params;
  loader: Loader;
};

export type OnEventArguments<Params extends BaseSourceParams> = {
  denops: Denops;
  sourceOptions: SourceOptions;
  sourceParams: Params;
  event: DduEvent;
};

export type GatherArguments<Params extends BaseSourceParams> = {
  denops: Denops;
  context: Context;
  options: DduOptions;
  sourceOptions: SourceOptions;
  sourceParams: Params;
  input: string;
  parent?: DduItem;
  loader: Loader;
};

You can split the file.

@Shougo
Copy link
Owner

Shougo commented Aug 26, 2024

Why base/source.ts requires loader?
Because some sources uses loader...

@Shougo
Copy link
Owner

Shougo commented Aug 26, 2024

@4513ECHO
Copy link
Contributor Author

Remaining circular references:

  1. types.ts and base.ui.ts
  2. among ext.ts, ddu.ts and base/ui.ts

If we move the definition of UiActionArguments to types.ts, ① and ② is going to be resolved.
However, because of UiActionArguments depends on Ddu, a new circular reference between types.ts and ddu.ts is happening.

@4513ECHO
Copy link
Contributor Author

This dependency was added at 3202e53. Why UiActionArguments requires Ddu?

@Shougo
Copy link
Owner

Shougo commented Aug 26, 2024

This dependency was added at 3202e53. Why UiActionArguments requires Ddu?

Because user actions want to use ddu like this.

    args.contextBuilder.patchGlobal({
      ui: "ff",
      profile: false,
      uiOptions: {
        ff: {
          actions: {
            kensaku: async (args: {
              denops: Denops;
              ddu: Ddu;
            }) => {
              args.ddu.updateOptions({
                sourceOptions: {
                  _: {
                    matchers: ["matcher_kensaku"],
                  },
                },
              });
              await args.denops.cmd("echomsg 'change to kensaku matcher'");

              return ActionFlags.Persist;
            },
          },
        },
        filer: {
          toggle: true,
        },
      },

Hm... It should use denops dispatcher instead.

@4513ECHO 4513ECHO marked this pull request as ready for review August 26, 2024 09:37
@4513ECHO 4513ECHO changed the title [WIP] Resolve circular reference of imports [RFC] Resolve circular reference of imports Aug 26, 2024
@4513ECHO
Copy link
Contributor Author

This pull request is now ready to use now.
@Shougo Could you release pre-release version to test?

Current dependencies graph:

image

@Shougo
Copy link
Owner

Shougo commented Aug 26, 2024

OK.

@Shougo Shougo mentioned this pull request Aug 26, 2024
@Shougo Shougo closed this in #122 Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants