-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Conversation
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
df5117f
to
06ec089
Compare
Conflicts have been resolved. A maintainer will review the pull request shortly. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
15744a9
to
40cb95a
Compare
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>
.../get-configuration-file-model/get-configuration-file-model.global-override-for-injectable.ts
Show resolved
Hide resolved
ensureDir: async (path, opts) => ensureDirSync(path, opts), | ||
ensureDirSync, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
} catch { | ||
// ignore | ||
} |
There was a problem hiding this comment.
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? :)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 register
ing the injectable
, which is more like a convention.
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side-effect.
There was a problem hiding this comment.
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>
encoding: "utf-8", | ||
spaces: 2, |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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")); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>
- 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.
…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.
resolves #4884
This PR does the following:
Singleton
as a super class ofBaseStore
SIngleton
style static methodsSingleton
that are not related to the extension APIrunAfter
's (to fix a exception in renderer)execHelm
in favour of explicitly using the injectable version.