ECharts扩展流式布局 需求ECharts 的设计是每个元素在画布上绝对定位的,这样元素多了可能出现重叠问题。设计师为了让业务方的不同场景都可以自动解决这些布局问题,希望我们能支持类似 DOM 的流式布局。 方案设计Plan1:二次绘制(在组件层解决)在各个组件绘制后,获取其包围盒信息,计算布局,然后设置 grid,二次绘制。 这个方案存在很多问题: 因为存在两次绘制,图表初始化会出现 2 次绘制结果的切换效果(待确认) 2024-08-13 ECharts #ECharts
需求的必要性业务前端的加入时机,不能不参与 如何低成本的确认可行性动画和3D的调试问题:Unity或者UE先做好。 做不确定的事情,效果停留在各自脑子里面,讨论再多也没用 做一个的时间,做2个 打一枪,换一炮 主题统一写在哪里?如何避免冲突拆分模块化 拿到元素先 /** 从 view 实例获取轴标签元素 */export function getAxisLabelEls(co 2024-08-12
ECharts扩展配置项-dvNameLocation 需求问题重现 Demo详见这个示例。 问题描述轴标题属于绝对定位,无法保证标题文本一定位于图表上方或下方 x 轴的轴标题在 x 轴右侧显示时,是跟随 x 轴轴线的,不是在图表右下角,0 轴情况会出现问题(dvNameLocation) 技术方案相关配置项:axis.nameLocation 生命周期:位于component:beforeupdate和component:afterupdate之间, 2024-08-12 ECharts #精 #ECharts
如何设计一个前端业务开发框架 目的提效 + 提质 1、不做重复的活儿 2、少做脏活儿、累活儿 3、相同的功能,随着时间越来越好(组件化 + 持续改进) 通用能力下沉,开发人员只需专注于上层业务的开发。 策略业务开发框架 + 通用组件库。 业务开发框架初期文件拷贝,后续加入 kingfisher 脚手架。 通用组件库独立项目,以 npm 包的形式发布,业务层通过 npm install 的方式引入使用。 非 UI 组件,和技术栈 2024-07-16 #TODO #前端工程化
开发笔记-Insight的文本与曲线布局 需求现有实现的源码阅读方案设计Insight 类型的,标签最多 3 个:最大、最小、异常值 如果是显示事件类的,数据量就可能很多,而且当前 F10 的事件没有权重的属性,无法根据权重排序筛选 流程Model:把用户的配置项转换成 echarts 配置项由于这次仍然是用的 dvMarker,因此 Model 不用修改,直接完全沿用之前的即可。 调用 flag 初始化图形元素模仿 flag 新增一个 2024-07-09 #开发笔记