Я исследую демо-версию / аккаунт приложения для пользователей. Демо-счет предназначен только для чтения для потенциальных клиентов, так что они могут просматривать полнофункциональный демо-счет. Вместо того, чтобы регистрироваться или платить за приложение, чтобы увидеть, как оно выглядит, они могут просматривать, что это за служба и каковы ее функции, не подписываясь на нее.
Это может быть основано на данных stati c ( и не требует динамической генерации).
Основываясь на моем исследовании, я сделал несколько выводов, которые могут быть полезны для создания демонстрационного приложения и сохранения постоянства демонстрационного приложения с исходным приложением:
- У нас могут быть отдельные маршруты для демонстрационного приложения, например,
app.com/demo/dashboard или app.com/dashboard?demo=1. С отдельным маршрутом мы должны использовать отдельные компоненты, потому что я не хочу запутывать демонстрационные компоненты с исходными компонентами, потому что у него много логических c аутентификации, вызовов API и прочего. При таком подходе возникает проблема сохранения постоянства пользовательского интерфейса демонстрационного приложения с фактическим приложением.
Чтобы преодолеть это, я могу использовать один и тот же стиль для нескольких компонентов, но не для структуры. Так что со временем синхронизация структуры станет затруднительной. c.
Итак, я ищу общие ответы на следующие вопросы: Каков наиболее эффективный способ создания демонстрационной версии приложения? Какие данные использовать? Как сохранить стойкость компонентов. (Для этого, возможно, мы сможем создать рабочий процесс Git, чтобы инженеры обновляли структуру демонстрационного пользовательского интерфейса всякий раз, когда они обновляют структуру исходного пользовательского интерфейса)
Надеюсь, этот псевдокод передает мой мыслительный процесс
One of the demo web application example is: https://demo.pritunl.com/