The front of shop.mayvenn.com.
Storefront is built primarily using ClojureScript and Om, with a smidgen of Clojure.
On the server side, there is a simple static file server with some redirects and a very tiny bit of dynamic code (for robots and stuff).
Storefront's Om code is built around a single application state and two disparate events systems, transitions and effects. Events processed in transitions mutate state, e.g. adding product information after it has been retrieved. On the other hand, those processed in effects cause side-effects, such as making api calls and causing animations. Despite being separate, the two event systems operate on the same events. This allows a clean separation of concerns. Events are collections of keywords that transitions and effects operate on reductions of these collections. This allows for some common tasks to be abstracted cleanly.
For example, lets say the navigate-product event, equivilant to [:navigate :product]
is triggered:
- The event will propagate to transitions and the
:navigate
transition will run. - Still in transitions, the transition for
[:navigate :product]
will run, and some page nav information will be moved into the app state. - The event will propagate to effects and the
:navigate
effect will run. It will start API calls for various information that needs to be loaded on every page change. - Still in effects, the
[:navigate :product]
effect will execute and an API call to fetch the product is started. - (ASYNC) Upon success, a callback that triggers the api-success-product is called. The other API calls from step 3 have similar functionality, so lets skip them for now.
- The api success event is then processed by transitions and the product is moved into the application state.
- Via the magic of Om (and therefore react) bindings, the product information is bound from the application state.
Here is some more information about effects and transitions
Starting at /src-cljs/storefront/, there are some directories.
- Accessors - Utility modules for working with our domain models
- Browser - Modules which work with browser APIs directly, e.g. scrolling and cookies
- Components - React UI components
- Hooks - Things like middleware or 3rd party code which is non-essential to the operation of storefront e.g. yotpo, honeybadger, optimizely
- Utils - Small helper libraries that are generic in nature, e.g. a Uuid generator
- Where are the tests?
- The vast majority of Storefront's tests are in a different project. This was done because they are integration tests and test more than just storefront.
- Whats up with your SCSS and CSS?
- They are from the previous version of the site. Going forward we would like to make the SCSS more component oriented.
- Can I run this?
- Sure, but you will need to setup up some external dependencies, such as an API server. We hope this project serves as a reference project moreso than generic ecommerce solution.
Copyright (C) Mayvenn, Inc. - All Rights Reserved