1) Это звучит выполнимо.
2) Нет. Что бы ни делало работу.
Я бы создал состояние postPagination в блоге, где бы я держал данные о нумерации страниц отдельно от сущностей. И действие BlogPaginate для изменения его состояния в функции редуктора.
{
{
sort: 'date',
filters: {
category: 'home',
tag: 'testTag'
}
},
page: 1
}
Я хотел бы создать эффект, который прослушивает действия маршрутизатора и сопоставляет соответствующие (url / blog / *) с соответствующими поисковыми фильтрами для действия BlogPaginate, которое, в свою очередь, вызывает вызов службы.
Возвращение к страницам, которые вы видели ранее, было бы более плавным, чем раньше. В зависимости от скорости изменения содержимого я бы выбрал отправку действия или использование значения в кэше, если оно существует.
Затем я бы добавил к состоянию postPagination:
{
pageContents: {
// map of page to entity ids
1: [1,8,222]
}
{
sort: 'date',
filters: {
category: 'home',
tag: 'testTag'
}
},
currentPage: 1,
totalPages: 10
}
Каковы преимущества наличия проектов в том же решении, если Вы используете ссылки на файл?
Если Ваш app.exe
использование utils.dll
и Вы изменяете код для utils.dll
, затем, если это будет в том же решении, то VS заметит зависимость и перекомпилирует обоих. Если это не находится в решении, необходимо будет выскочить, перекомпилировать utils.dll
отдельно, затем переход въезжает задним ходом и перекомпилировал app.exe
.
Это становится более или менее важным в зависимости от того, на сколько Ваш exe другого dll ссылается, и как часто они изменяются (в изменении совместно использованного dll сред команды часто, по моему опыту).
Существует также побочный эффект, что, если у Вас есть 100 проектов в VS, будет требоваться много времени для обработки их всех только, чтобы выяснить, нужна ли им перекомпиляция или нет.
Для моих проектов я создаю assemblies
папка, в которую автоматически копируют проекты от местоположения набора, до которого другие проекты копируют сборки.
Постсборка для проекта ссылаемого блока:
if not exist "C:\builds\Project1" md "C:\builds\Project1\" copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"
Предварительная сборка для ссылки на проекты:
если существуют копия "c:\builds\Project1\" "c:\builds\Project1*.*" "$ (ProjectDir) блоки"
Файл проекта указывает на assemblies
подпапка для ссылок поэтому, даже если исходные проекты разгружены из решения, созданные в последний раз блоки, будет использоваться без проблем производительности наличия целого проекта в памяти при разработке.
Разгрузка проектов предназначена, чтобы быть временным действием, таким образом, можно отредактировать фактический файл проекта как XML (текст). Если Вы хотите полностью удалить проект из своего решения, необходимо использовать пункт меню "Remove", который будет заботиться об удалении любых ссылок на тот проект.
Одно преимущество для использования ссылок проекта состоит в том, что оно позволяет Вам легко отлаживать через код. Это также автоматически гарантирует использование корректной сборки конфигурации (т.е., если Вы создадите в режиме "Debug", то это будет использовать Отладочную версию блока). Однако Вы освобождаете некоторый determinisim, о которой версии/сборке зависимого проекта Вы возьмете - ссылки проекта означают, что Вы всегда используете последнее.
Да, чтобы Visual Studio определила зависимости от сборки, она должна смочь видеть и разработать все проекты, которые означали бы ссылки проекта.
Я только что имел эврика момент, прочитывая документ MSDN о структурировании решений и проектов.
То, что я не заметил, - то, что в многопроектном решении, контекстное меню в Проводнике Решения делает предложение Зависимости, Проекта раскрываются. Здесь можно определить зависимости проекта вручную, если Вы не определили их ссылками проекта между проектами.
Посмотрите здесь (ссылка MSDN, так будет сам разрушать после нескольких недель),