이 기사는 프론트엔드 반응형 프로그래밍 솔루션과 그 단점(코드 포함)에 대해 자세히 소개합니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.
실제 세계의 많은 부분은 반응형 방식으로 작동합니다. 예를 들어, 우리는 다른 사람들로부터 질문을 받은 후 이에 대응하고 그에 상응하는 답변을 제공합니다. 개발 과정에서 저 역시 반응형 디자인을 많이 적용하고 경험을 쌓으며 다른 사람들에게 영감을 주고 싶었습니다.
리액티브 프로그래밍과 일반 프로그래밍 아이디어의 주요 차이점은 리액티브 프로그래밍은 푸시 방식으로 작동하는 반면, 비리액티브 프로그래밍은 풀 방식으로 작동한다는 것입니다. 예를 들어 이벤트는 매우 일반적인 반응형 프로그래밍입니다. 우리는 일반적으로 다음과 같이 합니다.
button.on('click', () => {
// ...})로그인 후 복사
비반응형 방식에서는 다음과 같이 됩니다.
while (true) {
if (button.clicked) { // ...
}
}로그인 후 복사
분명히 코드의 우아함과 실행 효율성 측면에서 모두 그렇습니다. , 비반응형 방법은 반응형 디자인만큼 좋지 않습니다.
Event Emitter는 대부분의 사람들에게 친숙한 이벤트 구현으로, 매우 간단하고 실용적입니다. Event Emitter를 사용하면 다음 비동기 검색과 같은 간단한 반응형 디자인을 구현할 수 있습니다. Event Emitter의 구현에는 많은 단점이 있으며, componentWillUnmount에서 리소스를 수동으로 해제해야 한다는 것을 알게 될 것입니다. 예를 들어 검색 시 여러 데이터 소스를 집계해야 하는 경우와 같이 표현 능력이 부족합니다.
class Input extends Component {
state = { value: ''
}
onChange = e => { this.props.events.emit('onChange', e.target.value)
}
afterChange = value => { this.setState({
value
})
}
componentDidMount() { this.props.events.on('onChange', this.afterChange)
}
componentWillUnmount() { this.props.events.off('onChange', this.afterChange)
}
render() {
const { value } = this.state
return ( <input value={value} onChange={this.onChange} />
)
}
}
class Search extends Component {
doSearch = (value) => {
ajax(/* ... */).then(list => this.setState({
list
}))
}
componentDidMount() {
this.props.events.on('onChange', this.doSearch)
}
componentWillUnmount() {
this.props.events.off('onChange', this.doSearch)
}
render() {
const { list } = this.state
return ( <ul>
{list.map(item => <li key={item.id}>{item.value}</li>)} </ul>
)
}
}로그인 후 복사
분명히 개발 효율성이 매우 낮습니다.
Redux
Redux에서는 이벤트 스트림을 사용하여 응답성을 구현합니다. Redux에서는 리듀서가 순수 함수여야 하므로 응답성을 구현하는 유일한 방법은 구독이나 미들웨어를 통해서입니다.
스토어에 가입하시면 Redux에서는 어떤 데이터가 변경되었는지 정확하게 알 수 없기 때문에 더티 체크만 가능합니다. 예:
class Search extends Component {
foo = ''
bar = ''
doSearch = () => {
ajax({
foo,
bar
}).then(list => this.setState({
list
}))
}
fooChange = value => { this.foo = value this.doSearch()
}
barChange = value => { this.bar = value this.doSearch()
}
componentDidMount() { this.props.events.on('fooChange', this.fooChange) this.props.events.on('barChange', this.barChange)
}
componentWillUnmount() { this.props.events.off('fooChange', this.fooChange) this.props.events.off('barChange', this.barChange)
}
render() { // ...
}
}로그인 후 복사
watcher(store)
이 방법에는 두 가지 단점이 있습니다. 하나는 데이터가 복잡하고 데이터 양이 상대적으로 많을 때 효율성 문제가 있다는 것입니다. 문맥 상으로는 매우 어려울 것입니다. React-redux에서 connect 함수에 있는 mapStateToProps의 두 번째 매개변수는 props입니다. Props는 필요한 컨텍스트를 얻기 위해 상위 구성요소를 통해 전달될 수 있지만, 이렇게 하면 리스너가 React 구성요소가 되어 구성요소가 마운트될 때 마운트됩니다. 그리고 언로딩이 생성되고 소멸되도록 하려면 문제가 발생합니다.
또 다른 방법은 미들웨어의 데이터 변경을 모니터링하는 것입니다. Redux의 설계 덕분에 특정 이벤트(Action)를 수신하여 해당 데이터 변경 사항을 얻을 수 있습니다.
function createWatcher(mapState, callback) {
let previousValue = null
return (store) => {
store.subscribe(() => { const value = mapState(store.getState()) if (value !== previousValue) {
callback(value)
}
previousValue = value
})
}
}const watcher = createWatcher(state => {
// ...}, () => { // ...})로그인 후 복사
이 방법은 대부분의 문제를 해결할 수 있지만 Redux에서는 미들웨어와 리듀서가 실제로 모든 이벤트(Action)를 암시적으로 구독합니다. 이는 성능 문제가 전혀 없음에도 불구하고 분명히 불합리합니다.
객체 지향 응답성
ECMASCRIPT 5.1에는 getter와 setter가 도입되었으며, getter와 setter를 통해 응답성을 구현할 수 있습니다.
const search = () => (dispatch, getState) => {
// ...}const middleware = ({ dispatch }) => next => action => {
switch action.type { case 'FOO_CHANGE': case 'BAR_CHANGE': { const nextState = next(action) // 在本次dispatch完成以后再去进行新的dispatch
setTimeout(() => dispatch(search()), 0) return nextState
} default: return next(action)
}
}로그인 후 복사
여러 값에 응답한 후 새 값을 가져와야 하는 경우 Mobx에서 이 작업을 수행할 수 있습니다.
class Model {
_foo = ''
get foo() { return this._foo
}
set foo(value) { this._foo = value this.search()
}
search() { // ...
}
}// 当然如果没有getter和setter的话也可以通过这种方式实现class Model {
foo = ''
getFoo() { return this.foo
}
setFoo(value) { this.foo = value this.search()
}
search() { // ...
}
}로그인 후 복사
Mobx는 런타임 시 시간에 따른 값을 수집하고 이러한 값이 변경될 때 (트리거 설정기) 시간 값을 다시 계산하는 것은 분명히 EventEmitter의 접근 방식보다 훨씬 편리하고 효율적이며 Redux의 미들웨어보다 더 직관적입니다.
하지만 여기에도 단점이 있습니다. getter를 기반으로 계산된 속성은 y = f(x)의 상황만 설명할 수 있습니다. 그러나 실제로는 f가 비동기 함수이므로 y = wait가 됩니다. f(x). 이 상황은 getter로 설명할 수 없습니다.
이 상황에서는 Mobx에서 제공하는 자동 실행을 통해 구현할 수 있습니다.
class Model {
@observable hour = '00'
@observable minute = '00'
@computed get time() { return `${this.hour}:${this.minute}`
}
}로그인 후 복사
런타임 종속성 수집 프로세스가 완전히 암시적이므로 여기서 자주 발생하는 문제는 예상치 못한 종속성의 수집입니다.
class Model {
@observable keyword = ''
@observable searchResult = [] constructor() {
autorun(() => { // ajax ...
})
}
}로그인 후 복사
분명히 여기서 로딩하면 안 됩니다. 이 문제를 해결하기 위해 몇 가지 추가 코드가 추가되며, 추가 코드로 인해 쉽게 오류가 발생할 수 있습니다.
또는 필수 필드를 수동으로 지정할 수도 있지만 이 방법에는 몇 가지 추가 작업이 필요합니다:
class Model {
@observable loading = false
@observable keyword = ''
@observable searchResult = [] constructor() {
autorun(() => { if (this.loading) { return
} // ajax ...
})
}
}로그인 후 복사
그리고 타임라인을 설명해야 할 때 Mobx는 다소 그렇게 할 수 없습니다. 5 몇 초 안에 다시 검색하세요.
관련 권장사항:
반응형 백엔드의 반응형 프런트엔드 프레임워크 버전 공식 출시_html/css_WEB-ITnose
매우 간단한 반응형 프런트엔드 개발 프레임워크 사용_html/css_WEB-ITnose
위 내용은 프런트엔드 반응형 프로그래밍 솔루션과 그 단점에 대한 자세한 소개(코드 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
