В чем суть конечного автомата на примере фронтенда?

Question

[AlexNew22]

Как понять логику конечного автомата на примере фронтенда?
Читаю статьи и не совсем понятно какой смысл в него закладывают, больше похоже на рекламу if else возможности языков
Если можно, с примером кода пожалуйста

Answer 1

[AnonymFromInternet]

Конечный автомат это функция.
Смысл конечного автомата (такой функции) в том, что она всегда при одинаковых входящих данных выдает одинаковый результат. Т.е. , например у этой функции есть входящий аргумент с определенным значением. Внутри функции это значение каким либо образом обрабатывается, и эта функция, например, возвращает это обработанное значение. В следующий раз, когда входящий аргумент будет таким же, функция обязательно должна вернуть такое же значение, как и всегда.

В качестве примера можно привести Reducer.
Если есть опыт работы с Redux, то я думаю, поймешь о чем речь.
Если нет, то:
Представь, что в приложении есть некий общий объект, который хранит в себе некие данные этого приложения. Например произошёл запрос на бэкенд, получен ответ, и данные сохранились в этом объекте. К этому объекту есть доступ у всех компонентов приложения. Т.е. отпадает потребность туда сюда из компонента в компонент передавать эти данные в виде props.
Данные в этом объекте может менять определенная функция. И этой функцией является редьюсер. И этот редьюсер и должен быть конечным автоматом.
Т.е. в редьюсер передаются данные, он эти данные принимает, распознает не при помощи if else, а при помощи switch case, так как это удобнее, и меняет данные в объекте. И, в следующий раз при передаче этому редьюсеру этих же данных, он поменяет данные в объекте абсолютно точно также.

const reducer = (state, action) => {
 switch(action.type) {
  case "new value":
  return{...state, value: action.payload}
}
}

Comments

[NikitaLikosov]

Функции конечного автомата не обязаны быть чистыми. Даже обязаны не быть чистыми если они мутируют глобальную переменную состояния, а не принимают и возвращают новое. Redux хороший пример конечного автомата, но чистые функции по сути никак не связанны с конечными автоматами.

Answer 2

[Сергей Сергей]

Конечный автомат — это ограниченное количество состояний, входные сигналы для перехода между состояниями и выходящие при этих переходах, а также сигналы текущего состояния. В теории их делят по выработке сигналов, но на фронтенде всё смешивается всё равно.
И важно помнить, что для фронтенда "конечный автомат" применяется в большей степени для процесса, а не значений. То есть, состояниями будут, например, являться:
• инициализация/загрузка документа — что до события download,
• открытое модальное окно,
• передача данных из формы,
а сигналами будут как раз события:
• ondowload сигнал для перехода из состояния загрузки в состояние готовности,
• клик по определённой кнопке — это сигнал для закрытия модального окна, например.
• submit формы
• response или reject — ответ на форму,
ещё сигналы из таймеров подойдут:
• таймаут загрузки, как самое очевидное,
• циклическая подгрузка, типа для новостей.
И по теории автоматов должно быть так, чтобы переход из одного состояния в другое всегда сопровождался определённым сигналом. Например, бесконечная лента записей из состояния просмотра по сигналу "докрутили до конца" переходит в состояние "подгрузка". Но ведь пользователь может крутануть назад и вперёд, что опять породит сигнал "докрутили до конца", но из состояния "подгрузка" не должно быть переходов по этому сигналу, а потому не должно быть и повторного запроса на сервер.

Можно примешивать ещё и значения, связанные с контентом, например, зависимость поведения от конкретных данных, но тогда количество состояний рискует быть неограниченным.

И тут начинается цирк с конями.

Обычное действие — форма заявки. Здесь можно начать с состояния "покоя", когда никаких действий пользователь ещё не совершил. Затем клик по кнопке "Заявка" — сигнал. Появляется модальное окно с формой — другое состояние. Здесь два пути, продолжить заполнять форму или закрыть её, оба пути – сигналы.
НО процесс заполнения формы порождает зависимость от значений, так как нужна валидация введённых данных. Тут вроде бы и один сигнал "Отправить", но порождает два состояния: передача данных или "неверные данные в форме". С передачей данных более-менее понятно, переводим в состояние "Подождите" с каким-нибудь эффектом вращающейся свистелки.
А как определить переход в состояние "неверной формы"? Технически это запуск функции валидации через перехват submit события, но логически это противоречит "конечным автоматам", а потому результат валидации становится сигналом. А ещё бывает так, что части формы нужно скрывать или показывать по чекбоксу в той же форме. Здесь есть место для размышлений и споров, да.

И ещё, разные части страницы могут обладать своими независимым состояниями, а это порождает нужду в независимых, параллельно существующих автоматах или целой автоматной иерархии.

Answer 3

[NikitaLikosov]

Конечный автомат это функция или набор функций которые получает состояние и действие. В зависимости от них что- то делает и задаёт новое состояние. Есть начальное, промежуточные и обычно конечное состояние. Они меняются во время жизненного цикла приложения. Redux хороший пример конечного автомата. Когда мы в вузе это проходили я с удивлением узнал в нём банальный стейт с функциями в setState.

Answer 4

[Александр Скуснов]

Если забыть про текстовый язык (JS) и перейти к графическому, то очевидные преимущества будут налицо: пример Stateflow из MatLab/Simulink. Обычно используется автоматчиками.