How are 'pop-ups' developed? State-driven or imperative?

This article brings you relevant knowledge about front-end development pop-up windows. It mainly introduces how front-end development engineers can quickly and efficiently develop pop-up windows. For those who are interested, let’s take a look below. I hope it will be useful to everyone. helpful.

As a front-end development engineer, developing various pop-up windows is commonplace, but how to do it quickly, efficiently and with a unified style is a problem.

State driven

In today's front-end technology stacks are Vue, React, using state driven is a common way. For example, if we want to introduce a pop-up window to our page, click a button to pop up:

<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
		}
	}
}

There is a problem with the above. The variables that control the display and hiding of the pop-up window, the logic for displaying the pop-up window, and the callback logic for closing the pop-up window are scattered in different places. The place.

Assuming that this page has more than one pop-up window, then write it like this:

<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
		},
	}
}

It is not too verbose to write like this.

Imperative Development (Functional)

I developed promise-modal This library can be used to develop Promise functional pop-ups in React projects.

Installation

npm i promise-modal

Use

your Modal component to write like this, we will pass in the two props callbackResolve and callbackReject In your component, you need to call them when closing the Modal.

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

Pass your Modal component into the create function

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
}

Use Modal in business code, just like the Promise function.

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

Of course, there has always been controversy between imperative and state-driven development:

This is You Yuxi’s point of view, supporting state-driven development:

www.zhihu.com/question/35…

There are also some netizens who support imperative style:

www.zhihu.com/question /35…

Intercepted fragments:

For the user, he only needs to focus on what he wants to show and the rules to show, without additional Pay attention to irrelevant logic such as showing and hiding the pop-up window - the call itself is to be displayed.

Changed to an imperative call, the user does not need to introduce components, mount components, declare callbacks, interrupt the logic flow, and can only focus on their own data.

My opinion

• When the state drives multiple pop-up components, the code is too redundant.
• For large teams, front-line business developers have different levels of levels, different code styles, decentralized state drivers, and everyone has different styles such as variable naming. The styles cannot be unified, resulting in messy code. Unable to maintain.
• Promise functional style means that users of pop-up windows do not need to care about logic such as display and hiding. The principle of proximity is that only when the business reaches this point and the pop-up window should appear, the corresponding pop-up window function is called.
• Of course, this method increases the work of pop-up window developers, but reduces the mental burden of pop-up window users.
• This library implicitly passes in two props, callbackResolve and callbackReject. The dependency source is unclear, which brings new mental burden. I don’t have a good idea for the moment, so PR is welcome.

Finally

When developing pop-up windows, would you rather use state-driven or imperative methods? Is imperative suitable for your team or project? Give it a try.

GitHub address

npm address

Related tutorials: "Web front-end development video tutorial"

The above is the detailed content of How are 'pop-ups' developed? State-driven or imperative?. For more information, please follow other related articles on the PHP Chinese website!