Skip to content

refactor(utils): simplify configuration validation and error handling - #4240

Open
KristjanESPERANTO wants to merge 4 commits into
MagicMirrorOrg:developfrom
KristjanESPERANTO:utils/refactor
Open

refactor(utils): simplify configuration validation and error handling#4240
KristjanESPERANTO wants to merge 4 commits into
MagicMirrorOrg:developfrom
KristjanESPERANTO:utils/refactor

Conversation

@KristjanESPERANTO

Copy link
Copy Markdown
Collaborator

I ended up going down a bit of a rabbit hole with this PR. The main goal throughout was to make the code easier to understand and maintain. There are no intended changes to the normal application behavior. The error handling is also more consistent now, with error messages being passed to the point where they are handled instead of being logged in multiple places.

Please let me know if the PR has grown too large or if I have taken things in a direction that would be worth discussing 🙂

Commit 1

I started by looking at checkConfigFile and felt that it was doing too many different things. I split its responsibilities into a few smaller functions to make the overall flow easier to follow.

Outcome: clearer responsibilities and a simpler configuration validation flow.

Commit 2

While working on the file, I also noticed the arrow functions used for top-level functions. They are not wrong, but I find regular function declarations a bit more intuitive and easier to read in this context.

Outcome: a more consistent and readable function style, with the existing behavior preserved.

Commit 3

Finally, I noticed that some validation paths were throwing errors without any message:

throw new ConfigError("");

An error without a message is not very helpful for debugging. This led me to move the error logging to the places where the errors are handled and to make sure that every ConfigError carries a useful message.

Outcome: more consistent error handling and cleaner error output.

Commit 4

After looking at the remaining usages, I noticed that getAvailableModulePositions was only a thin wrapper around the internal modulePositions array. It's not part of the documented API for third-party modules, so I removed it and let moduleHasValidPosition use getModulePositions directly.

Outcome: less indirection and a smaller internal API, without changing the intended behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant