React application applying HOC patterns, built with CI, driven by BDD.
The goal of this APP is to ease customer's usage of large-scale public bicycle sharing system.
By displaying data from different providers (Bicing, Velib, ...) it can advice customers and provide them powerful information (location to pick or return a bike, best time for picking up a bike, ...).
Here is an example of a provider /lechatquidanse/bicing-api
Getting Started • Features • Built With • Development • Coding Standard • CI and Deployment
To install and run the API you need Docker Compose and... that's all. Please follow the official documentation to install it on your environment.
Clone the project and run the default installation:
git clone https://github.com/lechatquidanse/bicing-user-interface-app.git && cd bicing-user-interface-app && make installYour docker containers should have been successfully built and run.
Multiple features are proposed across the user interface, to locate stations nearby a geo location or change date expected:
The Makefile contains useful command for development purpose
Code and folder structure follow Domain Driven Design (DDD).
Here is a good article to understand naming and folder Domain Driver Design, little explanation and example.
src
\
|\ Application `Contains the Use Cases (state management) of the domain system, commands, queries, handlers and providers`
|
|\ Domain `The system business logic layer (Types, Definitions, Exceptions...)`
|
|\ Infrastructure `Its the implementation of the system outside the model. I.E: Rest Call Query, etc`
|
|\ UserInterface `It contains all the interfaces allowed for a user of the APP (Components and Containers)`
In this project, the state is handled by redux-saga. A reminder on how works redux-saga
Here is some very helpful resources that I encourage you to read to understand redux-saga and the architecture chosen in this project:
In this App, to query a station by its stationId, we need:
- actions, to explain if we want to start fetching, to explain that we are in pending a state, that an error occurred...
- operations/middleware, that will trigger a call to get station from a provider and dispatch other actions according to what happened
- reducers, to update state according to actions dispatched
- selectors, to "interface" how the state can be read
In this project, user interfaces are divided in two:
- components that handle "low level" templating. Their role is display html and css.
- containers that handle "high level" templating. Their role is dispatch actions, read state and render components. It is basically an enhanced version of a components, or called a Higher Order Component (HOC).
Here is some very helpful resources that I encourage you to read to understand HOC:
By decomposing our UI, it allows us to have a better SEPARATION OF CONCERNS. Which means easier testing, maintenance and development.
In this APP, to render geo suggestions, we need:
- a component to display the html Select input with some fixtures in it
- a container that will enhanced the component by connecting and reading state, rendering or not if its enabled...
CI and deployment can be handled through Gitlab and Docker thanks to .gitlab-ci.yml It contains 3 different stages.
Environment 'test' is triggered when a 'feature/*' branch is pushed to the repository. It will then install project and launch qa tools.
Environment 'build' is triggered when a 'release/*' branch is pushed to the repository. It will then install project, launch qa tools and then build and push a docker image on a registry if no error occured.
This manual action, will pull the image build by the previous step and update the specific container.
Stéphane EL MANOUNI · Linkedin