Идея такая: Я создаю описание полей для формы. [

{
fieldName: 'ФИО',
isRequired: true,
onClick: /* тут хочу иметь ссылку на функцию, которая находится в мутациях или геттерах*/
}
]

После чего по этому массиву я просто отрисовываю все на экран. функция, которая будет в свойстве onClick может повторяться у нескольких полей. Как это ограничение можно обойти?

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

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

Действия менеджер будет в админке прямо на JS писать? Или есть какое-то описание действий, какая-то модель?

Для менеджера будет выпадающий список из зараане заготовленных дейтсвий

Тогда почему бы не хранить эти действия отдельно от данных?

Т.е. стоит хранить имя функции, или какой-то иной идентификатор? [ { fieldName: 'ФИО', isRequired: true, onClick: 'functionName' } ]

обычно это делается иначе: - есть какой-то список возможных экшнов с полями, который уже реализован на vue; - менеджер в админке выбирает нужный экшн, который сохраняется в бд числом или строкой вместе с остальными данными; - при рендеринге ты смотришь, что там за экшн и сопоставляешь это с заранее заготовленным функционалом либо по какой-нибудь карте действий, либо по названиям

ну типа такого, да

Скорее хранить не onClick и имя функции, а что-то, что описывает элемент и позволяет понять, какие события на нём и как должны обрабатываться. onClick — что-то более низкоуровневое

Имеется ввиду сделать свойство events, и уже у него сделать свойство onClick?

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

Мне кажется это не возможно. Т.к. на одном и том же поле могут быть разные действия, в зависимости от анкеты. В одной анкете при заполнении поля ФИО должны будут отобразиться еще 2 поля, а в другой анкете ничего не должно происходить.

По этому и были мысли именно о конструкторе, который просто берет то, что ему дали и больше ни о чем не думает

Это точно возможно, потому что каким-то образом у вас менеджер будет описывать эти действия. И менеджер точно не будет думать в терминах DOM событий или js функций

Согласен, менеджер будет думать о том, что должно происходить при конкретных действиях заполняющего. Но как я сказал выше, действия зависят не от типа поля, а от анкеты, для которой менеджер делает поля. Не станем же мы писать у себя в коде для каждой анкеты свои типы полей, если у них отличия только в том, что будет на onClick. А почему вы считаете что лучше воспользоваться таким описанием элемента, а не просто хранить в onClick имя функции?

заранее нужно подготовить список возможных экшнов и реализовать их на vue например, есть экшн “hideFields” - это когда менеджер в админке выбирает “Скрыть поля” и указывает, какие именно скрыть ты должен при рендеринге проверять эти экшны и передавать их соответствующим обработчикам конкретно в данном случае ты смотришь, что выбран экшн hideFields и нужно скрыть, например, поля “email” и “phone”, именно это ты и делаешь

> Но как я сказал выше, действия зависят не от типа поля, а от анкеты Тут нет противоречия. Для конкретной анкеты менеджер будет как-то настраивать какие-то действия, свойства и т.д. Но делать он это будет с какой-то более высокоуровневой моделью, чем конкретные DOM события. > А почему вы считаете что лучше воспользоваться таким описанием элемента, а не просто хранить в onClick имя функции? Потому что это слишком низкоуровнево. Ваша конечная цель - не клик обработать, а реализовать поведение анкеты. Просто пока это поведение ограничивается обработкой клика. Завтра окажется, что одновременно надо ещё о фокусе как-то думать. Или о тапе отдельно. Или действие в целом будет сложнее. Данные при этом не будут изменяться. Ну и в целом в этой задаче, где по данным генерируется анкета, в основе всего именно структура данных, которая описывает анкету, и отталкиваться надо от неё. Анкета у вас будет как-то храниться, как-то создаваться, как-то редактироваться.

Именно так я сейчас и собираюсь сделать

стор должен строиться поверх той структуры данных, которая у вас есть, не наоборот. У вас бек в каком виде хранит все эти действия, настроенные менеджером?

Первый абзац был про то, что я не понимаю как мне описать поля по типу, если менеджер может навешать любые действия на любые поля? > Завтра окажется, что одновременно надо ещё о фокусе как-то Тогда я либо добавлю в админку еще поле onFocus, либо при фокусе буду делать тоже самое, что и при клике. Свойство onClick я теперь собираюсь перенести в объект events, что бы можно было подписаться на любое событие: [ { fieldName: 'ФИО', isRequired: true, events: { onClick: 'functionName' } } ]

