You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I saw the repetitive definition of exported functions that all got state as an argument which simply gets passed through to the execution of the getOption function. I tried to refactor this and came up with the upcoming code (which I haven't tested in terms of runtime functionality so far, but theoretically it should work).
... so the main difference would be that the getOption function returns a function that takes state as a parameter but has the proper option key preserved due to the usage of a closure. This would result to less function declarations in the code base and no need to pass through state down the execution chain.
Do you see a need for this? If yes, I can send a PR.
The text was updated successfully, but these errors were encountered:
Hi, just checked some code of the repo out of interest and saw the code of the src/utils/options.js file that looks like this (branch master, today):
I saw the repetitive definition of exported functions that all got
state
as an argument which simply gets passed through to the execution of thegetOption
function. I tried to refactor this and came up with the upcoming code (which I haven't tested in terms of runtime functionality so far, but theoretically it should work).... so the main difference would be that the
getOption
function returns a function that takesstate
as a parameter but has the proper option key preserved due to the usage of a closure. This would result to less function declarations in the code base and no need to pass throughstate
down the execution chain.Do you see a need for this? If yes, I can send a PR.
The text was updated successfully, but these errors were encountered: