那,顺便我还想到一个可以优化流程的点
- 如果策划对excel用的很熟悉的话,完全可以利用excel的自动统计提前完成一些需要运行时再次计算的数据
- 这些数据包括不限于某个词条某个属性的总数/每种类型的数量等等
哇,真是太爽了.
当然这个与这个帖子主题关系不大了,属于配表的结构组织了. 但是还是挺好的一个点.
校验的是数据类型，导出时校验和运行时校验配置类型错误谁更好，这就相当于在编辑器报错，和游戏运行中报错，如果连这个都无法分辨好坏要么是新手，要么就是自己不对必须别人承认自己对的犟种
而这两种情况我都不会继续回复了
犟种，咋还进行人身攻击了？
我只能说你对数值表校验仍停留着前端非常片面的模式，也证明兄台平时的工作经验也仅限于校验类型，业务逻辑中可能到处充满数值表遍历逻辑，不影响性能才怪，或许可能还额外增加一些数据管理类，我这是大项目经验之谈，小项目各种JSON满天飞当然是没问题了。
可以说我例举的你插件的缺点你一个都解决不了，仅抓着类型校验，这要是老手该有的觉悟，我也是无话可说，兄台开心就好，千万别进行人身攻击，都是读书人，素质起码要高点！
呵呵，首先你认为 编辑器报错，和游戏运行中报错 是运行中报错更好，如果你觉得我说的不对那么就是承认的提前校验数据优于运行时校验
其次，你说的缺点甚至都忘了你自己的问题和我的回答
你的回答就像 1 + 1 = 3，还要必须别人说自己对一样
另外你的使用方式我在上个项目早就经历过了，再次重申下缺点
-
所有配置读写逻辑得自己写且不保证完全正确（程序员不可能完全无 bug）
-
没有导出时数据类型校验和运行时数据类型校验 （得自己写）
-
配置表如果错误必须在运行时中才能检查到，还必须提前写表中每个属性的校验逻辑
-
任何人如果对表属性进行增删改都 必须通知开发人员同步改代码，如果漏通知开发人员那么所有人都不知道
-
不能保证配置表的读写逻辑完全正确（程序员不可能完全无 bug）
-
相比热更一个 ts 文件，配置文件的 bin 集合体积更大
另外你说的缺点只是我的插件缺少 bin 压缩以及你说的预处理，而你说的预处理任何配置方式都可以自己加，你可以包装一个 Map，我也可以基于配置加一个 Map，都是手写而已
相比起来谁的缺点多呢？
哎！和你沟通不了，前面三点请看我上面的回复，都给你说明。
再就是运行时数据处理“可以后面加”，这是神马理论？我的方式一次性处理各种数据校验、数据预处理（给数据加索引）、各种配置表之间的数据依赖，这些点你都要后面加，我都要要后期加各种数据处理了，请问你的类型校验有个神马用？
算了，你赢了！！！你的插件最好！
呵呵，请问你的预处理和其他逻辑是自动生成吗？如果不是生成的，那么如果我把插件加上导出 bin 文件，再加上你手写的各种预处理逻辑，那么这时候有什么区别呢？ 所以我说任何配置方式都可以自己加
我咋感觉还是表头加入数值类型比较好呢 读取来直接用
不过一般就用到string和number 复杂类型策划配表得搞辅助列(策划手头一份带辅助列和公式的原始表 导出给前端还得一份纯净的)
相对于luban的优点呢，我还是比较支持wolong说的不要搞重复的轮子的。现在基本上都直接上luban了。
就两字，简单，还有方便使用，luban我写之前看了下要求的格式和定义的方式还挺多有一定的学习成本
就像 webpack 和 vite，webpack 成熟功能多，但是新人基本无法第一时间上手已有项目，这个插件只是适合想快速上手，使用方便且希望服务端支持 JSON 的
你说的表直接的依赖关系luban就可以解决，你这些所谓的检查也是post-pipeline，也是完全一个新的建立在导表出来的helper类上就能解决的问题，完全可以分离开。都不是一回事。
第一次看到luban这个工具,然后看了下,我天,配置表导出功能都能做成这么一个工具…这项目真的不是为了给个人用来刷star的吗?
1赞
可能你的项目用不到luban所提供的功能，luban是十分强大的表格配置方案。我做过的几款商业项目都是上车的，自定义bean,enum，抽象能力十分强
多语言支持还是有需要的，就像在 java 服务端使用自己的语言配置表比 JSON 更好，至于其他功能看自己是否需要了
因为要前后端通用，那种类型定义只适合前端，不可能让策划整两套数值表，策划会骂娘，何况大项目一般上百个配置表，你可能会说还是整一套表，后端不读那一行就行了，可策划为啥要管你前端的字段类型？为啥后端就不用管？你能把楼主的这套理论和策划讲清楚吗？
所以我说楼主的实现固然有他的优点，但缺点如下：
1、加重了策划的负担。
2、复杂的数据处理需要二次加工，不能预先索引数据，如果不进行额外的数据管理，将在业务逻辑中增加不必要的性能损耗，楼主的数据还是不可修改的，比如解析配置表时对通配符的替换，该用什么替换，如何处理？
3、无法一次性处理数值表依赖关系，比如任务表依赖奖励表，奖励表依赖道具表。
4、一般情况，技术是明确知道策划提供的数值表每个字段是干什么用的，所以我们手动编写一个映射对象轻而易举，那么类似楼主的做法也是意义不大的。如果策划改类型，忘了说，不是还有测试兜底吗？再说改了类型不用改业务逻辑的吗？没有这种情况吧，如果策划和技术都忘了，请让策划背锅。
5、无法实现动态远程加载更新，需要bundle热更或者整包发布，整包发布肯定不行，因为各平台都有审核期，不能随性而为。
申明一点，小项目这么整无可厚非！
需要抽象类型的时候还是luban用的爽
嗯. 我对这个工具没有恶意. 这么多star也说明使用者多,用的人多迭代多bug就少,功能就更健壮. 我去试试.
举个例子就是
Item表有类型是Material还是Food还是xxx的时候
如果配置1,2,3也可以，但是写一个enum配置Material，Food，xxx，然后在Item里写
type
ItemEnum
你就是if(xxx.type === ItemEnum.Material )而不是自己在ts里定义一个enum或者写出if(xxx.type===1)这样的代码了
归根结底都在争辩数值表的使用方式而已，我的方式是直接导表使用CSV或其压缩包，按需加载使用，使用时一次性做了所有数据处理，既然后期又得搞helper做数据处理，为啥不首先就处理好呢？
因为你的方式需要程序手动去维护啊 
，还没有任何类型提示