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

Make base store non Singleton #6690

Merged
merged 118 commits into from
Dec 15, 2022
Merged

Make base store non Singleton #6690

merged 118 commits into from
Dec 15, 2022

Conversation

Nokel81
Copy link
Collaborator

@Nokel81 Nokel81 commented Dec 1, 2022

resolves #4884

This PR does the following:

  • Removes Singleton as a super class of BaseStore
  • Makes sure extension API doesn't break, while still deprecating the SIngleton style static methods
  • Removes all the rest of the uses of Singleton that are not related to the extension API
  • Makes the Store migrations injectable and a dependency of the stores
  • Adds support for multiple runAfter's (to fix a exception in renderer)
  • Removes legacy global execHelm in favour of explicitly using the injectable version.

@Nokel81 Nokel81 added the chore label Dec 1, 2022
@Nokel81 Nokel81 added this to the 6.3.0 milestone Dec 1, 2022
@Nokel81 Nokel81 requested a review from a team as a code owner December 1, 2022 14:27
@Nokel81 Nokel81 requested review from jansav and Iku-turso and removed request for a team December 1, 2022 14:27
@github-actions
Copy link
Contributor

github-actions bot commented Dec 2, 2022

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@Nokel81 Nokel81 force-pushed the make-BaseStore-non-singlton branch from df5117f to 06ec089 Compare December 2, 2022 15:36
@github-actions
Copy link
Contributor

github-actions bot commented Dec 2, 2022

Conflicts have been resolved. A maintainer will review the pull request shortly.

@github-actions
Copy link
Contributor

github-actions bot commented Dec 5, 2022

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@Nokel81 Nokel81 force-pushed the make-BaseStore-non-singlton branch from 15744a9 to 40cb95a Compare December 6, 2022 12:48
@github-actions
Copy link
Contributor

github-actions bot commented Dec 6, 2022

Conflicts have been resolved. A maintainer will review the pull request shortly.

Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
- Use it for ClusterStore

Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
- That value is not used anywhere in code

Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Comment on lines +61 to +62
ensureDir: async (path, opts) => ensureDirSync(path, opts),
ensureDirSync,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if these should be deprecated, or even left out of fs.injectable, as using them is mostly sign of trouble, and/or the responsibility of other abstraction. WDYT?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are confused because our own abstractions of writeFile, etc... use these.... so they are certainly required.

Comment on lines +27 to +29
} catch {
// ignore
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These make me uneasy. You? :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Offtopic: such a long filename with many meanings kinda hard to perceive get-configuration-file-model.global-override-for-injectable.ts. Could we have more clear/simple (file|class?) names?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least global-override-for-yaddayaddayadda will get shorter soon enough. Outside of that, naming should follow common sense, or what is the proposal? :)

apiManager.registerApi(api);
};

autoRegistrationEmitter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought: in a sense, emitters and their listeners, such as seen here, do something that Runnable could do, but without the burden of having to make a big deal about getting listeners "enlisted". That would be the same thing as registering the injectable, which is more like a convention.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder: this is a hack to preserve behaviour while making sure circular dependencies don't exist.

return {
id: "setup-root-mac-classname",
run: () => {
const rootElem = document.getElementById("app");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side-effect.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By that definition, so it render. So I think your point is moot.

Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Signed-off-by: Sebastian Malton <sebastian@malton.name>
Comment on lines +24 to +25
encoding: "utf-8",
spaces: 2,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These could be always set in writeJsonSync.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? This is wrieJsonSync

const beforeFrameStarts = runMany(beforeFrameStartsInjectionToken);
const currentlyInClusterFrame = di.inject(currentlyInClusterFrameInjectable);

return async () => {
await evenBeforeFrameStarts();
await beforeFrameStartsFirst();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which frame starts? (since below we're seeing distinguishing btw cluster/main frame).
Why we should wait for? (just random question for the first time looking at the code)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either frame, this function is here to consolidate all the initialisation steps (and the temporal dependencies between them). The reason why we split up these Runnable's (which is the type we created to describe each of these steps) into separate phases (which is what each of these runMany calls represents) is because sometimes there is a general need to have a step complete before anything else is run.

We could have instead specified a runAfter for every other runnable (which is how we specify the temporal ordering dependencies) but that seemed to be too repetitive.

const joinPaths = mainDi.inject(joinPathsInjectable);
const homeDirectoryPath = mainDi.inject(homeDirectoryPathInjectable);

ensureDirSync(joinPaths(homeDirectoryPath, ".kube"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this access actual filesystem or the fake one? The actual one is not to be accessed in a unit test.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This accesses the fake one because we have already overridden fsInjectable for mainDi above on line 183

Signed-off-by: Sebastian Malton <sebastian@malton.name>
@Iku-turso Iku-turso merged commit 25f37ac into master Dec 15, 2022
@Iku-turso Iku-turso deleted the make-BaseStore-non-singlton branch December 15, 2022 15:07
stefcameron added a commit to Mirantis/lens-extension-cc that referenced this pull request Mar 28, 2023
- https://github.com/lensapp/lens/blob/master/packages/core/src/extensions/extension-store.ts
- lensapp/lens#6690 ("Make base store non Singleton")
- lensapp/lens#4573 ("Elimination of global shared state")

The `createInstance()` and `getInstance()` methods had been deprecated in the Lens
Extensions API, so they have been eliminated from our code base also. But we're still
using "global shared state" Cloud and Sync store instances. It's just that Lens isn't
the one creating and holding the instance anymore, we are.
stefcameron added a commit to Mirantis/lens-extension-cc that referenced this pull request Mar 28, 2023
…ase (#1359)

- https://github.com/lensapp/lens/blob/master/packages/core/src/extensions/extension-store.ts
- lensapp/lens#6690 ("Make base store non Singleton")
- lensapp/lens#4573 ("Elimination of global shared state")

The `createInstance()` and `getInstance()` methods had been deprecated in the Lens
Extensions API, so they have been eliminated from our code base also. But we're still
using "global shared state" Cloud and Sync store instances. It's just that Lens isn't
the one creating and holding the instance anymore, we are.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BaseStore
3 participants