DenisVladimirovich, если нулевая, то читайте про подсистему управление доступом БСП, если и БСП у вас нет, то это очень странно. Лучше изучите и внедрите, сэкономите кучу времени в будущем.
tatarrr95, в смысле "таким способом"? Это синтаксис языка. Доступ к полям и методам объекта (экземпляра класса), возвращаемого функцией date_diff. А в вопросе - результат сравнения возвращаемых значений двух функций (по синтаксису, по факту одной из функций не существует.).
VegasChickiChicki, дело не конкретно в ssr, а в том, чтобы формировать страницу, отдаваемую пользователю, с помощью того же vue.
Например, когда мы загружаем первую страницу (ну, или при переходе из внешнего источника например email на не первую), мы получаем уже готовый html с сервера. а для перехода на вторую - мы просто загружаем json с данными второй страницы и vue подставляет его вместо первого. Так вот, на этом месте мы имеем, что мы дожны либо реализовывать дважды рендеринг страицы (на стороне клиента и на стороне сервера), либо рендерить все и на стороне сервера и на стороне клиента одним кодом.
Есть промежуточный вариант: вставлять на стороне сервера в vue компонент JSON с данными (например в larevel в виде см рендеринг JSON ) и рендерить все на стороне клиента, но вроде бы, такой подход не очень любят поисковики.
Андрей Брекоткин, vue пытается как можно меньше дергать dom, что при одинаковых кусках может приводить к такому эффекту. но вообще похоже на ошибку, поскольку v-model все-таки разный. Другое дело, что ваш пример слишком синтетический, в реальности так не бывает. Ну а вообще добавление key помогает во многих случаях именно отцепить один кусок dom и прицепить другой, а не "мутировать" имеющееся поддерево.
Андрей Брекоткин, не применяется change, во второй форме checked проставляется на основе реактивного свойства. Кажется, вы не поняли суть Vue (и вообще реактивности, когда страница строится от данных, а не наоборот).
renat-911, тут я могу только одно сказать - все давно придумано до нас. Например то, что чтение критических данных должно происходить в транзакции, равно как и запись.
Запросы отчетов - так пусть читают данные вне транзакций и будут иметь относительно консистентные данные (либо как выполненные до проведения вашей операции, либо после). Запросы в действиях, вносящих изменения - в транзакции и тогда также все будет правильно, при чтении они встанут в очередь.
Всё будет работать.
Еще почитайте про принципы двойной записи, раз уж у вас финансовая система. Хоть принцип и старый, но надежный.
