reactive框架的内容主要包括: 倾听数据的set操作 收集数据的get操作,然后当数据set的时候重新触发 当数据set操作的时候,批量触发 倾听数据的set操作的语法糖 与react的集成 1 倾听set操作 代码在这里 1.1 observable 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676...
而实际情况是一个完整的表单中将会有更加复杂的字段定义,更多的表单字段和联动,那么按照这样的渲染模式来说,性能将必然是一个极大的问题。 而神奇的@formily/reactive则巧妙的通过getter获取组件运行过程中使用过哪些字段,从而完成动态的订阅和订阅释放,从而达到最小单元的订阅响应,这才使得整个表单在渲染过程中能够更加...
从该案例中,我们会发现 useAsyncDataSource 这个Effect Hook函数内,可以直接用@formily/reactive来定义状态,然后又能在onFieldReact中消费,也就是说,我们的Effect Hook完全做到了自包含,也就是说很多复杂的表单逻辑,我们可以基于Effect Hook以非常高内聚的方式去抽象,写法非常类似Vue3的setup,当然,这并不是故意模仿,...
Formily 是一个数据+协议驱动的表单解决方案,它站在Reactive响应式编程巨人的肩膀上,构建出了从基础表单到低代码领域的高性能通用基础能力,同时其配套的跨框架+跨终端组件生态体系,也能让用户更高效的开发日常业务表单,尽可能的减少了重复冗余的逻辑实现。本篇内容来自白玄在第十六届D2前端技术论坛的分享,将为你介绍...
关于精确渲染,我们已经确定可以选用类似 Mobx 的 Reactive 方案,虽然是重新造了一个轮子,但是,Reactive 这种模式始终还是很适合抽象响应式模型,所以基于 Reactive 的能力,Formily 经过不断试错与纠正,总算设计出了真正优雅的表单模型。这样的表单模型,解决的是表单领域问题,所以也称之为领域模型,有了这样的领域模型,我们...
所以,借助 Mobx ,完全可以解决表单字段输入过程中的 O(n) 问题,而且是可以很优雅的解决,但是 Formily2.x 在实现的过程中发现 Mobx 还是存在一些不兼容 Formily 核心思想的问题,最终,只能重新造了一个轮子,延续 Mobx 的核心思想的 @formily/reactive
"@formily/reactive"; import { s8 } from "@kinte-topology/core"; import { Button } from "antd"; import { useMemo, useState } from "react"; export const Test = observer(() => { const form = useMemo(() => createForm(), []); const...
123456789101112131415161718192021222324252627282930313233343536373839404142434445import{ArrayField,Field}from'@formily/core';import{ useField }from'@formily/react';import{ observer }from'@formily/reactive-react';importReact, {ReactNode, useContext }from'react';import{ReactElement}from'react';typePropsType=Field& ...
Formily2.0自信地表示它足够专业，并且在性能优化、依赖关系管理、包设计、答疑成本控制等方面进行了深入改进。关于性能优化，解决性能问题的关键在于减少初次渲染的阻塞式计算，通过引入Reactive模式并采用类似Mobx的解决方案，优化了性能，同时减少了props脏检查的副作用。此外，引入被动联动模式，借助@formily/...
所以,如果要真正实现精确渲染,非 Reactive 不可! 领域模型 前面问题中有提到表单的联动是非常复杂的,包含了字段间的各种关系,我们想象一下,大多数表单联动,基本上都是基于某些字段的值引发的联动,但是,实际业务需求可能会比较恶心,不仅要基于某些字段值引发联动,还会基于其他副作用值引发联动,比如应用...