在项目持续过程中，大概率存在多岗位参与、同岗位多人参与、长期进行的情况，中间交错进行，若是随意添加与修改，没有相应的规范，会导致大屏越来越难以维护，出现问题也难以排查。

在长期项目实践过程中总结出下面的规范，在开展大屏项目时，依照这些规范执行，可以使得项目协作更加顺畅，大屏的可维护性更高。

1、主要内容

1.1 命名

大屏中的内容随着项目的推进，会越来越多，如果不通过命名来作区分，同名内容越来越多，会越来越难以分辨，所以需要尽可能使用有实际意义的命名。

1.1.1 系列名称

🚫 避免使用无意义的系列一、系列二。

✅ 使用与业务相关的温度、湿度等。

1.1.2 分组名称

🚫 避免使用分组1、分组2

✅ 使用顶部标题、底部工具栏等。

1.1.3 组件名称

有条件的情况下，使用诸如温度趋势折线图来代替基本折线图。

1.1.4 数据过滤器名称

🚫 避免使用数据过滤器1、数据过滤器2

✅ 根据实际功能命名，如API接口初始格式化、value字段保留两位小数、计算当前时间等。

1.1.5 回调名称

🚫 避免使用 data1、data2、s 这种难以辨别的回调名称。

✅ 根据实际内容与作用进行命名，如 userInfo、today、车辆定位数据、weather_content 等，中、英文都可以，命名风格也不作要求。

1.1.6 轮播表格字段

🚫 避免直接使用 column1、column2

✅ 使用预业务相关的姓名、性别、name、time

1.1.7 动态面板状态

🚫 避免使用默认的状态一、状态二、状态三

✅ 使用与实际业务关联的名称，如小学/初中/高中、全国/省级/市级、工厂/车间/产线等

1.1.8 条件名称

🚫 避免使用默认的条件

✅ 使用对应的逻辑说明，如存在有效值、s为1、可交互等。

1.2 分组

除了数据容器以外，必须按照实际展示区域内容分组，禁止按照类别分组（在不同区域的图片、形状、翻牌器等分在同一个组中）

1.3 数据过滤器

数据过滤器在使用过程中，鼓励写出更通用的组件，但不鼓励将复杂逻辑叠加在一个组件中。

想要数据过滤器容纳范围变大，变得更通用时，通常需要增加更多的逻辑判断，而这些额外的逻辑判断，会导致数据过滤器的复杂度增加。

当一个组件中需要根据不同的参数，返回不同结构的数据时，就可以考虑拆分数据过滤器了。

1.4 数据容器(组件)

数据容器(组件)用于对各种数据进行汇集、中转，由于回调参数全局通用的特性，在任意一个动态面板、引用面板中的回调参数都会传递到整个屏的各个地方。

当存在多层级、多组件共用同一份数据时，仅在需要该数据所有层级中的最顶层添加一个数据容器即可，避免多次请求造成浪费与网络拥堵，并且规避掉后续因路径变化、参数变更导致的重复修改问题。

1.5 动态面板

使用动态面板时，一般操作是需要展示时，控制其显示，并切换到对应状态，不需要显示时，执行【控制隐藏】的动作。当该动态面板有多个控制入口时，每个入口都需要配置两个动作【控制显示】与【切换状态】，遗漏任何一个都会使得最终的显示结果不符合期望。

可以在状态中添加一个【空】状态，该状态中不添加任何组件，切换到该状态时，最终效果等同于执行了隐藏动作。通过该方案，任何指向动态面板的控制，都只需要执行一个【切换状态】的动作，入口越多越有优势，并且动态面板的状态管理也更加清晰。

2、其他

存在显隐交互式时，尽量对组做显隐操作，而不是对具体组件做显隐操作，这样原区域有新增内容的话，就不需要再逐个配置，直接可以实现，后期扩展非常方便。

3、注意事项

（1）各个组件中的最小/大值谨慎设置，非必要不设置，否则可能会导致接入数据的展示异常。

（2）复制组件后，若存在多余的自定义事件、回调参数和数据过滤器，记得删掉，避免干扰。

4、总结

上述的各项规范原则都是为了使项目更加容易维护，并尽可能优化大屏性能。部分情况下按照规范实施可能会导致比平时多花一些时间，一旦项目紧急，为了赶项目不去注意。但越是这种时候，越需要去注意，否则着急忙慌赶出来的项目一堆问题，排查成本还非常高，需要花更多的时间去处理，最后陷入时间越来越不够的死循环。