На данный момент у меня есть папка с именем в PascalCase и внутри нее у меня есть файл index.js
- это мой компонент.
Любые Компоненты, непосредственно присоединенные к корневому Компоненту, я вложил в их собственную Папку с их собственным index.js. Я также использую точечную запись, чтобы описать природу любых файлов, непосредственно связанных с этой папкой, например [descriptor].[name].[prefix]
Components/
ComponentName/
|---util.componentName.js
|---constants.componentName.js
|---styles.componentName.scss
|---index.js
ChildComponent1/
|---util.childComponent1.js
|---styles.childComponent1.scss
|---index.js
ChildComponent2/
|---util.childComponent2.js
|---styles.childComponent2.styles
|---index.js
И для моего магазина mobx, потому что у меня меньше шансов иметь действительно глубокую структуру папок с Модули моего магазина У меня есть одна корневая папка-модуль с обычно двумя js
файлами в них Actions.js
& amp; index.js
index - это класс моего основного магазина, который расширяет мой класс Actions. (Я обнаружил, что один класс mobx со свойствами observable
, computed
и action
стал немного загроможденным).
Сама папка Store имеет index.js
, который импортирует все родственные модули-хранилища, чтобы позже объединить их в один объект-хранилище (необходимый для моего проекта)
Store/
StoreModule/
|---actions.js
|---index.js
AnotherStoreModule/
|---actions.js
|---index.js
index.js
Я полагаю, что есть нет НАСТОЯЩЕГО правильного способа, так как это зависит от предпочтений, вышеописанный способ, который я нахожу читаемым, и при использовании инструментов в VSCode для поиска файлов это может упростить поиск таких особенностей, как «я хочу видеть все файлы, которые являются константными файлами» ищет constants.[component name]
Каждое Представление имеет один и только один ViewModel
Я думаю, строги ли Вы о своем следующем шаблона затем, каждое представление будет иметь всего один ViewModel. У нас есть случай в нашем приложении, где требования изменили середину реки, и было самым легким иметь ссылку Представления два различных ViewModels. В зависимости от того, как Вы реализуете шаблон, это может или не может быть возможно.
Есть ли экземпляры где услуги ViewModel два Представления
Да, это - одно из преимуществ шаблона.
Проверка обрабатывается только ViewModel
Не обязательно. Мы приняли решение иметь наши образцовые классы, реализуют IDataErrorInfo и делают проверку сами. Это обеспечивает, чтобы, неважно, где Образцовый класс используется, проверка была тем же. Если проверка когда-нибудь должна изменяться, это находится во всего одном месте.
Модель является довольно немой
Это является только столь немым, как Вы хотите, чтобы это было. Можно включать проверку и бизнес-правила в модели, если Вам нравится.
Я действительно соглашаюсь со всеми, сказал выше. Всего один комментарий: Ваша модель представления может использовать другое представление модели внутри. Используя этот подход можно разделить представление на регионы пары, которые обслуживаются с моделями другого представления. Просто используйте ContentPresenter, свяжите его с необходимым свойством модели представления (который получает необходимую модель представления), и используйте DataTemplate для соединения необходимого представления с моделью представления.
Есть ли экземпляры где услуги ViewModel два Представления
Покрытые кожей приложения могут усилить эту способность.
Модель является довольно немой, но сама модель не обрабатывает проверку
Модель может быть столь умной, как Вам нравится. И это может включать "проверку" для обеспечения целостности, но та проверка не будет включать сообщения, которые появляются в UI.