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
The only reason for duplicating user settings files across email and handle was to be able to look for them on disk.
Instead of duplicating them, to look for a matching handle etc., one could just as well parse the content of the .env files and look for the matching handle there.
Hence, I'd suggest to refactor that part of the code and only maintain exactly one kind of .env file per instance and user with the following naming convention.
user-{user_id}.env
instance-{instance_id}.env
This way, changes to user handles or instance names or user email addresses or other movable parts won't affect these .env files as the ids are permanent.
@fredericenard, would you agree that the current code design should be improved for a professional product?
Would you agree on the proposed implementation and be able to do the refactor?
Happy to call later!
The text was updated successfully, but these errors were encountered:
The only reason for duplicating user settings files across email and handle was to be able to look for them on disk.
Instead of duplicating them, to look for a matching handle etc., one could just as well parse the content of the .env files and look for the matching handle there.
Hence, I'd suggest to refactor that part of the code and only maintain exactly one kind of
.env
file per instance and user with the following naming convention.This way, changes to user handles or instance names or user email addresses or other movable parts won't affect these
.env
files as the ids are permanent.@fredericenard, would you agree that the current code design should be improved for a professional product?
Would you agree on the proposed implementation and be able to do the refactor?
Happy to call later!
The text was updated successfully, but these errors were encountered: