-
Notifications
You must be signed in to change notification settings - Fork 2
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
Refactor the command for creating a local development environment #39
Refactor the command for creating a local development environment #39
Conversation
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
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.
good points
- i really liked the breakdown you made with the build.ts file
- i really liked the input process
in discussion point:
-
using .then instead of await function buildLocalEnv created a very messy code that is hard to track or understand. IMO we should use async/await
-
executeShellCommand should support sync and async.
src/utils/build.ts
Outdated
progressReporter({increment: 100 , message: 'failed to initialize the hub cluster'}); | ||
reject('OCM extension, failed to initialize the hub cluster'); | ||
}); | ||
}) |
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 is less clean than using await.
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 so.
before, after each await statement, we needed to sleep,
using this callbacks technique, and we sleep no more.
:-)
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.
also, with the awaits statements,
we dropped granular control of the displayed message.
we didn't handle rejected promises,
we just let them all drop into the catch clause of the try-catch statement.
now, using the catch callbacks, we handle rejections better at the time they arrive,
we have full control over what is being displayed to the user, and what is being done after the rejection.
if we were to try and do this with previous iteration using the await statements,
I'm guessing it wouldn't have looked all that well with a million try-catch/switch/if statements.
🤔
IMO
the use of the await statements was cool and pretty,
but, as it was, it didn't get half the work done as the current promise and callbacks technique,
so I'm not sure the two code iterations are comparable.
😃
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.
but we could handle the rejection of the promise.
e.g
acceptJoinRequests rejection promise could also take care of
console.debug('failed to accept join requests');
console.error(stderr);
progressReporter({increment: 100 , message: 'failed to accept the join request made from the managed clusters'});
reject('OCM extension, failed to accept the join request made from the managed clusters');
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Thanks. :-)
I think it looks better this way, about the readability,
I should have pointed out, I fixed executeShellCommand. |
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
src/utils/build.ts
Outdated
let kindClustersCreated = Promise.all(clusterPromises); | ||
kindClustersCreated | ||
.then(() => { | ||
/* ################################ ## |
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.
doesn't need to be so big
// Initialize the Hub Cluster
could be enough
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
Signed-off-by: Tomer Figenblat <tfigenbl@redhat.com>
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.
very good!
you can merge it to my branch
No description provided.