Skip to content

refactor: upmconfig load logic #337

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

Merged
merged 1 commit into from
May 22, 2024
Merged

refactor: upmconfig load logic #337

merged 1 commit into from
May 22, 2024

Conversation

ComradeVanti
Copy link
Collaborator

Currently we have a service function for determining the directory in which the upmconfig is located. On load and save the actual file path of the config is constructed from this directory.

There is no need for this delayed path construction. We can instead make the service resolve the actual path of the config file right away. This makes client code a little shorter.

Currently we have a service function for determining the directory in which the upmconfig is located. On load and save the actual file path of the config is constructed from this directory.

There is no need for this delayed path construction. We can instead make the service resolve the actual path of the config file right away. This makes client code a little shorter.
@ComradeVanti ComradeVanti merged commit 3d8b110 into master May 22, 2024
4 checks passed
@ComradeVanti ComradeVanti deleted the config-file-path branch May 22, 2024 12:38
ComradeVanti added a commit that referenced this pull request May 22, 2024
Currently we return the path of the upm config file we modified after a save so that the path can be in logging. This is done because previously we only had access to the configs directory path in the client code.

Since #337 we also have access to the file path in client code and so dont need this return value.
ComradeVanti added a commit that referenced this pull request May 22, 2024
Currently we return the path of the upm config file we modified after a save so that the path can be in logging. This is done because previously we only had access to the configs directory path in the client code.

Since #337 we also have access to the file path in client code and so dont need this return value.
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