-
-
Notifications
You must be signed in to change notification settings - Fork 67
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
feat: reduce cognitive complexity #401
Conversation
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.
lgtm
Just look for my last commit plz, I had missed a previous optimization during refactorisation. |
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.
LGTM
Can you update the workflow to fastify-autoload/.github/workflows/ci.yml Line 20 in 3584972
|
I do it in an independent PR @gurgunday : #403 |
I would prefer a review from @climba03003 before merging. |
Can you review @climba03003 plz or can we merge? |
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.
LGTM.
This PR is intended to reduce the overall cognitive complexity of the component, which is imho unnecessarily hard to read, although I understand this is subjective. Basically, I've done a bit of refactoring, breaking down huge functions into smaller ones and limiting the use of nested closures.
I put the
findPlugins
function in its own file to reduce the size ofindex.js
and because it is a clearly separated step.I tried to do the same with
loadPlugins
butvitest
failed to transpile after that... But the two big steps are finding and loading, registering is just a few lines so I think it's ok.I think I've also slightly reduced algorithmic complexity by making a single global iteration on
pluginTree
, including plugin loading, hooks and registration. This also makes it possible to benefit from the current iteration context, instead of making distinct tree traversal for hooks and plugins, although this point isn't quite clear to me yet. So it's not a fix of #383.