@epigraph/configurator-lite

epigraph-configurator-lite

An initiative to build a version of the configurator that utilises the findings from the epigraph-configurator solution and implements the solution that fulfills about roughly 90% of the projects we have delivered. We also do everything mentioned while ensuring that we build a better user experience at the end of the day.

Some philosophies that we will be adhering to:

• Library First - Create libraries instead of web component unless absolutely required (discuss with the team before proceeding)
• Engine Agnostic - Shouldn't be too complicated to migrate to a new engine in the future instead of threejs.
• Object Oriented Approach (Classes > Functions).
• Modularity within the components is important (both core and UI).
• Eventually code split.
• "Executable" would be a web-component ().
• API > QueryParameters > Web component attributes > Input Data/Experience Data.
• Event Up Prop Down approach.
• AR via model-viewer
• Define Analytics early.
• Test Driven Development.

Tech Stack:

• Bundler: Vite
• Primary Language: Typescript.
• Engine: Threejs
• Linter: ESLint
• Formatter: Prettier
• UI: React
• CI/CD: Github Actions
• Unit Tests: Jest

Developer Guildelines:

The entire project is internally called an "App", which is wrapped and deployed as a web-component. This is crucial to remember because anything within the App will be named and structured accordingly. For example:

The top level web-component's class is named "AppConfiguratorLite" within "AppIndex.ts" because it is the entry point for the ConfiguratorLite App. Diving futher into the structure, you will notice that this app has further components. Some of those components are:

• app-core
• app-ui

There could be more App level components in the future but there needs to be a very solid reason for why something was promoted/implemented at the App component level.

Once we enter the AppComponents level, each of these components manage their own sub-components and expose an API that allows interaction with their sub-components. No AppComponent should ever directly interact with another AppComponent's members/sub-components, instead the API exposed by that AppComponent should be used. You will very commonly see this being used for the communication between the AppCore and the AppUi.

Extending a base class We follow OOP patterns within this project and utilise inheritance as best as we can. This is the reason you will notice that the "app-core" component is broken down into

A generic directory structure:

• bundle-identifier (app, app-core, app-ui)
  • components (Dedicated for all the bundle level reusable components)
  • enums (All enums relevant to this bundle)
  • interfaces (All interfaces relevant to this bundle)