-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Optionally include tags in Webhook #72
Optionally include tags in Webhook #72
Conversation
Fixed some of the formatting things that CI was complaining about. |
Thanks @MikeLundahl for sorting this out. I will get that reviewed today or tomorrow morning. |
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 hope it's okay with @DavideIadeluca to leave out Teams, it could be contributed later.
I've taken the time to review your PR and there's one thing I'd prefer seeing changed. The note about formatting you can probably forget about, it occurred only once.
Good job on this one!
@@ -148,7 +152,8 @@ export default class WebhookEditModal extends Modal { | |||
<div> | |||
<h3>{this.translate(group)}</h3> | |||
{events.map((event) => ( | |||
<Switch state={this.webhook.events().includes(event.full)} onchange={this.onchange.bind(this, event.full)}> | |||
<Switch state={this.webhook.events().includes(event.full)} |
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.
Formatting changes should be left out. There are a few reasons for that, but the most important one is that it makes the review process so much harder. You really want to just submit the changes that have an actual impact. Especially in open source where you want to make the impact of reviewal as non-existent as possible.
Understand that you could have submitted these changes unknowingly, most IDE's have settings that enable auto formatting before commit. It's best to disable this feature and use the keyboard shortcut to make this a manual action. If per-project settings are possible, then doing that would be an alternative.
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 can definitely second that, but as this is such a minor case I wouldn't bother much retroactively now
src/Models/Webhook.php
Outdated
$tagsApplied = Tag::whereIn('id', $this->tag_id)->get(); | ||
|
||
return $tagsApplied->map(function ($tag) { | ||
return $tag->name; | ||
})->toArray(); |
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.
With eloquent it's always a better approach not to retrieve all entries at once. Especially on databases with millions of records this is going to be an issue.
For these use cases you can use a chunking method, each
for instance is once of those, but perhaps map()
is also a method that chunks: like chunkMap: https://github.com/laravel/framework/blob/05d920410e58f04b13dcaa83937b9d4574fc9b3f/src/Illuminate/Database/Concerns/BuildsQueries.php#L81
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.
Thanks! What about the chunk()
method? Did some reading, I could do something like this:
$tagsApplied = [];
Tag::whereIn('id', $this->tag_id)->chunk(100, function ($tags) use (&$tagsApplied) {
$tagsApplied = array_merge($tagsApplied, $tags->map(function ($tag) {
return $tag->name;
})->toArray());
});
return $tagsApplied;
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.
If you're only after the name. I would use a select("name") and get(). You won't need to loop or chunk 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.
While generally I would agree that chunking is the way to go, I'm not sure if it is of much use here.
Realistically, every community has less than 100 tags, so performance wise it wouldn't really make a difference. I feel like at the point where a community has more than 100 tags, other parts of the ecosystem would be already causing more performance issues.
So in favor of code readability, I would go with the initially suggested method.
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.
The initial one is still unnecessary:
$tagsApplied = Tag::whereIn('id', $this->tag_id)->get(); | |
return $tagsApplied->map(function ($tag) { | |
return $tag->name; | |
})->toArray(); | |
return Tag::select('name')->whereIn('id', $this->tag_id)->pluck('name')->toArray(); |
Is exactly the same thing.
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 tried the simplified version with select and pluck... Works on my end so I pushed the tweak. Have a look.
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.
Looks good to me
My pleasure! :) |
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.
Working as expected – Looks good to me. @luceos please have a look at the conversation about using chunking and let me know if you still would change it up. From my side this PR is good for a merge as it is right now.
src/Models/Webhook.php
Outdated
$tagsApplied = Tag::whereIn('id', $this->tag_id)->get(); | ||
|
||
return $tagsApplied->map(function ($tag) { | ||
return $tag->name; | ||
})->toArray(); |
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.
While generally I would agree that chunking is the way to go, I'm not sure if it is of much use here.
Realistically, every community has less than 100 tags, so performance wise it wouldn't really make a difference. I feel like at the point where a community has more than 100 tags, other parts of the ecosystem would be already causing more performance issues.
So in favor of code readability, I would go with the initially suggested method.
@@ -148,7 +152,8 @@ export default class WebhookEditModal extends Modal { | |||
<div> | |||
<h3>{this.translate(group)}</h3> | |||
{events.map((event) => ( | |||
<Switch state={this.webhook.events().includes(event.full)} onchange={this.onchange.bind(this, event.full)}> | |||
<Switch state={this.webhook.events().includes(event.full)} |
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 can definitely second that, but as this is such a minor case I wouldn't bother much retroactively now
Fixes #0000
Discord & Slack
Changes proposed in this pull request:
Added "Include tags" in the edit webhook modal (Frontend)
Reviewers should focus on:
Screenshot
Settings:
Discord:
Slack:
Confirmed
composer test
).Required changes: