Comment sont développés les « pop-ups » ? Impulsé par l'État ou impératif ?

Cet article vous apporte des connaissances pertinentes sur les fenêtres contextuelles de développement front-end. Il présente principalement comment les ingénieurs de développement front-end peuvent développer rapidement et efficacement des fenêtres pop-up. Pour ceux qui sont intéressés, jetons un coup d'œil ci-dessous. cela vous sera utile.

En tant qu'ingénieur de développement front-end, développer diverses fenêtres pop-up est monnaie courante, mais comment le faire rapidement, efficacement et avec un style unifié est un problème.

Piloté par l'état

Dans les piles technologiques frontales d'aujourd'hui se trouvent Vue, React, l'utilisation pilotée par l'état est une méthode courante. Par exemple, si nous voulons introduire une fenêtre pop-up sur notre page, cliquez sur un bouton pour apparaître : Vue、 React 的情况下，使用状态驱动是一种常用方式。比如我们页面要引入一个弹窗，点击某个按钮弹出：

<template>
	<div>
		<Modal1 v-show="visible" @close="closeModal" />
		<button @click="showModal" >click</button>
	</div>
</template>

<script>
import Modal1 from &#39;./modals/Modal1.vue&#39;
export default {
	components: { Modal1 },
	data() {
		return {
			visible: false
		}
	},
	methods: {
		// 弹出弹窗
		showModal(){
			this.visible = true
		},
		// 关闭弹窗，并传回数据
		closeModal(data) {
			this.visible = false
			// 拿到 data  todo something
		}
	}
}

以上有一个问题，控制弹窗显隐的变量、显示弹窗的逻辑、关闭弹窗的回调逻辑分散在不同的地方。

假设这个页面有不止一个弹窗，那么这样写：

<template>
	<div>
		<Modal1 v-show="visible1" @close="closeModal1" />
		<Modal2 v-show="visible2" @close="closeModal2" />
		<Modal3 v-show="visible3" @close="closeModal3" />
		<button @click="showModal1" >click</button>
		<button @click="showModal2" >click</button>
		<button @click="showModal3" >click</button>
	</div>
</template>

<script>
import Modal1 from &#39;./modals/Modal1.vue&#39;
import Modal2 from &#39;./modals/Modal2.vue&#39;
import Modal3 from &#39;./modals/Modal3.vue&#39;

export default {
	components: { Modal1, Modal2, Modal3 },
	data() {
		return {
			visible1: false,
			visible2: false,
			visible3: false,
		}
	},
	methods: {
		// 弹出弹窗
		showModal1(){
			this.visible1 = true
		},
		// 关闭弹窗，并传回数据
		closeModal1(data) {
			this.visible1 = false
			// 拿到 data  todo something
		},
		showModal2(){
			this.visible2 = true
		},
		// 关闭弹窗，并传回数据
		closeModal2(data) {
			this.visible2 = false
			// 拿到 data  todo something
		},
		showModal3(){
			this.visible3 = true
		},
		// 关闭弹窗，并传回数据
		closeModal3(data) {
			this.visible3 = false
			// 拿到 data  todo something
		},
	}
}

这样写起来简直不要太啰嗦。

命令式开发（函数式）

我开发了 promise-modal 这个库，可以在 React 项目中 Promise 函数式的开发调用弹窗。

安装

npm i promise-modal

使用

你的 Modal 组件这样写，我们会传入 callbackResolve和 callbackReject

import React, { useState } from 'react'
import { Modal, Button } from 'antd'
import PropTypes from 'prop-types'

const TestModal = (props) => {
  const { title, callbackResolve, callbackReject } = props
  const [isModalVisible, setIsModalVisible] = useState(true)

  const handleOk = () => {
    setIsModalVisible(false)
    callbackResolve(true)
  }

  const handleCancel = () => {
    setIsModalVisible(false)
    callbackReject(false)
  }

  return (
    <Modal destroyOnClose title={title} visible={isModalVisible} onOk={handleOk} onCancel={handleCancel}>
      <p>Some contents...</p>
      <p>Some contents...</p>
    </Modal>
  )
}

TestModal.propTypes = {
  title: PropTypes.string.isRequired,
  callbackResolve: PropTypes.func.isRequired,
  callbackReject: PropTypes.func.isRequired,
}
export default TestModal

Il y a un problème avec ce qui précède. Les variables qui contrôlent l'affichage et le masquage de la fenêtre pop-up, la logique d'affichage de la fenêtre pop-up et la logique de rappel pour fermer la fenêtre pop-up sont dispersées à différents endroits.

Supposons que cette page ait plus d'une fenêtre pop-up, alors écrivez-la comme ceci :

import { create } from 'promise-modal'
import TestModal from './TestModal'

// 如果你使用 Class 组件
export default (data) => create(TestModal, data)

// 如果你使用函数式组件和 hooks，你必须创建一个自定义 hooks 返回
export const useTestModal = () => {
  const showTestModal = (data) => create(TestModal, data)
  return showTestModal
}

Ce n'est pas trop verbeux d'écrire comme ça.

Développement impératif (fonctionnel)

J'ai développé promise-modal Cette bibliothèque peut rendre Promise fonctionnelle dans les projets React Développer la pop-up d'appel fenêtre.

Installer

import { useTestModal } from './modals/TestModal'

const showTestModal = useTestModal()

// use Promise.then
showTestModal({
  title: 'Test Modal',
})
  .then((response) => {
    console.log('response: ', response)
  })
  .catch((error) => {
    console.log('error: ', error)
  })

// use await
const res = await showTestModal({
  title: 'Test Modal',
})
console.log('res: ', res)
// do something here

Utiliser

🎜Écrivez votre composant Modal comme ceci, nous le transmettrons callbackResolve et callbackReject deux accessoires de votre composant, vous devez les appeler lors de la fermeture du Modal. 🎜rrreee🎜Passez votre composant Modal dans la fonction de création🎜rrreee🎜Utilisez Modal dans le code métier, tout comme la fonction Promise. 🎜rrreee🎜Bien sûr, le développement impératif ou dirigé par l'État a toujours été controversé : 🎜🎜C'est le point de vue de You Yuxi, soutenant le développement dirigé par l'État : 🎜

www.zhihu.com/question/35…

Il y a aussi des internautes qui soutiennent le style impératif :

www.zhihu.com/question/35…

Extraits interceptés :

Pour les utilisateurs qui Autrement dit, il n'a besoin que de se concentrer sur ce qu'il veut afficher et sur les règles d'affichage, et n'a pas besoin de prêter une attention particulière à une logique non pertinente telle que l'affichage ou le masquage de la fenêtre contextuelle - l'appel lui-même doit être affiché.

En le changeant en appel impératif, les utilisateurs n'ont pas besoin d'introduire des composants, de monter des composants, de déclarer des rappels et d'interrompre le flux logique. Ils peuvent uniquement se concentrer sur leurs propres données.

Mon avis

• Lorsque l'État pilote plusieurs composants pop-up, le code est trop redondant.
• Pour les grandes équipes, les développeurs commerciaux de première ligne ont différents niveaux de hiérarchie, différents styles de code, des pilotes d'état décentralisés, et chacun a des styles différents tels que la dénomination des variables. Les styles ne peuvent pas être unifiés, ce qui entraîne un code désordonné qui ne peut pas être maintenu.
• Le style fonctionnel promis signifie que les utilisateurs de fenêtres contextuelles n'ont pas à se soucier de la logique telle que l'affichage et le masquage. Le principe de proximité signifie que ce n'est que lorsque l'entreprise atteint ce point et que la fenêtre contextuelle doit apparaître que la fenêtre contextuelle correspondante apparaît. la fonction de fenêtre contextuelle est appelée.
• Bien sûr, cette méthode augmente le travail des développeurs de fenêtres pop-up, mais réduit la charge mentale des utilisateurs de fenêtres pop-up.
• Cette bibliothèque transmet implicitement callbackResolve和 callbackRejectdeux accessoires, et la source de la dépendance n'est pas claire, ce qui entraîne une nouvelle charge mentale. Je n’ai pas de bonne idée pour le moment, donc les relations publiques sont les bienvenues.

Enfin

Lors du développement de fenêtres pop-up, préférez-vous utiliser des méthodes pilotées par l'état ou impératives ? L'impératif convient-il à votre équipe ou à votre projet ? Essayez-le.

Adresse GitHub

Adresse npm

Tutoriels associés : "Tutoriel vidéo sur le développement front-end Web"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!