все что можно было там разрулить адаптивной версткой было адаптировано и так

я же в вуй чате ?

Нужно обратить внимание на структуру данных в целом, использовать связанные списки например

там сложное дерево, где разные варианты выбора показывают одинаковые вопросы. Причем есть ситуация когда: - При выборе Х - показывается вопрос А, и после него (в зависимости от выбора А) показывается либо B либо C - При выборе Y - показывается вопрос А, но после него должны идти поля D и F

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

это один из вариантов, но он не имеет смысла для vue шаблонов

которые сами по себе и так декларативны

и делать еще одну декларативную надстройку над ним как то странно

то что ты опишешь правила для каждого поля где то там снаружи, получится по сути тоже самое что ты опишешь их на языке шаблонов vue внутри template

все разруливаеться через state

то что ты опишешь правила для каждого поля где то там снаружи, получится по сути тоже самое что ты опишешь их на языке шаблонов vue внутри template

но эти правила тебе потом понадобятся и при валидации, например

все разруливаеться через state

http://tsya.ru/

но эти правила тебе потом понадобятся и при валидации, например

валидация разная бывает

валидация разная бывает

это да, но нужно учесть - не понадобиться ли потом тащить всё это ещё куда-то

1. валидация по сабмиту всех значений полей синхронно/асинхронно 2. валидация отдельных полей по блюру/асинхронно

на самом деле если форма действительно сложная, я бы воспользовался каким нибудь final-form

по крайней мере с валидациями проблем не будет уж точно

там сложное дерево, где разные варианты выбора показывают одинаковые вопросы. Причем есть ситуация когда: - При выборе Х - показывается вопрос А, и после него (в зависимости от выбора А) показывается либо B либо C - При выборе Y - показывается вопрос А, но после него должны идти поля D и F

Значит сначала описать дерево в виде json например и при каждом изменении в форме запускать функцию которая будет сравнивать дерево с входными данными и перерисовывать всю форму

я валидацию по блюру сделал пока что. у меня засада в том как показывать нужные поля без дублирования кода. чтобы они шли один за другим

я валидацию по блюру сделал пока что. у меня засада в том как показывать нужные поля без дублирования кода. чтобы они шли один за другим

ты пока не заморачивайся по поводу дублирования

ты сначала сделай так чтобы все работало просто

рефакторинг это следующая итерация уже

ну и само собой 3 это валидация на бакенде еще

это то что асинхронно по сабмиту собственно

чтобы оно работало - надо придумать как показывать поля в нужной последовательности :) В шаблоне у меня идут списком: <tag v-if=choosen(1)"> <tag v-if=choosen(2)"> <tag v-if=choosen(3)"> Проблема как показать 3й tag перед первым

чтобы оно работало - надо придумать как показывать поля в нужной последовательности :) В шаблоне у меня идут списком: <tag v-if=choosen(1)"> <tag v-if=choosen(2)"> <tag v-if=choosen(3)"> Проблема как показать 3й tag перед первым

да вариантов море, даже через CSS порядок расстановки можешь указать

можно либо через flex порядок разрулить

либо через display: box, box-ordinal-group

о инвалидно выглядит

<slot>

блин, точно. Спасибо

чтобы оно работало - надо придумать как показывать поля в нужной последовательности :) В шаблоне у меня идут списком: <tag v-if=choosen(1)"> <tag v-if=choosen(2)"> <tag v-if=choosen(3)"> Проблема как показать 3й tag перед первым

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

let data = [ { name: 'a' status: false, el: "element link" variants: [ { name: 'b' status: false, el: "element link", variants: [ { name: 'd', status: false, el: "element link", variants: [] }, { name: 'e', status: false, el: 'element link', variants: [ { name: 'c', status: false, el: 'element link', variants: [] } ] } ] }, { name: 'c' status: false, el: "element link", variants: [ { name: 'e', status: true, el: 'element link', variants: [] } ] } ] } ];

хм

Можно прожодить при каждом изменении в форме рекурсивно по всему дереву и отрисовывать элементы, если выбрано какое то поле ( например а ) то его статус в true и рисовать варианты

и тд

ага, я в принципе понимаю идею

для таких сценариев идеально использовать рендер-функции

Это причем расширяемо, если попросят например новые варианты ответов завести, просто меняешь этот конфиг и он автоматом все подхватывает

Можно прожодить при каждом изменении в форме рекурсивно по всему дереву и отрисовывать элементы, если выбрано какое то поле ( например а ) то его статус в true и рисовать варианты

идея интересная, спс, попробую реализовать

Это причем расширяемо, если попросят например новые варианты ответов завести, просто меняешь этот конфиг и он автоматом все подхватывает

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

поэтому сделали простой шаблонизатор

чтобы не описывать варианты структуры, не парсить ее потом и не рендерить

а сразу на языке шаблона всзять и описать

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

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

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

так vue template полностью покрывает требования задачи

в зависимости от значения ключевого поля выводишь нужные блоки, ненужные прячешь

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

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