Пока ни как. Это только в планах. Сейчас важен именно фронт. Сейчас конфиг пишем руками во vue

> Первый абзац был про то, что я не понимаю как мне описать поля по типу, если менеджер может навешать любые действия на любые поля? Вместо этого надо определять не обработку DOM событий и реализацию, а модель. Описать, как и зачем может настраивать анкету менеджер. Менеджер - не разработчик. > Тогда я либо добавлю в админку еще поле onFocus, либо при фокусе буду делать тоже самое, что и при клике. И менеджер должен будет думать, когда какие событие нужны, как там дела на разных платформах и в целом разбираться в HTML/JS?

Вот в этом и проблема скорее всего. Здесь не получится отталкиваться от представления. Здесь нужно продумать структуру данных, модель анкеты, а уже поверх неё будут правила, по которым декларируется представление анкеты. Определите чётко, какие типы элементов в анкете, чем они могут отличаться, что в них будет настраиваться, какие могут быть действия

> что в них будет настраиваться, какие могут быть действия Всё ни как не могу уловить вашу мысль, почему мне надо это продумать? Это же конструктор, есть куча блоков, менеджер их склеивает как хочет и на выходе все работает. Помимо клика сейчас есть еще событие изменения поля onChange. Допустим нам надо что бы при заполнении поля "телефон" у нас отобразились еще два поля. Менеджер в админке вешает на поле "телефон" событие "при изменении", выбирает "отобразить поля" и пишет что это за поля. Все готово. А если описывать по типам, то менеджер должен выбрать поле "телефон с отображением полей после заполнения" и пишет что это за поля. Так?

> Всё ни как не могу уловить вашу мысль, почему мне надо это продумать? Потому что вы будете это реализовывать > Это же конструктор, есть куча блоков, менеджер их склеивает как хочет и на выходе все работает. Менеджер склеивает блоки, настраивает поведение. Он думает об анкете на высоком уровне абстракции. Он не должен думать о том, как работает HTML, какие бывают события, какие есть нюансы между событиями. Думать, чем клик отличается от фокуса, input от change и т.д. Тем более он не будет писать код функций или выбирать имя экшина в сторе.

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

У нас есть разделение на типы полей: телефон, почта, чекбокс, текст и т.п. Но вот разделения на "телефон с отображением полей после заполнения" пока осознать не могу. Вы про какое разделение на типы имеете ввиду?

Нет, я вообще ничего не говорил про типы полей) Мы же не поля разные обсуждаем, а действия в анкете

Выше вы писали: > Описать, как и зачем может настраивать анкету менеджер. Что вы имели ввиду?

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

Тогда мне кажется мы с вами говорим про одно и то же ) Менеджер в админке создает поля: 1) Указывает тип поля (текст, телефон и т.п.) 2) Заполняет настройки для выбранного типа поля 3) Выбирает события, при котором должно что-то происходить с этим полем (клик, изменени и т.п). 4) Есть набор стандартных событий, которые менеджер не может изменить, и список событий, которые он может кстомизировать. Менеджер из выпадающего списка выбирает доступные ему действия (отобразить другие поля, вывести сообщение и т.п.) 5) Менеджер заполняет необходимые настройки для выбранного поля > Возможности менеджера по настройке анкеты ограничены. Получается что он может выбирать только то, что есть в выпадающих списках, и кастомизировать только то, что доступно в полях для каждого конкретного действия. > Набора различных сущностей анкеты, их настроек, действий в анкете Получается что у нас есть описание сущностей полей (телефон, текст, почта и т.п.), и отдельно описание что должно происходить с сущностью поля при изменени поля, клике и т.п. Т.е. мы любое поле можем заставить показать сообщение по клику, или отобразить другие поля при заполнении. Отмечу, что это тот функционал, который сейчас уже работает на восьми полях. На самом деле функционала сейчас есть на много больше. Но это все было сделано без стора. И когда стал переносить на стор, застрял именно на моменте, что делать с функциями в свойствах поля. Так все-таки, мы с вами про одно и то же говорим? Или я ошибся?

