是的,这正是我所提倡的。
假设你现在需要实现一个掷硬币的功能,当组件渲染时模拟一次掷硬币!一半的时间组件应该渲染 “正面”,一半的时间应该渲染 “反面”。你对你的产品经理说 “这需要多年的研究!” 然后你继续工作。
const CoinFlip = () =>
Math.random() < 0.5 ? <div>Heads</div> : <div>Tails</div>;
事实证明,模仿掷硬币比你想象的要容易得多,所以你可以自豪地分享成果。你得到了回复,“这真的是太棒了!请更新那些显示很酷的硬币的图片好么?” 没问题!
const CoinFlip = () =>
Math.random() < 0.5 ? (
<div>
<img src=”/heads.svg” alt=”Heads” />
</div>
) : (
<div>
<img src=”/tails.svg” alt=”Tails” />
</div>
);
很快,他们会在营销材料中使用你的 <CoinFlip /> 组件,来向人们演示你的新功能有多么炫酷。“我们想在博客上发表文章,但是我们需要标签 'Heads' 和 'Tails',用于 seo 和其他事情。” 哦,天啊,或许我们需要在商城网站中添加一个标志?
const CoinFlip = (
// We’ll default to false to avoid breaking the applications
// current usage.
{ showLabels = false }
) =>
Math.random() < 0.5 ? (
<div>
<img src=”/heads.svg” alt=”Heads” />
{/* Add these labels for the marketing site. */}
{showLabels && <span>Heads</span>}
</div>
) : (
<div>
<img src=”/tails.svg” alt=”Tails” />
{/* Add these labels for the marketing site. */}
{showLabels && <span>Tails</span>}
</div>
);
后来,出现了一个需求。“我们想知道你能否只给 APP 里的 <CoinFlip /> 添加一个重掷硬币的按钮?” 事情开始变得糟糕,以致于我不敢再直视 Kent C. Dodds 的眼睛。
const flip = () => ({
flipResults: Math.random()
});
class CoinFlip extends react.Component {
static defaultProps = {
showLabels: false,
// We don’t repurpose `showLabels`, we aren’t animals, after all.
showButton: false
};
state = flip();
handleClick = () => {
this.setState(flip);
};
render() {
return (
// Use fragments so people take me seriously.
<>
{this.state.showButton && (
<button onClick={this.handleClick}>Reflip</button>
)}
{this.state.flipResults < 0.5 ? (
<div>
<img src=”/heads.svg” alt=”Heads” />
{showLabels && <span>Heads</span>}
</div>
) : (
<div>
<img src=”/tails.svg” alt=”Tails” />
{showLabels && <span>Tails</span>}
</div>
)}
</>
);
}
}
很快就有同事找到你。“嗨,你的 <CoinFlip /> 性能太棒了!我们刚接到任务要开发新的 <DiceRoll /> 特性,我们希望可以重用你的代码!” 新骰子的功能:
你现在有两个选项,回复 “对不起,我们不一样。” 或着你一边向 CoinFlip 中添加 DiceRoll 的复杂功能,一边看着组件无法承受过多职责而崩溃。(是否有一个给忧郁的程序员诗人的市场?我喜欢追求这种技术。)
无头用户界面组件将组件的逻辑和行为与其视觉表现分离。当组件的逻辑足够复杂并与它的视觉表现解耦时,这种模式非常有效。实现 <CoinFlip/> 的无头将作为函数子组件或渲染属性,就像这样:
const flip = () => ({
flipResults: Math.random()
});
class CoinFlip extends React.Component {
state = flip();
handleClick = () => {
this.setState(flip);
};
render() {
return this.props.children({
rerun: this.handleClick,
isHeads: this.state.flipResults < 0.5
});
}
}
这个组件是无头的,因为它没有渲染任何东西,它期望当它在处理逻辑的时,各种 consumers 完成视觉表现。因此 APP 代码看起来应该是这样的:
<CoinFlip>
{({ rerun, isHeads }) => (
<>
<button onClick={rerun}>Reflip</button>
{isHeads ? (
<div>
<img src=”/heads.svg” alt=”Heads” />
</div>
) : (
<div>
<img src=”/tails.svg” alt=”Tails” />
</div>
)}
</>
)}
</CoinFlip>
商场站点代码:
<CoinFlip>
{({ isHeads }) => (
<>
{isHeads ? (
<div>
<img src=”/heads.svg” alt=”Heads” />
<span>Heads</span>
</div>
) : (
<div>
<img src=”/tails.svg” alt=”Tails” />
<span>Tails</span>
</div>
)}
</>
)}
</CoinFlip>
这很好不是么!我们把逻辑与视觉表现完全解耦!这给我们视觉上带来了很大的灵活性!我知道你正在思考什么......
你这小笨蛋,这不就是一个渲染属性么?
这个无头组件恰好是作为渲染工具实现的,是的!它也可以作为一个高阶组件来实现。即使是简单的实现,也可以到达我们的要求。它甚至可以作为 View 和 Controller 来实现。或者是 ViewModel 和 View。这里的重点是将翻转硬币的机制和该机制的 “界面” 分离。
这种分离的巧妙之处在于,推广我们的无头组件以及支持我们同事的新的 <DiceRoll /> 的特性会很容易。拿着我的 Diet Coke™:
const run = () => ({
random: Math.random()
});
class Probability extends React.Component {
state = run();
handleClick = () => {
this.setState(run);
};
render() {
return this.props.children({
rerun: this.handleClick,
// By taking in a threshold property we can support
// different odds!
result: this.state.random < this.props.threshold
});
}
}
利用这个无头组件,我们在没有对 consumer 进行任何更改对情况下,交换
const CoinFlip = ({ children }) => (
<Probability threshold={0.5}>
{({ rerun, result }) =>
children({
isHeads: result,
rerun
})}
</Probability>
);
现在我们的同事可以分享我们的 <Probability /> 模拟程序机制了!
const RollDice = ({ children }) => (
// Six Sided Dice
<Probability threshold={1 / 6}>
{({ rerun, result }) => (
<div>
{/* She was able to use a different event! */}
<span onMouseOver={rerun}>Roll the dice!</span>
{/* Totally different interface! */}
{result ? (
<div>Big winner!</div>
) : (
<div>You win some, you lose most.</div>
)}
</div>
)}
</Probability>
);
非常干净,不是么?
这表达了一个存在很长时间对普遍基本原则,“Unix 基础哲学第四条”:
分离原则:将策略与机制分离,将接口和引擎分离 —— Eric S. Raymond。
我想借用书中的部分,并且用 “接口” 来替换 “策略” 一词。
接口和机制都倾向于在不同时间范围内变化,但接口的变化比机制要快得多。GUI 工具包那时尚的外观和体验会变,但是操作和组合却不会。因此,将接口和机制结合在一起有两个不好的影响:它使得接口变的生硬,更难响应用户的需求,这意味着试图更改接口具有很强的不稳定性。
另一方面,通过将这两者分开,我们可以在没有中断机制的情况下试验新的接口。我们还可以更容易地为该机制编写好的测试(接口,因为它们太新了,难以证明这样的投资是合理的)。
我喜欢这里的真知灼见!这也让我们对何时使用无头组件模式有了一些了解。
当你将 “机制” 和 “策略” 分离时,就会产生间接的成本。你需要确保分离的价值大于它的间接成本。我认为这在很大程度上是过去许多 MV* 模式出问题的地方,它们从这样一个公理开始,即所有的东西都应该以这种方式分开;而在现实中,机制和策略往往是紧密耦合的,或分离的成本并没有超过分离的好处。
要获取一个真正的示例性非平凡无头组件,可以了解一下我朋友 Kent C. Dodds 在 Paypal 上的项目:downshift 的文章。事实上,正是 downshift 给了这篇文章一些灵感。在不提供任何用户界面的情况下,downshift 提供了复杂的自动完成、下拉、选择体验,这些体验都是可以访问的。在这里看看它所有可用的方法。
我希望随着时间的推移,会出现更多类似的项目。我无法计算有多少次我想使用一个特定的开源 UI 组件,但却无法这样做,因为在满足设计要求的方式上,它并不是 “主题化的” 或 “可剥离的”。无头组件完全通过 “自带接口” 的要求来解决这个问题。
在一个设计系统和用户界面库都是无头的世界里,你的界面可以有一种高端定制的感觉,以及优秀开源库的持久性和可访问性。你仅需要将时间花费在你所需要的部分 —— 一个独特的,外观及体验都只属于你 APP 的部分。
我可以继续讨论从国际化到 E2E 测试集成的好处,但我建议你最好自己去体验。
译者:@Starrier,译文:https://github.com/xitu/gold-miner/blob/master/TODO1/headless-user-interface-components.md
作者:@Merrick Christensen,原文:https://medium.com/merrickchristensen/headless-user-interface-components-565b0c0f2e18
Vuetify 支持SSR(服务端渲染),SPA(单页应用程序),PWA(渐进式Web应用程序)和标准HTML页面。 Vuetify是一个渐进式的框架,试图推动前端开发发展到一个新的水平。
通过给组件传递参数, 可以让组件变得更加可扩展, 组件内使用props接收参数,slot的使用就像它的名字一样, 在组件内定义一块空间。在组件外, 我们可以往插槽里填入任何元素。slot-scope的作用就是把组件内的数据带出来
函数子组件(FaCC )与高阶组件做的事情很相似, 都是对原来的组件进行了加强,类似装饰者。FaCC,利用了react中children可以是任何元素,包括函数的特性,那么到底是如何进行增强呢?
在现代的三大框架中,其中两个Vue和React框架,组件间传值方式有哪些?组件间的传值是灵活的,可以有多种途径,父子组件同样可以使用EventBus,Vuex或者Redux
自定义指令:以v开头,如:v-mybind。bind的作用是定义一个在绑定时执行一次的初始化动作,观察bind函数,它将指令绑定的DOM作为一个参数,在函数体中,直接操作DOM节点为input赋值。
prop的定义:在没有状态管理机制的时候,prop属性是组件之间主要的通信方式,prop属性其实是一个对象,在这个对象里可以定义一些数据,而这些数据可以通过父组件传递给子组件。 prop属性中可以定义属性的类型,也可以定义属性的初始值。
Web组件由三个独立的技术组成:自定义元素。很简单,这些是完全有效的HTML元素,包含使用一组JavaScript API制作的自定义模板,行为和标记名称(例如,<one-dialog>)。
web组件可以直接或间接的调用其他web资源。一个web组件通过内嵌返回客户端内容的另一个web资源的url来间接调用其他web资源。在执行时,一个web资源通过包含另一个资源的内容或者转发请求到另一个资源直接调用。
在实际开发项目中,有时我们会用到自定义按钮;因为一个项目中,众多的页面,为了统一风格,我们会重复用到很多相同或相似的按钮,这时候,自定义按钮组件就派上了大用场,我们把定义好的按钮组件导出,在全局引用,就可以在其他组件随意使用啦,这样可以大幅度的提高我们的工作效率。
Vue中子组件调用父组件的方法,这里有三种方法提供参考,第一种方法是直接在子组件中通过this.$parent.event来调用父组件的方法,第二种方法是在子组件里用$emit向父组件触发一个事件,父组件监听这个事件就行了。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!