Контроль. Эта концепция имеет решающее значение в программировании. Например, «гонка» за контроль между уровнем инкапсуляции «колесо» и уровнем бизнес-потребителей — очень интересная тема. Это не исключение в мире React. На первый взгляд, мы, конечно же, хотим, чтобы «колеса» контролировали как можно больше вещей:Потому что чем больше логики обрабатывает уровень абстракции, тем меньше вещей, о которых вы заботитесь при вызове бизнеса, и тем удобнее его использовать. Однако некоторые конструкции «не решаются сделать шаг вперед». Очень интересно перетягивание каната между «колесами» и управлением бизнесом.
В то же время возможность управления также тесно связана с конструкцией компонентов: вызывает восхищение дизайн атомарных компонентов, таких как атомарные компоненты; помимо концепции атомарных компонентов существуют молекулярные компоненты: молекулярные компоненты. Будь то молекулы или атомы, они существуют, когда дело доходит до решения бизнес-задач.
В этой статье будет использоваться фреймворк React в качестве фона, чтобы рассказать о некоторых моих мыслях и выводах об управлении во время разработки. Если вы не используете React, это все равно не помеха чтению в принципе.
До начала статьи я хотел бы рассказать вам о книге.
С прошлого года я работаю с известными технологическими гигантамиЯн ХайцзинНачался соавторский тур, в этом году мы совместно шлифовали книги ** "React state management and isomorphic real" ** наконец-то официально изданные! В этой книге за основу взят стек технологий React.На основе введения в использование React анализируется идея Redux с уровня исходного кода, и в то же время основное внимание уделяется архитектурному шаблону рендеринга на стороне сервера. и изоморфные приложения. Книга содержит множество примеров проектов, которые не только открывают для пользователей дверь в стек технологий React, но и улучшают общее понимание читателем пограничных областей.
Если вы заинтересованы в содержании книги или следующего содержания, пожалуйста, поддержите нас!Подробности в конце статьи, не уходите!
<form>
<label>
Name:
<input type="text" name="name" />
</label>
<input type="submit" value="Submit" />
</form>
class NameForm extends React.Component {
state= {value: ''}
handleChange = event => {
this.setState({value: event.target.value});
}
handleSubmit = event => {
alert('A name was submitted: ' + this.state.value);
event.preventDefault();
}
render() {
return (
<form onSubmit={this.handleSubmit}>
<label>
Name:
<input type="text" value={this.state.value} onChange={this.handleChange} />
</label>
<input type="submit" value="Submit" />
</form>
)
}
}
В настоящее время значения и поведение формы контролируются компонентами React, что делает разработку более удобной.
Это, конечно, очень базовая концепция, поэтому читателю предлагается продолжить чтение.
Пользовательский интерфейс «Колеса» и режим управления реквизитами
Пример, который я представил ранее, я называю его "узкий смыслКонтролируемые и неконтролируемые».Вообще говоря, я думаю, что полностью неуправляемые компоненты — это: функциональные компоненты или компоненты без состояния, которые не имеют внутренних состояний и принимают только свойства.. Его поведение при рендеринге полностью контролируется реквизитами, переданными извне, и не имеет собственной «автономии». Такие компоненты хорошо подходят для повторного использования и имеют хорошую тестируемость.
Но в дизайне «колеса» пользовательского интерфейса «полуавтономные» или «неполностью контролируемые» компоненты иногда являются лучшим выбором. Мы называем это паттерном «контрольные реквизиты». Проще говоря:Компонент имеет свое собственное состояние.Когда никакие связанные порты не передаются, он использует свое собственное состояние statea для завершения логики рендеринга и взаимодействия; когда компонент вызывается, если передаются связанные реквизиты, он передает управление и контролируется по уровню потребления бизнеса его поведение.
Изучив множество «колес» пользовательского интерфейса сообщества, я нашел библиотеку компонентов, написанную Кентом С. Доддсом для использования в PayPal.downshiftЭто будет широко принято такую модель.
Просто возьмите компонент Toogle в качестве примера, когда этот компонент вызывается бизнес-стороной:
class Example extends React.Component {
state = {on: false, inputValue: 'off'}
handleToggle = on => {
this.setState({on, inputValue: on ? 'on' : 'off'})
}
handleChange = ({target: {value}}) => {
if (value === 'on') {
this.setState({on: true})
} else if (value === 'off') {
this.setState({on: false})
}
this.setState({inputValue: value})
}
render() {
const {on} = this.state
return (
<div>
<input
value={this.state.inputValue}
onChange={this.handleChange}
/>
<Toggle on={on} onToggle={this.handleToggle} />
</div>
)
}
}
Эффект показан на рисунке:
Мы можем управлять переключением состояния компонента Toggle через поле ввода (введите «включено», чтобы активировать состояние, введите «выключено», чтобы сделать его серым), и мы также можем щелкнуть мышью для переключения, а содержимое поле ввода изменится соответственно.
Подумайте об этом: для компонента пользовательского интерфейса Toggle его состояние может контролироваться бизнес-вызовом, что обеспечивает удобство использования на уровне использования. В бизнес-коде, будь то Input или любой другой компонент, может управлять своим состоянием, у нас есть полный контроль над вызовом.
同时，如果在调用 Toggle 组件时，不去传 props 值，该组件仍然可以正常发挥。 следующим образом:
<Toggle>
{({on, getTogglerProps}) => (
<div>
<button {...getTogglerProps()}>Toggle me</button>
<div>{on ? 'Toggled On' : 'Toggled Off'}</div>
</div>
)}
</Toggle>
const callAll = (...fns) => (...args) => fns.forEach(fn => fn && fn(...args))
class Toggle extends Component {
static defaultProps = {
defaultOn: false,
onToggle: () => {},
}
state = {
on: this.getOn({on: this.props.defaultOn}),
}
getOn(state = this.state) {
return this.isOnControlled() ? this.props.on : state.on
}
isOnControlled() {
return this.props.on !== undefined
}
getTogglerStateAndHelpers() {
return {
on: this.getOn(),
setOn: this.setOn,
setOff: this.setOff,
toggle: this.toggle,
}
}
setOnState = (state = !this.getOn()) => {
if (this.isOnControlled()) {
this.props.onToggle(state, this.getTogglerStateAndHelpers())
} else {
this.setState({on: state}, () => {
this.props.onToggle(
this.getOn(),
this.getTogglerStateAndHelpers()
)
})
}
}
setOn = this.setOnState.bind(this, true)
setOff = this.setOnState.bind(this, false)
toggle = this.setOnState.bind(this, undefined)
render() {
const renderProp = unwrapArray(this.props.children)
return renderProp(this.getTogglerStateAndHelpers())
}
}
function unwrapArray(arg) {
return Array.isArray(arg) ? arg[0] : arg
}
export default Toggle
Используйте режим поддержки рендеринга, в этой статье не будет обсуждаться этот шаблон, заинтересованные читатели могут найти много информации в сообществе, но также могут найти соответствующий контент в моей новой книге.
Подводя итоги, шаблон управляющих реквизитов отражает типичные проблемы управления. Такие «полуавтономные» могут отлично адаптироваться к потребностям бизнеса и быть более гибкими и эффективными при проектировании компонентов.
Redux управление асинхронным состоянием и контроль
Когда дело доходит до темы контроля, как может быть такой инструмент управления состоянием, как Redux.Дизайн Redux отражает хорошую управляемость во всех аспектах., здесь мы сосредоточимся наАсинхронное состояниеДля большего содержания, пожалуйста, обратите внимание на мою новую книгу.
Redux обрабатывает асинхронность, и наиболее известным из них является промежуточное ПО, такое как Redux-thunk, которое было написано самим Дэном и использовалось в официальной документации Redux.Как и все другое промежуточное программное обеспечение, оно управляет процессом от действия до редюсера, так что действие функционального типа может быть отправлено непосредственно в бизнес-использовании., код реализации тоже очень прост:
function createThunkMiddleware(extraArgument) {
return ({ dispatch, getState }) => next => action => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument);
}
return next(action);
};
}
const thunk = createThunkMiddleware();
export default thunk;
Однако вскоре некоторые люди посчитали, что такая схема приводит к недостаточности бизнес-кода из-за недостаточного контроля при реализации промежуточного программного обеспечения. Нам все еще нужно следовать традиционным шагам Redux: писать действия, создатели действий, редукторы... Итак,Решения промежуточного программного обеспечения с большей степенью детализации управления появляются по мере необходимости.
Промежуточное ПО Redux-promise управляет типом действия, что ограничивает бизнес-сторону выполнением разрешения, когда свойство полезной нагрузки действия должно быть объектом Promise при отправке асинхронных действий, промежуточное ПО запускает действие того же типа и устанавливает полезную нагрузку в обещание и установите для свойства action.status значение «успех».
export default function promiseMiddleware({ dispatch }) {
return next => action => {
if (!isFSA(action)) {
return isPromise(action) ? action.then(dispatch) : next(action);
}
return isPromise(action.payload)
? action.payload
.then(result => dispatch({ ...action, payload: result }))
.catch(error => {
dispatch({ ...action, payload: error, error: true });
return Promise.reject(error);
})
: next(action);
};
}
Такой дизайн полностью отличается от Redux-thunk,Он контролирует процесс преобразования в самом промежуточном программном обеспечении.
dispatch({
type: GET_USER,
payload: http.getUser(userId) // payload 为 promise 对象
})
dispatch(
function(dispatch, getState) {
dispatch({
type: GET_USERE,
payload: userId
})
http.getUser(id)
.then(response => {
dispatch({
type: GET_USER_SUCCESS,
payload: response
})
})
.catch(error => {
dispatch({
type: GET_DATA_FAILED,
payload: error
})
})
}
)
.比如如果想实现乐观更新（Optimistic updates），那就很难做了。具体详见Issue #7
Похоже на Redux-Thunk, контроль размера частиц аналогичен, но более умеренный и постепенный процесс в действии, он будет отправлять xxx_pending, xxx_fullefult, xxx_rejected три типа действия в нужное время,То есть на основе контроля большего количества логики это промежуточное программное обеспечение увеличивает степень связи с внешними третьими лицами и больше не триггерирует xxx_fullefulted и xxx_rejected непосредственно и холодно. Пожалуйста, внимательно понимайте разницу..
Контрольизм и минимализм в государственном управлении
Разобравшись с проблемой управления в асинхронном состоянии, давайте проанализируем ее с глобальной точки зрения Redux. При внутреннем обмене я будуОбщие черты библиотеки классов управления состоянием на основе инкапсуляции ReduxРезюме в виде этого слайда страницы:
Вышеупомянутые четыре пункта являются упрощениями связанных библиотек классов на основе Redux., что очень интересно, это последние три пункта,Они неизменно связаны с контролем.以 Rematch 为代表，它不再是处理 action 到 reducer 的中间件，而是完全控制了 action creator，reducer 以及联通过程。
Конкретно,:
статья, введения относительно достаточно, и я не буду повторять их здесь.
Резюме: кодеры и контроль
В конечном счете, контроль — это дизайнерская идея, и это противостояние и столкновение между сторонними библиотеками классов и бизнес-потреблением. Это не имеет никакого отношения к языку и фреймворку, в этой статье React используется только в качестве примера, на самом деле борьба за контроль в области программирования наблюдается повсюду, она не имеет ничего общего с абстрактными категориями, и в этой статье были проанализированы примеры. в абстракции пользовательского интерфейса и абстракции состояния, Это тесно связано и напрямую определяет наш опыт программирования и эффективность разработки.
Однако на ранних стадиях программирования хороший дизайн управления трудно создать за одну ночь. Только посвятив себя фронтовой разработке, по-настоящему поняв собственные потребности бизнеса, а затем обобщив большое количество лучших практик, одновременно обращаясь к сути сообщества, анализируя отличные работы с открытым исходным кодом, я верю, что мы все растут.
Наконец, передний конец бесконечного обучения, надежды и общего прогресса каждой технологии энтузиастов мы можемЧжиху нашел меня!
Happy coding!
Happy coding!
Книга "React State Management and Isomorphism" написана мной и известным начальником фронтенд-технологий.Ян ХайцзинСовместные усилия сконденсировали наши накопления и опыт в процессе изучения и практики фреймворка React. **Помимо введения в структуру React, основное внимание уделяется анализу управления состоянием и рендеринга на стороне сервера изоморфных приложений. **В то же время он впитал в себя множество отличных идей от сообщества и провел индуктивное сравнение.
Эта книга написана Шэнь Доу, вице-президентом Baidu, Донг Руи, старшим фронтенд-инженером Baidu, Руаном Ифэном, известным экспертом по языку JavaScript, дядей Вольфом, евангелистом Node.js, justjavac, основателем из китайского сообщества Flarum, Сяоли, технический эксперт по интерфейсу в Sina Mobile и старший руководитель Baidu.Совместная рекомендация инженера по интерфейсу Гу Илина и многих других экспертов в круге интерфейса.
Заинтересованные читатели могутНажмите здесь, чтобы узнать подробности.Вы также можете отсканировать QR-код ниже, чтобы совершить покупку. Еще раз спасибо за вашу поддержку и поощрение! Призываю критиковать и исправлять!