refactor(utils): Configure theme using .env environment variables

[woeoio]

Configure theme options via the .env file for easy modifications.

[woeoio]

放到env和便于修改有什么联系么？在原有的代码里，通过主题抽屉修改之后直接复制粘贴不是比在env里改更便捷么？我没有看到有什么实质上的优化或者意义

便利性就在于, 当生产编译之后, 客户希望偶尔变化以下默认的主题结构, 比如有时候希望默认打开就是"暗黑主题模式", 那么我只需要修改 .env 的变量值就可以了, 而不需要修改源代码之后重新编译和发布.

[Azir-11]

便利性就在于, 当生产编译之后, 客户希望偶尔变化以下默认的主题结构, 比如有时候希望默认打开就是"暗黑主题模式", 那么我只需要修改 .env 的变量值就可以了, 而不需要修改源代码之后重新编译和发布.

env也是源码的一部分，你改了env也需要重新打包发布

[woeoio]

放到env和便于修改有什么联系么？在原有的代码里，通过主题抽屉修改之后直接复制粘贴不是比在env里改更便捷么？我没有看到有什么实质上的优化或者意义

便利性就在于, 当生产编译之后, 客户希望偶尔变化以下默认的主题结构, 比如有时候希望默认打开就是"暗黑主题模式", 那么我只需要修改 .env 的变量值就可以了, 而不需要修改源代码之后重新编译和发布.

因为这个变化可能是经常性的, 目前的情况是菜单就3个, 使用左右布局结构, 不如使用顶部菜单布局好看, 并且要关闭 tab 也签,

但是后面慢慢的功能做上去之后, 他们又希望很方便的切换到左右布局, 这些作为默认值下发到浏览器,

至于最终用户想要什么主题, 那确实是他们自己从抽屉去修改就好

[Azir-11]

你不会是开dev模式给客户用的吧？

[woeoio]

便利性就在于, 当生产编译之后, 客户希望偶尔变化以下默认的主题结构, 比如有时候希望默认打开就是"暗黑主题模式", 那么我只需要修改 .env 的变量值就可以了, 而不需要修改源代码之后重新编译和发布.

env也是源码的一部分，你改了env也需要重新打包发布

好吧, 我错了, 哈哈, 那我取消 pr

[woeoio]

Member

那不会

[honghuangdc]

1. 系统配置没有对接用户，想要变更生产的配置得重新编译和部署的
2. 这边给你的建议是将配置对接用户，这张就满足你的需求了

[woeoio]

1. 系统配置没有对接用户，想要变更生产的配置得重新编译和部署的
2. 这边给你的建议是将配置对接用户，这张就满足你的需求了

好的, 谢谢,

[Azir-11]

因为这个变化可能是经常性的, 目前的情况是菜单就3个, 使用左右布局结构, 不如使用顶部菜单布局好看, 并且要关闭 tab 也签,

但是后面慢慢的功能做上去之后, 他们又希望很方便的切换到左右布局, 这些作为默认值下发到浏览器,

至于最终用户想要什么主题, 那确实是他们自己从抽屉去修改就好

你这个情况最好就是拿去给后端存，直接在后台配置一下就全系统改掉了，或者是独立出一个在服务端的json文件也行，反正只要这个配置还存在于羡慕源码里面，你怎么改都是需要重新打包的

[woeoio]

因为这个变化可能是经常性的, 目前的情况是菜单就3个, 使用左右布局结构, 不如使用顶部菜单布局好看, 并且要关闭 tab 也签, 但是后面慢慢的功能做上去之后, 他们又希望很方便的切换到左右布局, 这些作为默认值下发到浏览器, 至于最终用户想要什么主题, 那确实是他们自己从抽屉去修改就好

你这个情况最好就是拿去给后端存，直接在后台配置一下就全系统改掉了，或者是独立出一个在服务端的json文件也行，反正只要这个配置还存在于羡慕源码里面，你怎么改都是需要重新打包的

好的, 明白了, 感谢指教

[Azir-11]

再补充一个，我们系统内的env全部都用ts约束了名称，你要加env变量的话最好是加上类型约束

[woeoio]

再补充一个，我们系统内的env全部都用ts约束了名称，你要加env变量的话最好是加上类型约束

好的, 刚才看了以下 env.d.ts 确实是有约束, 很规范啊!

请问这些约束, 你们是手写的还是有什么便捷工具呢? 我看全部还写了规范的注释

[Azir-11]

请问这些约束, 你们是手写的还是有什么便捷工具呢? 我看全部还写了规范的注释

手写的，主分支的每一次pr合并都是严谨的，我们会严格保证代码质量

[woeoio]

很不错!　这确实是我第一次见到的如此严谨的高质量项目