А если нужно добавить новое поле? Или два или три? В стили полезешь все править?)

так vue template полностью покрывает требования задачи

Покажи пример, пока это просто слова

А если нужно добавить новое поле? Или два или три? В стили полезешь все править?)

да, конечно

полезу править туда, где выставлен порядок полей

да, конечно

Ну удачи)

но это будет очевидно зато

let data = [ { name: 'a' status: false, el: "element link" variants: [ { name: 'b' status: false, el: "element link", variants: [ { name: 'd', status: false, el: "element link", variants: [] }, { name: 'e', status: false, el: 'element link', variants: [ { name: 'c', status: false, el: 'element link', variants: [] } ] } ] }, { name: 'c' status: false, el: "element link", variants: [ { name: 'e', status: true, el: 'element link', variants: [] } ] } ] } ];

Что может быть очевиднее этого?)

а вот ты сделав мегаструктуру с объектом потом реально раком можешь встать с такой формой

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

а вот ты сделав мегаструктуру с объектом потом реально раком можешь встать с такой формой

Ты со стилями в css скорее раком встанешь))

стили это как вариант простой перестановки элементов в flex-box

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

Парсер настроен именно на нее в чем проблема))

че там вставать раком то?

Парсер настроен именно на нее в чем проблема))

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

а так ему придется ограничиться только знаниями vue/css

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

я могу юзать геттеры из стора в beforeRouteEnter?

с метапрограммированием и всякими велосипедными структурами

если да, то как их туда прокинуть, потому как бьет undefinde

ERROR: S client not available

я могу юзать геттеры из стора в beforeRouteEnter?

что угодно можно юзать

если да, то как их туда прокинуть, потому как бьет undefinde

импортируешь свой стор и юзаешь store.getters.someGetter Доступа к this у тебя нет, если только внутри next

окей, thx

а так ему придется ограничиться только знаниями vue/css

Ага и сломать глаза от условий в шаблоне и разобрать твой css всеми order или nth-child() ))

Ага и сломать глаза от условий в шаблоне и разобрать твой css всеми order или nth-child() ))

ну css это как один из вариантов, при нормальной организации кода и именований ничего не сломаешь

ну css это как один из вариантов, при нормальной организации кода и именований ничего не сломаешь

По мне вариант с реализацией порядка и правил отображения в шаблоне будет норм, если структура оч редко меняется и полей довольно мало. Описать конфигом, в котором будут условия и порядок отображения 50ти полей намного проще, разобравшись только как работают эти правила и от чего зависит сортировка. При этом изменения нужно будет сделать только в этом конфиге и всё.

По мне вариант с реализацией порядка и правил отображения в шаблоне будет норм, если структура оч редко меняется и полей довольно мало. Описать конфигом, в котором будут условия и порядок отображения 50ти полей намного проще, разобравшись только как работают эти правила и от чего зависит сортировка. При этом изменения нужно будет сделать только в этом конфиге и всё.

я к тому, что такое описание в объекте будет ни разу не проще, чем такое же на языке шаблонов vue

я к тому, что такое описание в объекте будет ни разу не проще, чем такое же на языке шаблонов vue

чем будет больше полей - тем будет проще

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

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

ну если можно разрулить в шаблоне, но это будет сложно поддерживаемо - зачем всё тянуть в шаблон?

ну если можно разрулить в шаблоне, но это будет сложно поддерживаемо - зачем всё тянуть в шаблон?

вот ты сейчас показал пример хороший

поддерживать компонент, в котором будет 70 зависимых полей, из которых реальных 50 - это жесть же?

завтра придет чудик на проект и захочет этот объект отдавать с сервера

послезавтра придет другой чел и будет долго искать откуда что берется

так рождаются говнопроекты

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

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

это пока условия не усложнились

я о том, что сам путь в никуда

глядя в vue шаблон каким бы он не казался большим или небольшим, его всего можно оптимизировать в конце концов

понять что пошло не так и легко поправить

это пока условия не усложнились

Ты понимаешь что в конфиге описывается все зависимости, просто в одном месте или нет?)

а когда ты устраиваешь вот такие пляски с бубнами, они в итоге приводят к проблемам

это пока условия не усложнились

если описать всю логику в шаблоне, а затем усложнить условия - то можно и кровь из глаз заполучить)

если описать всю логику в шаблоне, а затем усложнить условия - то можно и кровь из глаз заполучить)

Именно так)

глядя в vue шаблон каким бы он не казался большим или небольшим, его всего можно оптимизировать в конце концов

если ты открываешь файл на 800 строк - то ты будешь неделю пытаться понять что там вообще происходит)

и скорее всего что-то проглядишь

шаблон vue как раз для этого и разработан, чтобы логику презентации данных описать простым языком

если ты открываешь файл на 800 строк - то ты будешь неделю пытаться понять что там вообще происходит)

для этого есть слово - декомпозиция

вот реальный пример из жизни

тоже в проекте так чувак сделал сначала такой же объектик