вью компоненте (options API) Вы сохраняете статику, которая импортируется в компонент и просто используется в шаблоне ?
1. В data. В данном случае это как бы маленько нарушает концепцию того, что в data мы храним состояние, т.е. данные, изменяющиеся со временем, статика ей не является.
2. В computed. В данном случае как бы также нарушение концепции, ведь computed это производное от состояния, т.е. некоторые данные высчитанные на основе состояния, а статика как бы им не является.
3. В кастомной option, например, constants (соотвественно в шаблоне будет использоваться как $options.constants.staticVarName). Минусом, возможно, может быть то, что название этого option никак не задекларировано на уровне фрейморвка и получается такое небольшое проектное знание.
Как обычно Вы делаете в проектах и на чем основывается ваш выбор ?
В $options потому что это не проектное знание
Не очень понимаю роль «проектного знания» в данном вопросе, к сожалению( Я рассматривал этот вопрос как поиск правильного ответа на вопрос: «Посредством чего (data/computed/$options и тд) лучше всего предоставить доступ теймплейту к статике (она может быть как импортнута откуда-то, так и определена внутри компонента), чтобы темплейт смог его использовать внутри себя». И мы пришли к выводу, что статику, которую template использует, корректнее всего размещать в виде кастомного опшина. Может ли на этот ответ как-то повлиять тот факт, что эта статика, доступ к которой необходимо предоставить темплейту, является/не_является проектным знанием ?
Знания реакт - обычные знания Знания как именно устроена ваша архитектура в проекте, проектные
Я поминаю такое различие. Мне непонятно, как это будет влиять на то, куда необходимо разместить статику для обеспечения к ней доступа шаблону
Обсуждают сегодня