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

Luigi core config refactorings #187

Merged
merged 14 commits into from
Nov 13, 2018

Conversation

jesusreal
Copy link
Contributor

Description

Changes proposed in this pull request:

  • Create class for Luigi Config
  • Avoid using interval to check for Luigi config existency -> Luigi initializes up to 50ms faster
  • Update unit tests
  • Use correct key for screenshots folder in Cypress config

Related issue(s)

@parostatkiem-zz parostatkiem-zz self-assigned this Nov 5, 2018
Copy link
Contributor

@parostatkiem-zz parostatkiem-zz left a comment

Choose a reason for hiding this comment

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

I like the changes!
Just a few how to be modern suggestions from my side, feel free to implement them or not.
One obsolete console.log(), 2 useless (I think) variable declarations. Please explain or remove them :)

core/src/services/config.js Outdated Show resolved Hide resolved
core/src/services/config.js Outdated Show resolved Hide resolved
};
this.config;

this.configReadyCallback = function() {};
Copy link
Contributor

Choose a reason for hiding this comment

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

I think here's the same story as with this.config; above. It doesn't change anything if you remove this line.

Copy link
Contributor Author

@jesusreal jesusreal Nov 5, 2018

Choose a reason for hiding this comment

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

This initial value is meant to enable calling this.configReadyCallback without the need of an if block to prove if it is defined or not.

value = value.apply(this, parameters);
if (isPromise(value)) {
return value;
getConfig() {
Copy link
Contributor

Choose a reason for hiding this comment

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

You can be more modern here and use a getter.

 get Config() {
    return this.config;
  }

and then
this.getConfig() -> this.Config.

I'm not requesting this change but I'd like you to know it :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I consider that option, but I see unnecessary to create a breaking change for this tiny improvement.

core/test/config.spec.js Outdated Show resolved Hide resolved
parostatkiem-zz
parostatkiem-zz previously approved these changes Nov 7, 2018
…-refactorings

# Conflicts:
#	core/src/navigation/LeftNav.html
#	core/src/navigation/TopNav.html
#	core/src/navigation/services/navigation.js
#	core/src/services/routing.js
@kwiatekus kwiatekus self-assigned this Nov 8, 2018
);
};
// Expose it window for user app to call Luigi.setConfig()
window.Luigi = LuigiInstance;
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to add everything to window.Luigi Wouldn't setConfig be enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For consistency I decided to expose the whole Luigi config instance, as this is what we are exporting through es module. But on the other side, I am in favour of exposing as less as possible to the window object, so I will apply the change you proposed. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now I know why I did not do that. Luigi config is a class, so setConfig is interacting with other members of the class. Therefore IMHO the best solution is to expose the whole instance

return value;
}
}
return wrapAsPromise(value);
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this function? Wouldn't that be easier to wrap it here? :) I't not used anywhere else

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, removed

nextValue = nextValue[propertyPath[propIndex++]];
class LuigiConfigManager {
constructor() {
this.configReadyTimeout = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this object?
The valueMs is not used anywhere. My suggestion would be to change this configReadyTimeout from an object to a string with just the id value.
The other option would be to use this valueMs in the timeout below, but then I don't like the name of the object, because what is an id of a timeout then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Id of a timeout makes sense to me, it is the way you identify a timeout you set in case you want to do something with it, like removing it. I will use valueMs instead the magic number '2000' when setting the timeout and keep the object.

kwiatekus
kwiatekus previously approved these changes Nov 9, 2018
@jesusreal jesusreal dismissed stale reviews from kwiatekus and parostatkiem-zz via 5779e96 November 9, 2018 09:50
@jesusreal jesusreal requested a review from bszwarc as a code owner November 9, 2018 09:50
parostatkiem-zz
parostatkiem-zz previously approved these changes Nov 9, 2018
@@ -286,7 +286,7 @@ When loading, the **viewUrl** uses the following dynamic URL parameters:
- `sort = asc`

```
Luigi.setConfig({
window.Luigi.setConfig({
Copy link
Contributor

Choose a reason for hiding this comment

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

It still should work with just Luigi.setConfig right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, everywhere is used with Luigi.setConfig. I just added it here to the documentation for consistency

Copy link
Contributor

Choose a reason for hiding this comment

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

So it's ok with this task, but I guess for the future we should set it to just Luigi.setConfig, it just seems easier ;)

@@ -286,7 +286,7 @@ When loading, the **viewUrl** uses the following dynamic URL parameters:
- `sort = asc`

```
Luigi.setConfig({
window.Luigi.setConfig({
Copy link
Contributor

Choose a reason for hiding this comment

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

So it's ok with this task, but I guess for the future we should set it to just Luigi.setConfig, it just seems easier ;)

…-refactorings

# Conflicts:
#	core/src/App.html
#	core/src/Authorization.html
…-refactorings

# Conflicts:
#	core/src/navigation/TopNav.html
@jesusreal jesusreal merged commit 273f607 into SAP:master Nov 13, 2018
@jesusreal jesusreal deleted the luigi-core-config-refactorings branch December 21, 2018 08:05
stanleychh pushed a commit to stanleychh/luigi that referenced this pull request Dec 30, 2021
* Refactor Luigi config code in core to be a class

* Encapsulate configNotReadyCallback in luigi core config class

* move object generic methods to helpers files

* Use proper key in cypress config for screenshots folder

* Cosmetic changes based on pull request review

* Small change in docu for consistency

* Remove wrapAsPromise function and use it as inline code

* use timeout value in ms instead of magic number in luigi config file

* Small change in docu for consistency
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants