前端动态修改配置文件 & 数据和业务的关系

Chamberlain99
454 阅读3分钟

前端动态修改配置文件

1.1 如何动态修改前端配置文件

在工作中遇到一个场景，3d机房可视化，从客户的系统跳转到3d系统，通过携带的resource-token来决定要呈现什么模型，具体分为:

  • 广州3d机房
  • 天津3d机房

如果url中有正常携带token则没什么讨论的必要。 如果url中没有携带token，则要设置其默认的token，但是有不能写死在前端

1.2解决方法

1、将resource-token写成一个配置文件xx.json放置在前端的static静态资源文件
2、前端根据url中是否携带resource-token决定是否加载xx.json中的default中的token

Vue.prototype.$rootURI = location.origin + location.pathname.substring(0, location.pathname.lastIndexOf('/') + 1)


const rep = await this.$getAction(this.$rootURI + 'static/data/resource.json')
    this.$ls.set('Resource-Token',rep.default)
    this.getAccountResource(rep.default,()=>{
    setTimeout(() => {
        this.$toast('正在跳转,请稍后',1500,'success')
       this.$router.push({path: '/garden'})        
      }, 1500);
})

数据和业务的关系

开箱既用：就是使用默认值就可以直接吧软件安装在系统后，立即使用了

数据分类：

  • 数据库（dba工程师负责 - 数据表针修改）
  • 运维数据（运维工程是负责）
  • 代码里面的数据（默认值）

数据要解决2个事情：

  • 驱动 - 操作
  • 驱动 - 业务 【数据驱动操作、业务，而不是程序驱动】

当你业务和操作都是程序驱动的时候，未来所有的变更都将需要改代码

变更的2种情况：

  • 运维变更 （因为运维这个东西需要调整）
    • 客户想要达到某种效果，我能够通过运维的方式实现
    • 运维方式：改配置、重新运行程序性、重新部署一个程序、修改主机名|端口号、修改数据库（不修改代码）

    修改后，业务体验一致，功能体验一致，只是表现的方式、业务的流程不同了

    作为前端开发：你能让运维满足以上的条件，那你的开发思维就转变过来了

延展：
SAP\IBM\Oracle 
Q：数据库为什么不需要改代码？
A：因为他们提供了很多运维接口、和配置项去解决问题 
   eg：比如字母大小写敏感，配置项配一下就解决了
  • 业务变更 （业务上有新的需求了）

    • 更高一个层面、是需要通过系统的一些配置去解决

    • EG：机柜告警，标签名称（日能耗|热力图|天空图），可能有客户的字典决定和配置，而非前端写死

总结

  • 多跳出自己的思维框架、不停留在低级的代码层面

  • 多为运维人员考虑、为产品经理、项目经理、售前人员考虑

  • 永远记住：数据驱动呈现 | 业务

  • 写vue\react的时候发现：可以用在很多场景、是因为他们思维转变过来了

    • 不会出现A有一个需求，支持一下；b搞一个东西，也支持一下
    • 比如用vue，我们基本都是遵循其思维方式，你不用写太多东西，多多东西都是通过配置的
    • 如果不遵循其思维，就可以硬生生写，这才叫做开发、写代码
    • 我们需要从开发思维转为研发思维

  • 先抽象、再具象

  • 编程思想：SPI，搞一些钩子，而不是执行一个东西再出来，不要流水线作业

  • 不关心过程、流程，只关心我在流程里面做什么东西，有可能在某个环节嵌入某个东西、拿到你的数据，改掉你的数据（【跟黑Ke的注入技术很大的关系】）

  • 表面上看任何一个地方都要判断有没有resource-token,实际上，只有一块代码需要关心它有没有resource-token，其他地方不关心，这样实现了代码业务之间的解耦。然后把这个token注入到一个变量中。然后判断有没有这个东西，有的话就用这个resource-token,没有的话，就直接使用默认的default中的数据即可。

  • 有点像一个事件机制，我干了这个事情，通知其他的，你们不用干了。

avatar
文章
阅读
粉丝