프런트엔드 반응형 프로그래밍 솔루션과 그 단점에 대한 자세한 소개(코드 포함)
- 不言원래의
- 2018-08-14 15:14:452504검색
이 기사는 프론트엔드 반응형 프로그래밍 솔루션과 그 단점(코드 포함)에 대해 자세히 소개합니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.
실제 세계의 많은 부분은 반응형 방식으로 작동합니다. 예를 들어, 우리는 다른 사람들로부터 질문을 받은 후 이에 대응하고 그에 상응하는 답변을 제공합니다. 개발 과정에서 저 역시 반응형 디자인을 많이 적용하고 경험을 쌓으며 다른 사람들에게 영감을 주고 싶었습니다.
리액티브 프로그래밍과 일반 프로그래밍 아이디어의 주요 차이점은 리액티브 프로그래밍은 푸시 방식으로 작동하는 반면, 비리액티브 프로그래밍은 풀 방식으로 작동한다는 것입니다. 예를 들어 이벤트는 매우 일반적인 반응형 프로그래밍입니다. 우리는 일반적으로 다음과 같이 합니다.
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와 Vue는 이 방법을 사용하여 응답성을 구현합니다. 물론 호환성을 고려하지 않는 경우 프록시를 사용할 수도 있습니다. 여러 값에 응답한 후 새 값을 가져와야 하는 경우 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!