Простая вроде задача и сделать можно по разному.
Суть: в веб приложении есть форма редактирования объекта.
Какие мысли кто должен определять какие поля можно редактировать: фронт или бэк?
Фронт вроде проще, не надо доп.запросов на бэк, но бэк вроде как должен определять логику приложения и если сделать аттрибуты на эти поля на бэкенде, то можно потом знать какие поля меняться могут, а какие нет
Здравствуйте, merge, Вы писали:
M>Какие мысли кто должен определять какие поля можно редактировать: фронт или бэк? M>Фронт вроде проще, не надо доп.запросов на бэк, но бэк вроде как должен определять логику приложения и если сделать аттрибуты на эти поля на бэкенде, то можно потом знать какие поля меняться могут, а какие нет
Я бы сделал во фронте, но бэк всё равно должен верифицировать изменения.
Здравствуйте, merge, Вы писали:
M>Какие мысли кто должен определять какие поля можно редактировать: фронт или бэк?
И фронт, и бэк. Бэк с точки зрения, что разрешено пользователю. Фронт с точки зрения, что ему нужно в данный момент. В разных формах могут редактироваться разные поля одного объекта. А в одной форме могут быть собраны поля от разных объектов.
Здравствуйте, merge, Вы писали:
M>Простая вроде задача и сделать можно по разному. M>Суть: в веб приложении есть форма редактирования объекта. M>Какие мысли кто должен определять какие поля можно редактировать: фронт или бэк? M>Фронт вроде проще, не надо доп.запросов на бэк, но бэк вроде как должен определять логику приложения и если сделать аттрибуты на эти поля на бэкенде, то можно потом знать какие поля меняться могут, а какие нет
Бэк, конечно. Этот кто-то кто определяет, какие поля можно редактировать, сохранит это в бд ведь. С тз расширяемости и понятности арх-ры я бы все хранил
на бэке.
Здравствуйте, merge, Вы писали:
M>Какие мысли кто должен определять какие поля можно редактировать: фронт или бэк? M>Фронт вроде проще, не надо доп.запросов на бэк, но бэк вроде как должен определять логику приложения и если сделать аттрибуты на эти поля на бэкенде, то можно потом знать какие поля меняться могут, а какие нет
Может бек возвращать список полей, их типы, свойства, метки и т.д. Чтобы совсем православно. А может бек возвращать список флагов (фич) при старте приложения. И UI из этого списка уже поймет, какую вообще форму делать и делать ли ее, какие там поля и т.д. У меня эволюционно скатилось к второму варианту. Первый вариант в одном месте остался, и неизменно смущает новых людей излишней "гибкостью" читай- сложностью на ровном месте.
Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, merge, Вы писали:
M>>Какие мысли кто должен определять какие поля можно редактировать: фронт или бэк? M>>Фронт вроде проще, не надо доп.запросов на бэк, но бэк вроде как должен определять логику приложения и если сделать аттрибуты на эти поля на бэкенде, то можно потом знать какие поля меняться могут, а какие нет
Аё>Может бек возвращать список полей, их типы, свойства, метки и т.д. Чтобы совсем православно. А может бек возвращать список флагов (фич) при старте приложения. И UI из этого списка уже поймет, какую вообще форму делать и делать ли ее, какие там поля и т.д. У меня эволюционно скатилось к второму варианту. Первый вариант в одном месте остался, и неизменно смущает новых людей излишней "гибкостью" читай- сложностью на ровном месте.
Да, где-то так. Бек возвращает список разрешений для пользователя, а как это осуществить — это уже дело фронда, он нужным образом для этого настраивает контролы.