> Так все-таки, мы с вами про одно и то же говорим? Или я ошибся? Вы думаете, что менеджер - это разработчик, который должен знать, как работает HTML, какие в нём есть события и в целом понимать работу анкеты на низком уровне. Либо сами опускаете какие-то нюансы на этом уровне. Вы в четвёртом пункте пишите "выбирает доступные ему действия". Эти действия, а также условия из выполнения и нужно описывать. Но это что-то более высокоуровневое, чем DOM события. Менеджеру не нужны неограниченные все возможные комбинации разных действий в анкете. Определите, что и зачем он может сделать. Что такое клик, например? Есть разница между кликом и фокусом? Менеджер тоже знает ответ на этот вопрос? А стереть написанный телефон - это действие изменения? По этому мне интересно, в какой структуре вы храните всё это, и как, если у вас не определены границы возможностей в терминах бизнес процессов, а не разработчиков.

С фокусом хороший пример, но мы пока не сталкивались с таким кейсом. На счет остального думаю что менеджер может понять что такое нажатие на поле, и что такое изменение данных в поле. Менеджер оперирует только человеческими названиями, мы ему не выводим ни куда onClick или onChange. У нас есть как низкоуровневые DOM события, такие как клик и onChange, так и что-то вроде "когда будет заполнено такое-то поле с таким значением сделай то-то". Но для менеджера это всегда человеческие названия. Этим ограниченным списком событий и ограниченным списком действий, которые можно вешать на эти события (отобразить поле, показать сообщение и т.п.) мы менеджера и ограничиваем.

В таких же ограничениях и опишите в данных анкеты действия в ней

Опишите действия поля в виде некоторого списка, в котором описаны триггеры действия и само действие. Триггер != DOM событие, действие != название экшина. Возможные триггеры и действия в анкете где-то у вас должны уже быть известны. Ну и дополнительные какие-то параметры, конечно

Так это же все уже описано. Только каждое действие описано по отдельности, а не их комбинации. Т.е. отдельно описано поведение поля телефон, отдельно описано поведения функционала "отобрази указанные поля, если указанное поле заполнено". Каждое поле генерирует события, на которые я подписываюсь в родительском компоненте и как-то реагирую, в зависимости от указанных настроек. Весь наш разговор я считал, что вы говорите о том, что надо описать каждую возможную комбинацию. Но кажется я ошибался. В целом, я понимаю о чем вы говорите. И кажется что идеологически у меня сейчас так и сделано, но может реализовано не так как это видится вам. Простой пример. После заполнения текущего поля отобразить еще два поля. onChange(field){ if (field.setting.isShowFields){ /* отображаем поля */ } }

> Весь наш разговор я считал, что вы говорите о том, что надо описать каждую возможную комбинацию Нет, я вообще нигде не говорил про комбинации. Я говорил о том, что надо отталкиваться от структуры данных, в которой вы храните описание анкеты. И в том же виде хранить описание действий разный элементов одной анкеты. > Т.е. отдельно описано поведение поля телефон, отдельно описано поведения функционала "отобрази указанные поля, если указанное поле заполнено". Да, норм. Просто это должно быть описание. В ваших первых примерах не было описания действий. Были функции обработки событий.

И такой onChange вы хотите описать всем полям с проверкой условий на все действия в них и возвращать геттерами?

У меня есть компонент каждого отдельного типа поля, который генерит событие change. В общем компоненте поля, внутри которого отрисовываются все поля, я отлавливаю @change, и выполняю одну функцию onChange. А внутри этой функции у меня уже прописан общий функционал и функционал, который может быть включен для данного события через дополнительные настройки.

Ок. А какая конкретно сейчас с этим проблема?)

Это я уже слегка запутался. Дело в том, что сейчас у меня часть настроек для полей идут через геттеры, которые я прописываю руками. А в вопросе я сразу попытался решить и будущую проблему при заполнении данных менеджерами. Думаю об одном, а пишу о другом. Получается что вы правы, в данном случае стоит отталкиваться от того, как эти данные хранятся на бэке.

Спасибо за столь дотошное докапывание. Не часто такое встретишь в чатах. Теперь есть мысли, как переписать код, что бы все заработало корректно